Re: Moving VAX into 21 century :-)

[Johnny Billquist <bqt%update.uu.se@localhost>]

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