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

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

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