Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Moving VAX into 21 century :-)



Den 2019-08-31 kl. 17:58, skrev Johnny Billquist:
On 2019-08-31 16:19, Anders Magnusson wrote:
Den 2019-08-31 kl. 14:04, skrev Johnny Billquist:
On 2019-08-31 05:13, Mouse wrote:
Things that CALL do:
Push requested register on stack at entry, and automatically restores
them again at return.
Saves AP and sets up new AP.
Saves and sets up new FP.
Also:

- Longword-aligns SP.

- Fiddles some trap enables based on the entry mask.

- Sets up fixed condition codes in the stack frame, which the procedure
    can fiddle and then have loaded into the PSW by RET.

- If CALLS is used instead of CALLG, RET pops additional longwords.

- Produces UNPREDICTABLE behaviour in various cases I doubt anyone
    cares about (such as CALLS SP,dst or CALLS R0,@(R0)+).
Right. And maybe some of those things can really be skipped without 
any negative effects, but I have a feeling that the main gain by JSB 
is just that by not doing a bunch of things you gain speed. But it 
is at a cost, and many times you actually want those things as well, 
and if you do all of them, then the gain from JSB are gone.
Not in the C ABI, that's the point :-)  The only things that are needed in a function call are:
- Remember return address
- Save/restore callee-saved regs (if needed)
- Allocate space on stack (if needed)
With the "C ABI" you are meaning the Unix (GNU?) C ABI then. Because C 
under VMS would be using AP, otherwise it wouldn't work combining with 
any standard libraries or code from other compilers, or whatever...
No, I mean an efficient C abi based on our needs.  What C under VMS does is more of academic interest :-)
I just don't want to do a lot of memory cycles that are unneccessary.

Saving/restoring regs take the same time whether or not CALLS is used, so I removed that from the calculation.
AP is never needed, and FP only if VLAs are used (or alloca called).
You mean it is not used? So then the compiler is constantly computing 
the offsets from SP? Well, I guess you could definitely do this, but 
it's a lot messier.
Well, no. Since SP/FP/AP have the same values during the whole function execution (modulo VLAs etc...) it's just a matter of which offset is used.
That's the whole reason for the existence of AP to start with.
Experience gained from the PDP-11. You often ended up with ad-hoc solutions that more or less did what a dedicated AP register would do, in the first place, and have it way more standardized had benefits.
Of course, with Unix, some of those benefits a almost irrelevant, as 
most things end up using the same compiler backend. Back in the DEC 
days, you had all kind of programming languages, and having a nicely 
standardized calling convention made life much easier and better.
Oh well. Then yes. Either change the compiler to actually make use of 
the AP, or skip that whole part.
The work it change pcc to use this ABI was less than an hour, so it's was not a giant work.  Especially since all other (modern) archs use similar ABIs.
Well, it does mean it's incompatible with all existing compiled code, 
which is an issue in it self. Not to mention the question of what the 
gain is in the end, since we do need more manual (well, compiler 
managed) bookkeeping, which otherwise was done in hardware.
I don't get how the compilers ever would be an issue?  They do the same as they always do. Compatibility is a different issue (but a very small one, and not difficult to solve either, especially for VAX...)
2) Make VAX use IEEE floats :-)
Personally, I would not use this.  I prefer to actively break code 
that
blindly assumes IEEE floating-point, so I can fix it.  (So far, I have
found more such code than I have code that legitimately depends on the
IEEE behaviour in cases where it differs from the VAX behaviour;
indeed, I can't recall a non-artificial example of the latter. Not
that I've found all that much of the former.)
I agree in the sense that most code do not actually need IEEE, and 
if they crash because of this, it is almost always artificial 
creations that explicitly fails, and not the actual meaningful code.
But it does raise the point if we should just fix it/fake it so that 
those stupid artificial tests pass, and just keep the VAX FP for the 
rest, so that the code will run, also when you have VAX FP.
That would be far too much inneccessary work.  I think making VAX FP act as IEEE is easy and lightweight.  Trying to fool zillions of packages are really time-consuming for no gain.
Well, my thinking was mostly to make silly thing pass that are caught 
today. I don't know if we still trap some INFs, for example, which 
IEEE allows.
So, not doing some big effort. Essentially just becoming even less 
strict, and just let things roll as much as possible with the minimal 
amount of changes. Let people get bad values, and funny resolts 
instead of trapping. We're talking about people running this software 
on VAXen, and I do not expect that anything serious will be affected 
or broken by such changes.
Exactly my point.  The only thing that might be a problem is difference in rounding,  VAX rounding instead of IEEE. And the chance that anyone would do serious IEEE-required calculations on a VAX is close to NIL. This is for all common calculations.  The rest will generate a trap and will be handled in software, like other emulated instructions.
-- Ragge


Home | Main Index | Thread Index | Old Index