Re: VAX floating point formats & tuning GCC for CPU models (was Re: Some more patches for GCC...)

[Jake Hamby <jehamby420%me.com@localhost>]

On Apr 4, 2016, at 10:25, Maciej W. Rozycki <macro%linux-mips.org@localhost> wrote:
> 
> On Mon, 4 Apr 2016, Greg Stark wrote:
> 
>>> Does -msoft-float work correctly?  I had the impression, perhaps 
>>> mistaken, that the GCC soft float library uses IEEE format, which of 
>>> course none of the VAX float formats use.
>> 
>> GCC doesn't support -msoft-float on VAX at all. It's apparently a
>> target-specific option and some targets support it and some don't.
> 
> All `-mfoo' GCC options are target-specific (`m' stands for "machine" 
> actually).  If it was a generic option, it would be called `-ffoo'.
> 
>> I would expect -msoft-float if it existed to be entirely IEEE format
>> and use a different set of libm functions that expect IEEE format. Of
>> course there are other libc functions that expect float arguments and
>> that could be an issue too...
> 
> The floating-point format used is down to the ABI -- if you mark binary 
> objects appropriately as they are compiled (assembly code annotation is 
> likely required), then you'll avoid interoperability problems.  There are 
> pieces of software which handcode floating-point data bit patterns of 
> course, but there aren't that many of them I believe.  Even for special FP 
> data portable software is supposed to avoid handcoding and to use 0.0/0.0 
> for example to get a qNaN.
> 
> If you choose the IEEE format, then you'll be able to port Java (GCJ) 
> with little effort BTW.
> 
>> If it existed my plan was to try to compile just parts of the system
>> with -msoft-float and then track down everywhere that floats from that
>> part could escape into the rest of the code and insert a conversion.
>> In my case that was going to be tractable because the part I wanted to
>> compile with -msoft-float was the user-visible datatype and there
>> should already be a simple conversion macro anywhere those are used
>> internally anyways. The goal was to guarantee that the internal code
>> doesn't depend on IEEE floating point.
> 
> A conversion between the VAX and IEEE floating point is non-trivial 
> because of the infinities and qNaN FP data (sNaN can be mapped to the VAX 
> reserved FP data, although even this is not an exact match).  There's the 
> issue of accuracy loss with denormals too.  The small range difference 
> between F-floating and IEEE single and then G-floating and IEEE double is 
> probably the least of the trouble.
> 
> All this makes a good conversion implementation a tad of a challenge, 
> although for programs which only rely on what some language standards 
> (e.g. ISO C) provide with disregard of IEEE floating point you can get 
> good results.
> 
> A while ago I actually tried to get a GCJ port running with the VAX 
> floating point format used in native (compiled code) by implementing the 
> necessary converters.  I got as far as to be able to build classpath, 
> however I couldn't verify the result at the run time because I chose the 
> wrong ;) OS (i.e. VAX/Linux) which has never got far enough to make it 
> possible.  I might be able to dig that stuff out if there's interest, all 
> of this was pretty much generic, suitable for any VAX OS.
> 
>  Maciej

You covered all the major differences between the two formats. The only detail you missed was that in addition to the lack of infinity, denormal numbers, and qNaN support, VAX FP also doesn't make a distinction between +0 and -0 (which on VAX is the reserved FP data you mentioned).

Other than those differences, you can convert between IEEE single and VAX F_float, or IEEE double and VAX G_float, by word-swapping the 16-bit words within the value (VAX uses big-endian 16-bit words for its FP formats, a PDP-11 artifact), and by adding or subtracting 2 from the exponent bias (can be done with integer add/subtract on the word containing the exponent).

It took me several hours of confusion before I finally figured out why the VAX docs say they use "excess 128" and excess 1024 encoding for the exponent, when you have to add/subtract 129 or 1025 to get the real exponent (IEEE uses excess 127 for singles and 1023 for doubles). On VAX, the mantissa range is from 0.5 to 0.9999..., and on IEEE, the range is from 1.0 to 1.9999..., with a hidden one bit in both cases. So if you interpret the mantissa in IEEE terms, the "real" exponent bias for VAX FP formats is 129 (F and D_float) or 1025 (G_float).

There's some really ugly code in lib/libc/gdtoa that's used for printing numbers and makes lots of VAX assumptions. I have it mostly working for G_float. I've partially updated the math library assembly language code, but I also believe the fdlibm math routines that all the other platforms use (lib/libm/src) could be adapted to VAX G_float by adding new macros in math_private.h to insert and extract words in IEEE format from VAX FP numbers. I'm only going to spend one or two more days on this part and then bundle up what I have and send it as a patch. There are other bugs in the compiler that are far more pressing.

Regards,
Jake