Remove real type

[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

> - Results that you can find with programs written in other languages are usually computed with just floats or doubles.
 >If I want to test if a D program gives the same results I can't use 
reals in D.
 > - I don't see reals (long doubles in C) used much in other languages.

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

> - Removing a built-in type makes the language and its manual a little simpler.

it doesn't change the codegeneration that much (ok, ok there are some 
fpu instructions that are not fully equal to double precision behaviour) 
but also for more than 15 years now

> - I have used D1 for some time, but so far I have had hard time to find a purpose for 80 bit FP numbers. The slight increase in precision is not so useful.
> - D implementations are free to use doubles to implement the real type. So in a D program I can't rely on their little extra precision, making them not so useful.

but it is an 80bit precision feature in hardware - why should i use an 
software based solution - if 80bits are enough for me
btw: the precision lost while switching between fpu stack and the D data 
space is better

> - While I think the 80 bit FP are not so useful, I think Quadrupe precision FP (128 bit, currently usually software-implemented)
 >can be useful for some situations, 
(http://en.wikipedia.org/wiki/Quadruple_precision ).
 >They might be useful for High dynamic range imaging too. LLVM SPARC V9 
will support its quad-precision registers.

sounds a little bit like: lets throw away the byte type - because we can 
do better things with int

> - The D2 specs say real is the "largest hardware implemented floating point size", this means that they can be 128 bit too in future. A numerical simulation that is
 >designed to work with 80 bit FP numbers (or 64 bit FP numbers) can 
give strange results with 128 bit precision.

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.

> So I suggest to remove the real type; or eventually replace it with fixed-sized 128 bit floating-point type with the same name (implemented using a software
 >emulation where the hardware doesn't have them, like the __float128 of
 >GCC: http://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html ).
 > In far future, if the hardware of CPUs will support FP numbers larger 
than 128 bits, a larger type can be added if necessary.

why should we throw away direct hardware support - isn't it enough to 
add your software/hardware float128? and all the others

btw: the 80bit code-generator part is much smaller/simpler in code than 
your 128bit software based impl