Re: is Vax addressing sane today

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.

Terje