On Aug 26, 2019, at 8:08 AM, Anders Magnusson <ragge%ludd.ltu.se@localhost> wrote:
Hi all,
I have been looking at some VAX problems lately, and have found out that there are two architectural things things that probably would help VAX quite much.
1) Change calling convention.
As described in my previous mail, it would solve a very old well-known performance problem.
You could of course change the code generator in GCC to do that. It would be an ABI change, with far reaching impact. Stack trace (GDB and elsewhere) would be completely different. Function prologues would have to do register saving (not too difficult). Exception handling would need to be redesigned.
But I think there would be more to be gained by spending similar levels of effort on improving the VAX back end in the compiler for reliability.
2) Make VAX use IEEE floats :-)
Today virtually no floating point exist that is not IEEE. The only fragment around is probably the VAX floats.
I have done some checking, and if we accept the difference in rounding (VAX uses a different way than IEEE) then it would be (almost) no overhead in the common cases (overhead comes when dealing with INF, NAN and subnormals).
- Use F and G floats. They have the same format as IEEE single and double, and are both available on virtually all VAXen.
- Make use of the floating point faults that VAXen can generate to emulate the features missing on VAX.
...in theory also H floats could be used as long double since they match the IEEE 128-bit quad precision :-)
But since H float is optional it might end up being emulated (maybe not a big problem?)
I don't get it. VAX float is what the hardware uses. IEEE float is different in many details. For example, VAX doesn't have subnormals since all numbers are normalized and the MSB is not represented in the encoding. So while VAX F might have the same field layout as IEEE single precision, they are in fact completely different data types.
Why would you want to slow things down by emulating an alien float format?