Re: is Vax addressing sane today

On Wed, 25 Sep 2024 16:54:18 +0000, EricP wrote:

Kent Dickey wrote:

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

Well, there is a bunch of things to unpack here.
>
First, INTO is a 32-bit x86 instruction. On 64-bit x64 AMD reassigned
that opcode to be for other instructions. On x64 the JO (jump overflow)
instruction does overflow detection.
>
The reason AMD could reassign INTO was because it wasn't being used by
C/C++.
But this is a side effect of C's widespread use, not the cause.
Programmers write in C because it is widely used and supported,

Free compilers

and as a consequence of that choice they get unchecked arithmetic.
But they are not choosing C to get unchecked arithmetic.
Had this same usage tests been done on other languages the results
would likely be quite different.
>
Second, on x86 the INTO and on x64 a JO offset32 take up 1 and 5 bytes
respectively. In JO case it has to branch to a ThrowOverflow () call
so thats 5 more bytes per ADD or SUB if you want error traceability.
With overflow trapping instructions there is NO runtime or code size
cost.
>
Third, on many risc ISA like RISC-V there are no flags so no JO
instruction
even possible. Either they must use the branchless overflow idiom or the
branching version, adding more to the cost of error detection.
>
*OR*its has an Add Fault Overflow instruction which has NO RUNTIME COST
   ADDFO  rd = rs1 + rs2

*OR"its ??? can you translate than into comp.arch language.

Fourth, it sounds like what you want is a risc (no flags) ADD
instruction
that returns both a result and an overflow flag so you can do the
equivalent of the x64 JO branch test.
   ADDO (ro,rd) = rs1 + rs2
where rd is dest and ro is a register to receive a 0/1 overflow flag.
Once one allows multiple dest registers ADDO is trivial to support.
>
But that does not invalidate the usefulness of ADDFO.
I would also have ADDFC Add Fault Carry for unsigned overflow,

Which will be used two orders of magnitude less than ADDFO. First
because unsigned is used less often than signed, secondly much/most
unsigned arithmetic is specified to wrap rather than check.

plus other instructions for checking signed overflow and unsigned carry.
>

Look at:
https://godbolt.org/z/oMhW55YsK
>
Which is this code:
>
int add2(int num, int other) {
    return num + other;
}
>
Compiled with these options:  -O2 -ftrapv
(-ftrapv is the GCC argument for detect signed overflows and crash).
>
For x86-64 clang 19.1.0:
>
add2:
        add     edi, esi
        jo      .LBB0_1
        mov     eax, edi
        ret
..LBB0_1:
        ud1     eax, dword ptr [eax]
>
This looks OK: it does a normal add, then branches-on-overflow to
an undefined instruction.

>
Yes, this is all for x64 which has no INTO instruction.

s/x64/x86-64/g
It is still an x86 with all the benefits and detriments.
<snip>

>

So why should any hardware include an instruction to trap-on-overflow?

>
Because ALL the negative speed and code size consequences do not occur.

No because an EFFICIENT trap-on-overflow has no performance consequences
when no overflow is created. Efficient means 10-20 cycles to arrive at
exception handler--already in a reentrant state with exceptions and
interrupts still enabled. Just because x86 is so horrible in this regard
does not mean every architecture has to be at least that bad.

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.

>
Not really. Its a flag in the uOp indicating HasException and a union
of fields to hold exception status and RIP, all of which needs to be
there for other instructions like load/store.

Agreed, the overhead of recording "Overflow" and whether to do something
about it is so small that other considerations sway the argumetns.

Instruction sets which make detecting overflow difficult (say, RISC-V),
would do well to make branch-on-overflow efficient and easy.  But adding
trap-on-overflow instructions is a waste of effort.

No they are a very useful tool for those who need such a tool
because the manual alternative is significantly more expensive
for both size and performance.
>
"I have one example where overflow exceptions would be a poor
implementation
choice" does not imply "therefore no one should have them as an option".

>
Can you share what language, compiler, and hardware you are using which
implements overflow checks using a trap-on-overflow instruction?
>
Kent

>
On DEC VAX the Overflow Enable flag was in the Program Status Word.

On My 66000 Overflow enable bit is part of the thread-status-line.

IIRC it was enabled by default in all DEC languages, Fortran77, Pascal,
Ada, Cobol, and disabled by default for C. But it could be toggled with
a runtime library call.

Similar--but library call does not have to "gain privilege" to flip the
bit's state.

For a variety of reasons having Overflow Enable in the status register
is A Bad Idea.

Can you expand. It seems to me if the unprivileged application using
the instructions at hand (Header Register instruction) can access
and write those exception control bits without needing privilege--
that most of the "A Bad Idea™" disappear. At the same time there
are significant amounts of state that do require privilege to
access in thread-status-line, and HR obeys such a distinction.

               On Alpha it was a compile switch which selects different
instructions ADD vs ADDV, and also controlled by pragmas.
If you wanted to manually test for overflow then you used
one of the idioms, whatever language you worked in.