Re: is Vax addressing sane today

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.
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
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"