Re: Moving VAX into 21 century :-)

[John Wilson <wilson%dbit.com@localhost>]

[de-lurk]
From: Paul Koning <paulkoning%comcast.net@localhost>
>There is a surprising number of newer architectures that don't do IEEE.
>See https://gcc.gnu.org/backends.html, the column marked "I".  And then
>there is SPU, which has IEEE float format but no NaN or Inf.  These don't
>seem to be NetBSD platforms, admittedly.  But it doesn't appear to be true
>that "all modern CPUs do IEEE".

As an assembly-language zealot, I do find it funny when HLL users are
totally comfortable quietly depending on non-portable architectural details,
when IMHO portability is the *only* point of HLLs (if you're going to write
non-portable code, why let it be fat and slow too?).  Just because IEEE FP
seems to be everywhere for some people doesn't mean anybody promised it to
them everywhere they'll ever go.  So I'd agree that this sounds like a bug
in Python.

Meanwhile, if passing pedantic test suites DOES seem important, well then
I guess speed ISN'T important.  So I'd argue that any true-IEEE-compatible
mode might as well be all software (so it'd be all library calls -- no need
to add trap overhead to do it with fake opcodes, unless there's an added
plan to make them *real* opcodes in an emulator), and should have a way to
turn it off for compiling truly portable code that'll run fast.

REALLY dumb question:  does GCC run on VMS?  Definitely want to keep the
usual calling convention around as an option if so.

Also:  agree about not needing a FP, other than as a convenience for
debugging.  Even Small-C (the only compiler I ever truly understood)
got that right -- at any point you always know how much you've messed up
the SP, and [original] K&R pretty much explicitly says that the only thing
a "goto" into a block (from above) promises to do is fix the SP to where it
would have been if you'd gotten there honestly (initializers be damned).
Which sounds like it's saying the exact same thing.

John Wilson
D Bit
[re-lurk]