On 29 June 2014 22:45, Russel Winder via Digitalmars-d <[email protected]> wrote: > Hopefully there are points here for pedantry and bloody mindedness… > > > On Sat, 2014-06-28 at 18:32 -0700, Walter Bright via Digitalmars-d > wrote: > […] >> Keep in mind that D is a systems programming language, and that > implies you get >> access to the hardware types. > > > On Sun, 2014-06-29 at 12:22 -0700, Walter Bright via Digitalmars-d > wrote: > […]. >> >> That is not true with D. D specifies that float and double are IEEE 754 >> types >> which have specified size and behavior. D's real type is the largest the >> underlying hardware will support. >> >> D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is >> 16. > > > D gives access to the hardware types, and D defines the structure of all > those types. The only resolution is that D only works on that hardware > where the hardware types are the ones D defines. Thus D only works on a > subset of hardware, and can never be ported to hardware where the > hardware types differ from those defined by D. > > So D float and double will not work on IBM 360 unless interpreted, and > real would be 128-bit (not IEEE)? >
I'm sure it isn't as bad as you describe for floor and double. And if it is, then I can't see GCC (C/C++) working on IBM 360 either, without some out-of-band patches. And so what you allege IBM to have done is a platform problem, not a language one. Support for IBM extended reals is partial, and will improve as PPC is ported to. > The D real type definitely suffers the C/C++ float and double problem! > > I guess we just hope that all future hardware is IEEE754 compliant. > else static assert(false, "Here's a nickel, kid. Go buy yourself a real computer."); // :)
