On Apr 6, 2016, at 18:04, Paul Koning <paulkoning%comcast.net@localhost> wrote:
On Apr 6, 2016, at 7:54 PM, Maciej W. Rozycki <macro%linux-mips.org@localhost> wrote:
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.
Yes, it could indeed be done, and it would be an interesting science project. You'd end up with a non-standard ABI, producing binary data incompatible with any real VAX. But it could be done.
I'm not sure it would be all that useful. Given the fact that there aren't any non-FPU VAXen, it doesn't seem worth the trouble.
It's interesting that clearly some subset options were only theoretical (float) while others were commonly used (POLYx, decimal instructions, PDP11 compatibility mode especially). I suspect that comes from the fact that doing without float instructions is a major hardship for a general purpose computer, while the other CISC instructions that clutter up the VAX instruction set are far less important. Things like POLY and CRC really don't add much value.
paul