--- Comment #4 from Don <clugd...@yahoo.com.au> 2011-03-21 10:58:35 PDT ---
(In reply to comment #3)
> GDC somewhat a bit exceptional, as there's both library functions and it's own
> internal real_t floating point emulation routines available (which is not
> exactly IEEE 754 compliant, but is close to the description of characteristics
> of floating types in the ISO C99 standard), etc...
> And there's call optimisation and constant folding which means if the values
> are known at compile-time, then most calls would have been evaluated away.
> logN(expN(x)) => x)
> And I'm sure both GCC and libc aren't always quite what the DMD unittests
> expect anyway. I know of at least 1 'off-by-one' math unittest that fails
> because of GCC backend truncates rather than rounds the value from real to
> double, and another where 1.5 * 10 makes 15.0000000001 - or something to that
> effect when formatted into a string literal.
> In any case, I'm more concerned about not hurting the systems that *do* have
> 80-bit math functions. The only other systems out there I can think of that
> have it is IA64 - which I have no hardware (though David's already mentioned
> that there's yet no IASM for for 64bit on GDC anyway. :)
Fair enough. AFAIK the only other system with 80-bit reals is Motorola 68K, but
the Freescale(?) upgrades to those processors only have 64 bit. So it's
probably a legacy system even for embedded processors, and won't ever have much
D presence even in the most optimistic scenario.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------