dennis luehring: > > - Its length is variable across operating systems, it can be 10, 12, 16 > > bytes, or even just 8 if they get implemented with doubles. The 12 and 16 > > bytes long waste space. > > across hardware systems - its not an operating system thing 80bit is the > native size of x86 fpu
If you change the OS, on the same hardware, you have different representation length inside structs. And they can waste lot of space. > but you can't port delphi extended type (since delphi2 i think), gcc > suports it, llvm supports it, assembler "support" it, borland and intel > compiler supports it Modern hardware doesn't support it. I think hardware will win. So far I have never had to port code from C/Delphi/C++ that requires the 80 bit FP type, but this means nothing. Do you know software that needs it? With LDC/Clang their support for the X86 FPU is very bad, you essentially use the SSE registers only unless you don't care for performance. You can try some benchmarks, or you can look at the asm produced. > but it is an 80bit precision feature in hardware - why should i use an > software based solution - if 80bits are enough for me You have software where 64 bit FPs are not enough, but 80 bits are exactly enough (and you don't need quad precision). > sounds a little bit like: lets throw away the byte type - because we can > do better things with int In D the byte is signed, and it's quite less commonly useful than ubyte. If you call them sbyte and ubyte you can tell apart better. Your analogy doesn't hold a lot, because ubyte is a fundamental data type, you can build others with it. While real is not so fundamental. There are languages that indeed throw away the ubyte and essentially keep integers only (scripting languages). You have to see the performance of the programs compiled with the last JIT for Lua language. > ok now we got 32bit, 64bit and 80bit in hardware - that will (i hope) > become 32bit,64bit,80bit,128bit,etc... but why should we throw away real > - maybe we should alias it to float80 or something - and later there > will be an float128 etc. With the current DMD specs, if CPUs add 128 bit FP the real type will become 128 bit, and you will lose all the possibility to use 80 bit FP from D, because they are defined as the longest FP type supported by the hardware. This is positive, in a way, automatic deprecation for free :-) > btw: the 80bit code-generator part is much smaller/simpler in code than > your 128bit software based impl Right. But I think libc6 contains their implementation. I don't know about Windows. >From Walter's answer it seems the real type will not be removed. It's useful >for compatibility with uncommon software that uses them. And if someday the >hardware 128 bit FP will come out, D will replace the real with it. Thank you >for all your comments. Bye, bearophile
