Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Wed, 25 Sep 2024 18:11:32 +0000
Organization: Rocksolid Light
Message-ID: <8f031f2b5082d97582b1231a060f2b9f@www.novabbs.org>
References: <vbd6b9$g147$1@dont-email.me> <2024Sep10.094353@mips.complang.tuwien.ac.at> <vckf9d$178f2$1@dont-email.me> <O2DHO.184073$kxD8.113118@fx11.iad> <vcso7k$2s2da$1@dont-email.me> <efXIO.169388$1m96.45507@fx15.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3464019"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$lgZRFLi8T76SJaj5KXOD6OBHVXZFi3i9IdTosAqveCsLkP.7/IB5m
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 7897
Lines: 163

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.