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: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 24 Sep 2024 11:37:03 +0300
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <20240924113703.00002a90@yahoo.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 24 Sep 2024 10:36:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1fade10e8a2bab21410dad877002ecd";
	logging-data="3291197"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+jn//TFObigoTPkxflH+cc5iHSGQBQx3M="
Cancel-Lock: sha1:r312mKfejo2bd6Qs4sH6vprfN4c=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4626

On Tue, 24 Sep 2024 08:02:23 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> 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
> >  =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. =20
> >>
> >> 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).=C2=A0 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.=C2=A0 Just that CPUs
> >> should not bother having trap-on-overflow instructions. =20
> > <snip> =20
> >> 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.=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.=C2=A0 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.=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
> >=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 ?? =20
>=20
> 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?
>=20
> 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.

It would be interesting if you answer before looking at what clang does,
then take a look and comment again.

> Terje
>=20