Re: is Vax addressing sane today

On Tue, 24 Sep 2024 10:44:22 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

Michael S wrote:

On Tue, 24 Sep 2024 08:02:23 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
 

MitchAlsup1 wrote: 

On Mon, 23 Sep 2024 21:57:08 +0000, Kent Dickey wrote:
    

In article <O2DHO.184073$kxD8.113118@fx11.iad>,
EricP  <ThatWouldBeTelling@thevillage.com> wrote: 

    

The x86 designers might then have had an incentive to make all
the checks as efficient as possible, and rather than eliminate
them, they might have enhanced and more tightly integrated
them. 

>
OK, my post was about how having a hardware trap-on-overflow
instruction (or a mode for existing ALU instructions) is useless
for anything OTHER than as a debug aid where you crash the
problem on overflow (you can have a general exception handler to
shut down gracefully, but "patching things
up and continuing" doesn't work).  I gave details of reasons
folks might want to try to use trap-on-overflow instructions,
and show how the other cases don't make sense.
>
In no way was I ever arguing that checking for overflow was a bad
idea, or a language issue, or anything else.  Just that CPUs
should not bother having trap-on-overflow instructions. 

<snip> 

So why should any hardware include an instruction to
trap-on-overflow?
>
Trap-on-overflow instruction have a hardware cost, of varying
severity. If the ISA isn't already trapping on ALU instructions
(such as divide-by-0), it adds a new class of operations which
can take exceptions.  An ALU functional unit that cannot take
exceptions doesn't have to save "unwinding" info (at minimum,
info to recover the PC, and possibly rollback state), and not
needing this can be a nice simplification.  Branches and LD/ST
always needs this info, but not needing it on ALU ops can be a
nice simplification of logic, and makes it
easier to have multiple ALU functional units.  Note that x86
INTO can be treated as a branch, so it doesn't have the cost of
an instruction like "ADDTO r1,r2,r3" which is a normal ADD but
where the ADD itself traps if it overflows.  ADDTO is
particularly what I am arguing against--
it is just a bad idea for the ISA to have ALU instructions take
exceptions. 

>
You argue that trap-on-overflow as an instruction is unnecessary
AND
You argue that overflow detection is worthwhile
AND
You argue that ALU should not raise overflow exceptions
>
I am at a loss for how to take all 3 arguments together at the
same time !?! Can you explain ?? 

>
Maybe all add/sub/etc opcodes that are immediately followed by an
INTO could be fused into a single ADDO/SUBO/etc version that takes
zero extra cycles as long as the trap part isn't hit?
>
Personally I'm happy with the clang approach.
 

 
Couple of questions:
1. Which code would you put at destination of jo branch?
2. In your code generator would every jo in the code (or in the
module, or in the function) jump to the same destination or each
will have destination of its own.
 
It would be interesting if you answer before looking at what clang
does, then take a look and comment again. 

 
If the handler consists of terminating the program, then every
function, or small group of functions depending upon total code size,
can have a common target, just so that all the JO opcodes can use the
short-form two-byte encoding og a forward branch. I.e. leaving just
127 bytes available for mainline code.
 

In case of clang (on Win7+msys2, I didn't test on other targets) the
handler terminates the program with no useful info printed.
Still, clang has different target for each jo. At target location it
places invalid instruction.
So, it lays infrastructure for better handler, pays the price in terms
of code size, but does not take an advantage.

If you want separate handling for each overflow, i.e. switch to
bigint and resume, then you do need one target per JO, in order to
pick up the originating instruction address (and place it on the
stack for a subsequent RET?) before jumping to a common handler.
 
Terje
 

I want address of originating instruction in the handler.
I want it not for switch to bigint that would not be in spirit of
non-dynamic compiled languages, but in order to get useful termination
printout.
With JO in order to get what I want I'd have to pay by significant
increase in code size.