Den 2019-08-26 kl. 15:15, skrev Kamil Rytarowski:
In short: the VAX "calls/ret" pair of instructions are quite slow (see timing mail yesterday) since they do a lot of things. Using jsb/rsb instead is much faster. This was described already in a paper from IIRC MIT in the early 80's.On 26.08.2019 14:08, Anders Magnusson 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.What is this change about?
Also if we change ABI we could spare one register to TLS.
Why not? :-)
No, therefore the overhead in this case. Have to check (and trap) instead, but vax is very happy to trap when it comes to floating point :-) This shouldn't be a problem, the common cases will work without traps.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).Can VAX support 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?) Comments on this?Do you mean F for float, G for double, H for long double? If that can work, it sounds fine.
I think it can :-) Will come back more on this later. -- R