Re: is Vax addressing sane today

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