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: <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>
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 <O2DHO.184073$kxD8.113118@fx11.iad>,
> EricP  <ThatWouldBeTelling@thevillage.com> 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.
<snip>
> 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