Re: New Vax - future directions :-)

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Jul 6, 2021, at 12:26 PM, john%ziaspace.com@localhost wrote:
> 
> First, I have to say that I can't imagine there are many places left where such interesting discussions can take place. I'm loving all of this :)
> 
> That said, I'm mostly interested in seeing what future directions could help the current state of VAX. The biggest issue I see when running bulk pkgsrc builds are floating point exceptions stopping builds. Usually this is because the build process tries things that usually never happens in real execution, which makes me wish for either:
> 
> 1) alternate exception handling that allows continuing with and handling infinites and NaNs, which is doable with emulation / FPGA

VAX float doesn't have infinite, though it does have NaN ("signaling" NaN in IEEE terminology) as well as floating underflow and floating overflow exceptions.  All these are "faults" which means they are restartable.  So it's up to the OS and/or libraries to make that available to applications; it isn't a processor architecture limitation.

> and/or
> 
> 2) IEEE 754 floating point emulation that isn't just soft-float, but uses the built-in FPU to do most of the work

It's typically really hard to emulate one floating point format using an FPU that uses a different format.  It might be doable if both mantissa and exponent in the hardware are larger than in the emulated form, but even then it gets tricky.  For example, IEEE sometimes generates denormal results, something impossible by definition on VAX.

> If floating point were addressed, and if OpenSSL is fixed, we'd have many, many more packages built ;)
> 
> (If anyone wants to look in to OpenSSL, please do. I tried, but I don't know what to do when gdb dumps core...)

File a GDB bug report?  Is this native or cross GDB?  If native, it might be a GCC code generation bug; compiling with the current version might help.

	paul