OSDev.org

Hi, I've been thinking of ways I could use instructions from FPU,MMX,SSE,SSE2,3DNOW instruction subsets to speed up my operating system.

I'm currently looking at ways to use MMX/3DNOW instructions to speed up my VESA library code to make rendering faster.

Another thought I have is to recode my search routines to use packed instructions and data (MMX,SSE/SSE2) so I can search on multiple keys (upto 4 at a time) in my linear link list search code.

Has anyone thought of these instructions and how to use them to improve their os speed?

Any suggestion would be highly appreciated.

Thanks

Not all computers support some of these instructions (most computers made in the last ten years or so support FPU, but the others are newer technologies).

If you want people to be able to use your OS, even if they don't have those, you could detect the presence of MMX, SSE, etc. when starting up. Then, if they have it, use an optimized code, but if not, use the compatible code. Just a thought (I have a 486, so FPU is all my PC has)

You could have some code to emulate these things, whenever an illegal instruction is encountered it would do what the instruction would have done. But for computers that don't have those, the code would actually be slower rather than faster (although this is probably the easiest way to do it).
It's difficult to be compatible AND use newer technology, so if you choose newer technology, that's OK because it's your OS

Manipulating multiple chunks of data with one instruction can increase your efficiency HUGELY, but if you don't really need SIMD (Single-Instruction Multiple-Data) then you probably shouldn't use it, as it could actually make your code less efficient, and harder to read as well.

Thanks, but I already know that. That wasn't my question.

Using those instructions in the kernel would be a bad idea, it will require saving the user programs FPU/SSE state on kernel entry.

You can program SSE/MMX directly in assembly but it will be far easier to just ask GCC to compile -O3 -msse2, of course if you want to have a single library for both with/with-out SSE then you'll need to do the math manually.

Read the first paragraph from AR again: Using any FPU, MMX, or SSE registers will significantly increase your context switch times. If the kernel only ever touches the integer registers, it doesn't have to save / restore the FPU registers for the userspace code. I can't think of a scenario where using those FPU registers in kernel space would be worthwhile the additional work ocurring at every kernel entry.

If you were to insist on the VESA code being in the kernel though, you could just set the save/restore code to only execute in the event of entry into SSE optimized sections of code, which is what Windows does.

I personally would prefer a user space library to create a raw bitmap which the kernel can just copy onto the framebuffer then there isn't any need in the kernel itself. (You used the term "Operating System" which doesn't help in determining where exactly you want it)

Correction: My previous post was not entirely correct, you could simply compile seperate chunks of code like "SSE_DrawRect()", "MMX_DrawRect()" and "NoOpt_DrawRect()", link them all in then use the initalization to determine which function would be best at runtime and use a "thunk" to map to it.

Thanks for the comments and suggestions. Sorry for the delay in responding, been tied up with work

I'm using a microkernel design and use the TS bit to trigger a FPU/MMX/SSE state save only when a task uses those instructions.

I'll be using 3DNOW/MMX/SSE when available for the graphics and VESA subsystems (will be doing OpenGL as soon as I sought out VESA).

I'll have to think over using these instructions in the kernel itself, probably do some profiling.

I'll keep you posted. Thanks once again

NotTheCHEAT wrote: If you want people to be able to use your OS, even if they don't have those, you could detect the presence of MMX, SSE, etc. when starting up. Then, if they have it, use an optimized code, but if not, use the compatible code. Just a thought (I have a 486, so FPU is all my PC has)

486? I hope you mean your testbed is a 486.....(BTW I've got a 486-DX 35/40mhz and a 8008 IBM - ;D )

Nope, my COMPUTER is a 486. Until I can scrape up enough money to buy a computer worth talking about, that IS my computer.