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 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: References: <2024Sep10.094353@mips.complang.tuwien.ac.at>

<3b7a257101d09e1995314aadace0e14f@www.novabbs.org> <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 wrote: >=20 >> MitchAlsup1 wrote: >>> On Mon, 23 Sep 2024 21:57:08 +0000, Kent Dickey wrote: >>> =20 >>>> In article , >>>> EricP=C3=82=C2=A0 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. >>> >>>> 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 - "almost all programming can be viewed as an exercise in caching"