Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 24 Sep 2024 10:44:22 +0200
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <vctu57$350hh$1@dont-email.me>
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>
 <3b7a257101d09e1995314aadace0e14f@www.novabbs.org>
 <vctklf$33me0$2@dont-email.me> <20240924113703.00002a90@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 24 Sep 2024 10:44:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ba850320f378134a56324cf4c3f4d265";
	logging-data="3310129"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qEhQhqmUDg8nuvVUVywwK2TykuhbJI99V6ebIidZkjg=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:MzHbW3xW7Is6OkUN4YSsfbOMoQo=
In-Reply-To: <20240924113703.00002a90@yahoo.com>
Bytes: 5566

Michael S wrote:
> On Tue, 24 Sep 2024 08:02:23 +0200
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>=20
>> MitchAlsup1 wrote:
>>> On Mon, 23 Sep 2024 21:57:08 +0000, Kent Dickey wrote:
>>>   =20
>>>> In article <O2DHO.184073$kxD8.113118@fx11.iad>,
>>>> EricP=C3=82=C2=A0 <ThatWouldBeTelling@thevillage.com> wrote:
>>>   =20
>>>>> 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).=C3=82=C2=A0 I gave details of reas=
ons 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.=C3=82=C2=A0 Just that C=
PUs
>>>> 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.=C3=82=C2=A0 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.=C3=82=C2=A0 Branches and LD/ST al=
ways
>>>> 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.=C3=82=C2=A0 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.=C3=82=C2=A0 ADDTO is particula=
rly 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.
>>
>=20
> 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.
>=20
> 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=20
common target, just so that all the JO opcodes can use the short-form=20
two-byte encoding og a forward branch. I.e. leaving just 127 bytes=20
available for mainline code.

If you want separate handling for each overflow, i.e. switch to bigint=20
and resume, then you do need one target per JO, in order to pick up the=20
originating instruction address (and place it on the stack for a=20
subsequent RET?) before jumping to a common handler.

Terje


--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"