actually, as far as some architectures go, their 32-bit floating point software is not slower than the early hardware floating point units. At there MCU units the generic bulkiness of an operating system poses the main problem. In assembly I can assure hard-realtime interrupts of 3 instruction cycles delay and analyse the proper cause in two instructions after which execution of the interrupt code follows. Floating point math takes ~200 cycles on 8-bit cores, but on 16-bit cores it is much faster. It also depends on how wisely you use it, like pre-aligning and such. And yes, it is faster to use multiple-aligned 32-bit maths (or 8-bit and 16-bit and 24-bit) combined and aligned to match a specific fixed point as a floating point substitute. That's rather hardcore programming, but the fastest execution.
On Tue, Oct 28, 2008 at 5:45 AM, EBo <[EMAIL PROTECTED]> wrote: > Jon Elson <[EMAIL PROTECTED]> said: > >> Jeff Epler wrote: >> > Second, emc >> > freely uses floating point including in real-time code, and most non-x86 >> > systems don't have floating point units. This use of floating point >> > might be impossible in a real-time context, might give them unacceptably >> > low performance, or it might not be a problem at all---someone with >> > specific knowledge about these platforms might know for sure. >> > >> Yup, this is totally architecture dependent. On the expired Alpha >> architecture, there is no demarcation between floating point and integer >> hardware. Any register can hold a floating point operand, and no >> special floating point state is held anywhere else. So, there'd be no >> extra overhead or additional context to save. I think MIPS is (was) the >> same way. I don't know what the "new" architectures will be, other than >> the X86_64, which probably retains all of the horrible encrustations of >> the X86 architecture. > > does anyone know of a systematic study looking at the overhead in floating > point emulation in AVR/ARM/PIC? It might be interesting to know how much FP > is actually done in the critical section, and how tight hard realtime > constraint cane be guarnteed in that context. Even if it were not realistic, > one could make a list of realistic embedded CPU's that could work. > > EBo -- > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
