Could you offload certain CPU instructions to a co-processor over PCI-E bus?

[Keylimesoda]

I've been working with the Intel Quark (x1000 SoC) lately.

For old binary compatibility reasons, I'd like to be able to run the vector instructions that are missing on the Quark (SSE2 in particular).

Would I be better off writing an emulator that intercepts and runs the instructions in a hypervisor kind of setup, or could I actually get a co-processor chip (think x87) that I could use to offload instructions, perhaps across the PCI-E bus?

 

[BrightCandle]

If you just leave the instruction in the program as per normal then when the CPU hits that instruction its going to crash. I don't know if you can pick that crash up somehow and do something with it (some sort of custom fault handler maybe) but most likely you can't get told when the instruction didn't match something the CPU knows about.

So the next option is virtualising the underlying hardware. There you definitely can catch particular calls, and search through the programs and replace the instructions with calls into your routines and such. Its a non trivial problem of course but its possible to intercept them this way and then do whatever you want with that call. Don't focus too much on having special hardware run them, once you are at the point of calling your hypervisor its most likely still much faster to keep the calculation in the CPU rather than going over the extremely slow PCI-E bus to dedicated hardware. The main thing is emulating it in software initially.

While its possible I suspect by the time you have it working the updated hardware will probably support the instructions, its going to take quite a while to write a program capable of hosting this sort of thing.

 

[Keylimesoda]

I'm hopeful, but not optimistic that the Quark will support SSE2 anytime soon.

I'm not sure how you'd "bolt-on" SSE2 support without messing with the decode section of underlying Pentium.

 

[TuxDave]

I'm hopeful, but not optimistic that the Quark will support SSE2 anytime soon.

I'm not sure how you'd "bolt-on" SSE2 support without messing with the decode section of underlying Pentium.

If I had to venture a guess, you would want to "bolt it" on back in compilation. You don't want to try to wait until the physical decode portion of the Pentium to do some trickery.

Edit: Oh, I guess when I reread your original post, if you're jumping through all these hoops for legacy binary reasons, then I guess recompiling is out of the question.

 

[Mark R]

The old way this was done for allowing binary compatibilty with FPU code on non-FPU hardware was to handle the "invalid opcode" exception from the CPU.

When the CPU hits an unrecognised instruction, it jumps to the OS/your code, which checks to see if it recognises the instruction. If it doesn't, it invokes the normal excpetion mechanism (usually terminate the program). If it does then it runs the emulation.

This should be doable on any modern CPU - the issue is that it needs low level hardware access, so your OS must support you doing this.