Path: ...!3.eu.feeder.erje.net!feeder.erje.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 08:02:23 +0200
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <vctklf$33me0$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 24 Sep 2024 08:02:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3651a7231ef7da6ad04f9fc6816c0f39";
	logging-data="3267008"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18a9Lx8iyl7Q0uXjEXp5tCdSj7T2xRWxbdvKdZ8WAX70Q=="
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:FOlmxT6qjYSMYqIgV2TAMEU42MA=
In-Reply-To: <3b7a257101d09e1995314aadace0e14f@www.novabbs.org>
Bytes: 4222

MitchAlsup1 wrote:
> On Mon, 23 Sep 2024 21:57:08 +0000, Kent Dickey wrote:
>=20
>> In article <O2DHO.184073$kxD8.113118@fx11.iad>,
>> EricP=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 instructi=
on
>> (or a mode for existing ALU instructions) is useless for anything OTHE=
R
>> than as a debug aid where you crash the problem on overflow (you can
>> have a general exception handler to shut down gracefully, but "patchin=
g
>> things
>> up and continuing" doesn't work).=C2=A0 I gave details of reasons folk=
s 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.=C2=A0 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=
=2E
>> 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.=C2=A0 An ALU functional unit that cannot take exceptions d=
oesn'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.=C2=A0 Branches and LD/ST always needs this info, but n=
ot
>> needing it on ALU ops can be a nice simplification of logic, and makes=

>> it
>> easier to have multiple ALU functional units.=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.=C2=A0 ADDTO is particularly what I am arguing
>> against--
>> it is just a bad idea for the ISA to have ALU instructions take
>> exceptions.
>=20
> 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
>=20
> 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=20
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

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