Re: VAX floating point formats & GCC patches

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

> 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

Are we sure there wasn't some MicroVAX model somewhere that was sold with only the CPU chip and FP emulation? The Digital Technical Journals seem to imply that you could get one just the CPU chip and no FPA, and VMS & Ultrix would emulate the FP instructions through the reserved operand exception. But it's possible that they never actually configured many systems that way because it would be so slow.

I didn't think the POLY instruction added much value either, but it turns out that polynomial approximations are used to compute sines, cosines, and other math functions. On the later VAXen, it's true that you could easily do 6 or 7 multiply-adds in a loop, especially with auto-increment, or even unrolled, and it's no big deal. But I think when they were designing the architecture in 1976, it seemed like a really cool hack to be able to have one microcoded instruction to crank through the entire polynomial computation in one instruction.

I have some good news on the GCC optimization & code gen bug fixing front which I'll share in a separate email. I'm basically finished with the G_float conversion project, so I'll send a diff to the list, probably tomorrow, after I've cleaned it up and tested it a bit more. I didn't rewrite very much code and didn't add or remove any files, so it should be a reasonably clean patch, if I can manage to email it without any glitches.

Regards,
Jake