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 11:10, Paul Koning <paulkoning%comcast.net@localhost> wrote:
> 
> 
>> On Apr 4, 2016, at 12:45 PM, Antonio Carlini <a.carlini%ntlworld.com@localhost> wrote:
>> 
>> On 04/04/16 17:05, Felix Deichmann wrote:
>>> Am 04.04.2016 um 17:58 schrieb Mouse:
>>>>>> [...] NetBSD on VAXen without FPA chips, [...]
>>>> 
>>>> I'm probably just exposing my ignorance, here, but, do such things
>>>> exist?
>>> 
>>> InfoServer 1000 for example. It seems to be based upon a CVAX 78034 CPU without the "floating-point accelerator" CFPA.
>> ...
>> That said, I don't know whether any real VAX ever shipped without FP. The VAX-11/730 was, iirc, almost entirely implemented in microcode, so I guess you could re-write the microcode and dump the FP instructions. Not sure that would count as a VAX though ...
> 
> The "VAX Architecture Reference Manual" book (not the DEC internal document) has summaries of the various models in Appendix B.  I though that Microvax I was an exmaple of a no-float machine, but that's incorrect.  What it says is that there were two versions: one with F/G and one with F/D.  (Neither variant has H float.)  MicroVAX II is shown as having F/D/G but no H.  It also says, interestingly/curiously enough, that G/H float support was an optional feature on the 750 and 780.  Also that the 730 was the first VAX to have F/D/G/H standard.
> 
> 	paul

Yep, that's what I concluded as well. NetBSD's kernel has emulation for most of the instructions that were removed from the various MicroVAX chips (including "polyd", but not "polyg"), but no set of floating-point routines. So there's no way NetBSD will work now without an FPA.

It might be interesting to try to build a version of NetBSD that used IEEE-compatible soft float routines and avoided the VAX formats completely, but it would probably be at least 30x slower than using the built-in FP instructions and VAX formats and living with their limitations.

Regards,
Jake