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 Wed, 6 Apr 2016, Mouse wrote:

> >>> I would expect -msoft-float if it existed to be entirely IEEE
> >>> format and [...]
> >> The floating-point format used is down to the ABI -- [...]
> 
> Well, to an extent.  I expect you would have trouble finding a compiler
> that generated VAX assembly/machine code but with IEEE floats.
> -msoft-float (if it existed) would handle the arithmetic, but you'd
> also have to generate constants and the like to match.

 It's easier than you think it would seem.  You can actually configure GCC 
to use the IEEE floating point with the VAX target -- all you need is to 
set REAL_MODE_FORMAT appropriately for the relevant formats (SFmode, 
DFmode, etc.) at run time.  Then you can flip between the formats desired 
with a command-line option -- be it `-msoft-float' or whatever.

 This is actually how IRIX `long double' worked in the MIPS port before 
support was dropped.  IRIX used a pair of doubles (mips_extended_format) 
while the other MIPS ports used 128-bit IEEE format (mips_quad_format).  
This is also how switching between the IEEE 754-1985 and IEEE 754-2008 NaN 
formats now works for the MIPS ports, although the difference between the 
corresponding formats is a little bit less significant.  Still they are 
distinct formats (mips_*_format vs ieee_*_format), supported with a single 
GCC binary and switchable at the run time.

 All the supported FP formats are defined in gcc/real.c as structures 
providing details of the individual format's properties as well an 
encoding and a decoding function and the compiler itself operates in its 
own internal format.  Consequently switching between different external 
representations is really straightforward.

 Then GCC supports switching between different ABIs (multilibs in 
GCC-speak) at run time based on definitions provided in compiler's 
configuration telling it which command-line options or combinations of are 
significant for ABI differences.  You can pick arbitrary options, so it's 
up to you to decide what is relevant, including but not limited to FP 
format changes.  GCC will then pick different paths for different ABIs 
each, for startup files and libraries to be used in static linking, and 
that in turn can affect dynamic loading where applicable.

 So you could pick the IEEE single and double, and maybe 128-bit extended 
formats and use them with the `-msoft-float' multilib, and then have the 
VAX F-floating and D-floating, and maybe H-floating formats with the 
`-mhard-float' multilib.  You could have, say, a `-mg-float' hard-float 
multilib using the VAX F-floating and G-floating, and maybe H-floating 
formats as well.  All supported with a single GCC binary and using the 
corresponding compatible libc and other libraries.

 You could then define different dynamic loaders and have annotation 
defined for ELF binaries to tell compatible objects apart, so as to allow 
binaries to coexist in a single system and consequently have all the three 
ABIs supported in parallel at the same time on a single machine, on a 
per-process basis.  This has been done successfully with the MIPS/Linux 
port already (except for its countless number of ABIs rather than mere 3; 
to say nothing about ISA variations and ignoring the two endiannesses 
possible) -- with the aid of the kernel to switch hardware FP modes where 
necessary (not applicable for the VAX platform) and to match dynamic 
executables against the dynamic loader requested.  So with some effort it 
can be done with the VAX/NetBSD port as well.

 FWIW,

  Maciej