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: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 24 Sep 2024 13:18:55 +0300
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <20240924131855.00006dac@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>
	<20240924113703.00002a90@yahoo.com>
	<vctu57$350hh$1@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 12:18:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1fade10e8a2bab21410dad877002ecd";
	logging-data="3291197"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EsyBziHl0GjPcxgSlCW6zPKZJfRTmLkg="
Cancel-Lock: sha1:16pDLqE0MxhIm3IyS5j+xLA+4Iw=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 6286

On Tue, 24 Sep 2024 10:44:22 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Michael S wrote:
> > On Tue, 24 Sep 2024 08:02:23 +0200
> > Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> >  =20
> >> MitchAlsup1 wrote: =20
> >>> 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
> >>>     =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).=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. =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.=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
> >>>> 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.=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
> >>>> 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
> >>>
> >>> I am at a loss for how to take all 3 arguments together at the
> >>> same time !?! Can you explain ?? =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?
> >>
> >> Personally I'm happy with the clang approach.
> >> =20
> >=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. =20
>=20
> If the handler consists of terminating the program, then every
> function, or small group of functions depending upon total code size,
> can have a common target, just so that all the JO opcodes can use the
> short-form two-byte encoding og a forward branch. I.e. leaving just
> 127 bytes available for mainline code.
>=20

In case of clang (on Win7+msys2, I didn't test on other targets) the
handler terminates the program with no useful info printed.
Still, clang has different target for each jo. At target location it
places invalid instruction.
So, it lays infrastructure for better handler, pays the price in terms
of code size, but does not take an advantage.

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

I want address of originating instruction in the handler.=20
I want it not for switch to bigint that would not be in spirit of
non-dynamic compiled languages, but in order to get useful termination
printout.
With JO in order to get what I want I'd have to pay by significant
increase in code size.