Re: One more oddity with gcc and vax floats...
Dave McGuire <[email protected]> Wed, 10 Jun 2026 09:56:01 -0400
| Newsgroups | gmane.os.netbsd.ports.vax |
|---|---|
| Message-ID | <[email protected]> |
On 6/10/26 09:50, Paul Koning wrote:
>>>>>> This is just one more problem with non-IEEE floating point. Since this
>>>>>> is a battle that cannot be won maybe I should put the dust of the
>>>>>> "Emulate IEEE floating point" stuff I once worked on. Must read up on
>>>>>> the IEEE 754 standard first though.
>>>>>
>>>>> i wouldn't hate this. :-)
>>>>
>>>> I'm not convinced. Starting to do all FP math in software will be costly, on a machine that is already suffering heavly with performance issues.
>>> Why couldn't hardware floating point do much of the work?
>>
>> I was about to ask the same thing. Let the hardware do the FP in VAX format, and the emulation would just be a thin translation layer. There would be some edge cases like NaN etc, but other than that, it's not that hard to do.
>
> It's not quite a thin translation layer because the ranges are different, and IEEE has rounding modes that DEC float doesn't.
Sure, there are things that would need to be dealt with. But I know
conversion is practical and not all that difficult; I've written code to
do that before, for both Cray and VAX FP.
It's one of those things where the regular stuff takes an afternoon,
and the edge cases take another two weeks. ;) But it can be done. I
don't know if it's practical in a "shim", but I bet the end result would
be faster.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA