About: FPU Enabler
Posted by Chainfire on 01-10-2009 at 11:00:00 - Comments: 197 - Views: 44299
Project: FPU Enabler - Tags: Good news Drivers Windows Mobile
Project: FPU Enabler - Tags: Good news Drivers Windows Mobile
See my post at Modaco, also for the actual download:
Several new devices have an FPU these days (VFP in this case), a coprocessor that can speed up floating point (fractioned numbers) calculations. Devices that have an FPU include devices based on the SC6410 processor like the Samsung Omnia II/Pro and Acer M900 and Snapdragon based devices like the Toshiba TG01 and HTC Leo. However, Windows Mobile right now does not come with support for it. NuShrike and myself decided to do something about this, and FPU Enabler is the result.
FPU Enabler is an application that patches coredll in-memory and replaces some of the FPU emulation routines with actual FPU routines, all applications will automatically make use of this.
Now, obviously there are a number of caveats with an application like this. First, the FPU code is not IEEE compliant. This means that in some edge cases calculation results are undefined, which may cause issues. Exceptions are not supported - so for example a divide by 0 will not raise an error, which may be problematic. If your device acts as the control board for a nuclear power plant, we would definitely advise against using this app.
Not nearly all instructions that can be speed-up by FPU use are supported (yet). They may be in the future. Actual real-world effects will depend heavily on the application used. You'd have to look hard to notice it, for most applications. This may change as (if) more instructions become supported.
Because of the way this is patched in, you aren't actually reaching the full speed possible with hardware FPU. Also, devices not running in "ALLKMODE" already are patched to run this way. As we haven't really found a good way to patch context switching code yet, during FPU instructions interrupts are disabled and an extra jump into patch-code is required. Disabling interrupts requires KMODE, and thus we patch everything to run this way.
What we really need is for Microsoft, Samsung, Toshiba, HTC, etc to just simply enable FPU support in their kernel builds. That would solve pretty much all the issues, and be quite a bit faster even. We know CE6 supports it, and it is rumored WM7 will as well, but it would be great if they would put in support in new 6.5 builds :)
Instructions
- Unpack the zip file somewhere
- Copy the EXE and the DLL to \ on your device
- Run the EXE
- Click Patch button
- Wait until it says it's done
- Close the EXE
Credits
- Chainfire - Patcher code
- NuShrike - FPU code
Thanks
- cmonex - Help with patch theory
- no2chem - Help with patch theory
Compatibility notes
- Samsung Omnia II - main test device
- Samsung Omnia Pro - untested, should work
- Acer M900 - crashes on suspend/resume, FPU enabled flag cleared, still looking for a solution
- Toshiba TG01 - quick test done by cmonex, effect not as big as with Omnia II
- HTC Leo - untested, should work, effect likely not as big as with Omnia II
Patcher notes
- Right now, the patcher does not allow you to un-patch. You need to soft-reset.
- DirtyBench is not really (or "really not") a reliable benchmark and does not benchmark all functions - hence the name.
- No attempt is made (as of yet) to test if a function is actually faster with or without FPU. On the TG01 for example this results in __adds being patched while it should not. The call overhead due to the patching is larger than the time taken to do an __adds in FPU emulation mode.
- You can quit the app and the FPU functions will keep working. The patched code resides in an intentional memory leak.
- Do NOT run the application twice without soft-resetting in between!
Currently patched functions
- __adds
- __subs
- __muls
- __divs
- __addd
- __subd
- __muld
- __divd
- __itos
- __itod
- __stoi
- __stod
- __dtoi
- __dtos
Other functions may follow in the future.
Known issues
- Acer M900 - crashes on suspend/resume, FPU enabled flag cleared, still looking for a solution
- Samsung Omnia II - GinKage reported his 'lock screen' doesn't work with FPU Enabler running. Works fine for me, though.
Feel free to report issues, I'm not assuring you we will fix them, but they're interesting to know anyways.
Remember this is proof-of-concept code, it may not actually be very useful, and may have adverse effects. It's "because we can" code.
Several new devices have an FPU these days (VFP in this case), a coprocessor that can speed up floating point (fractioned numbers) calculations. Devices that have an FPU include devices based on the SC6410 processor like the Samsung Omnia II/Pro and Acer M900 and Snapdragon based devices like the Toshiba TG01 and HTC Leo. However, Windows Mobile right now does not come with support for it. NuShrike and myself decided to do something about this, and FPU Enabler is the result.
FPU Enabler is an application that patches coredll in-memory and replaces some of the FPU emulation routines with actual FPU routines, all applications will automatically make use of this.
Now, obviously there are a number of caveats with an application like this. First, the FPU code is not IEEE compliant. This means that in some edge cases calculation results are undefined, which may cause issues. Exceptions are not supported - so for example a divide by 0 will not raise an error, which may be problematic. If your device acts as the control board for a nuclear power plant, we would definitely advise against using this app.
Not nearly all instructions that can be speed-up by FPU use are supported (yet). They may be in the future. Actual real-world effects will depend heavily on the application used. You'd have to look hard to notice it, for most applications. This may change as (if) more instructions become supported.
Because of the way this is patched in, you aren't actually reaching the full speed possible with hardware FPU. Also, devices not running in "ALLKMODE" already are patched to run this way. As we haven't really found a good way to patch context switching code yet, during FPU instructions interrupts are disabled and an extra jump into patch-code is required. Disabling interrupts requires KMODE, and thus we patch everything to run this way.
What we really need is for Microsoft, Samsung, Toshiba, HTC, etc to just simply enable FPU support in their kernel builds. That would solve pretty much all the issues, and be quite a bit faster even. We know CE6 supports it, and it is rumored WM7 will as well, but it would be great if they would put in support in new 6.5 builds :)
Instructions
- Unpack the zip file somewhere
- Copy the EXE and the DLL to \ on your device
- Run the EXE
- Click Patch button
- Wait until it says it's done
- Close the EXE
Credits
- Chainfire - Patcher code
- NuShrike - FPU code
Thanks
- cmonex - Help with patch theory
- no2chem - Help with patch theory
Compatibility notes
- Samsung Omnia II - main test device
- Samsung Omnia Pro - untested, should work
- Acer M900 - crashes on suspend/resume, FPU enabled flag cleared, still looking for a solution
- Toshiba TG01 - quick test done by cmonex, effect not as big as with Omnia II
- HTC Leo - untested, should work, effect likely not as big as with Omnia II
Patcher notes
- Right now, the patcher does not allow you to un-patch. You need to soft-reset.
- DirtyBench is not really (or "really not") a reliable benchmark and does not benchmark all functions - hence the name.
- No attempt is made (as of yet) to test if a function is actually faster with or without FPU. On the TG01 for example this results in __adds being patched while it should not. The call overhead due to the patching is larger than the time taken to do an __adds in FPU emulation mode.
- You can quit the app and the FPU functions will keep working. The patched code resides in an intentional memory leak.
- Do NOT run the application twice without soft-resetting in between!
Currently patched functions
- __adds
- __subs
- __muls
- __divs
- __addd
- __subd
- __muld
- __divd
- __itos
- __itod
- __stoi
- __stod
- __dtoi
- __dtos
Other functions may follow in the future.
Known issues
- Acer M900 - crashes on suspend/resume, FPU enabled flag cleared, still looking for a solution
- Samsung Omnia II - GinKage reported his 'lock screen' doesn't work with FPU Enabler running. Works fine for me, though.
Feel free to report issues, I'm not assuring you we will fix them, but they're interesting to know anyways.
Remember this is proof-of-concept code, it may not actually be very useful, and may have adverse effects. It's "because we can" code.
