Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Mon, 23 Sep 2024 22:17:02 +0000 Organization: Rocksolid Light Message-ID: <3b7a257101d09e1995314aadace0e14f@www.novabbs.org> References: <2024Sep10.094353@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="3205687"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 X-Rslight-Site: $2y$10$yviOdXQT8889xPkKa4OoN.qf6X0Zxa5WBkforBXqlBM0HbgfyMPTK Bytes: 3422 Lines: 50 On Mon, 23 Sep 2024 21:57:08 +0000, Kent Dickey wrote: > In article , > EricP wrote: >>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). 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. Just that CPUs 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. 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. 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. 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. ADDTO is particularly 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 ?? > Kent