Port-vax archive

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

Re: Moving VAX into 21 century :-)



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.

Setting up AP - well, you might have some clever convetions in mind,
but I would expect similar effort to CALL would be needed for JSB.

Depends.  AP is really _needed_ by CALLG, not CALLS.  If your arglists
are always on the stack, then you can access the args by offsets off SP
and you don't really need AP.  (Args in registers, of course, work
equally well whichever way.)

Both handle AP, and in the called function you have no idea if it was CALLG or CALLS that called you. Your arguments are there through the AP, no matter which way you were called.
That's the whole point of the thing.

The fact that with CALLS, the arguments are actually on the stack is not something the called should know or care about.

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.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index