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: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Mon, 23 Sep 2024 17:51:26 -0400
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <jwvldzikq9m.fsf-monnier+comp.arch@gnu.org>
References: <vbd6b9$g147$1@dont-email.me>
	<09ce1622b872f0b0fa944e868a8c97be@www.novabbs.org>
	<vbnisc$2hb59$1@dont-email.me>
	<2024Sep10.094353@mips.complang.tuwien.ac.at>
	<vckf9d$178f2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 23 Sep 2024 23:51:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4b01e9bc3f3192bb258d057b1367074c";
	logging-data="3025851"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18WtN4Hau5EXkjttxzV2mtovZ9OdoNl2IQ="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:BiMG1/kheAdP/RhmVQvCGJPPduQ=
	sha1:Ecxbt/PCPHRVbVQrXuGNEHfAMb8=
Bytes: 3465

> Let's look at how you might want to handle overflows when they happen:
>
> 1) Your language supports seemlessly transitioning to BigInts on
> 	overflow.  Then each operation that could overflow needs to call
> 	a special bit of code to change to BigInt and then continue the
> 	calculation.  This code must exist, even if a trapping
> 	instruction doesn't need an explicit branch to it.  Some
> 	mechanism is needed to call this code.

IOW, this is the case where the program thinks it's manipulating some
"mathematical number ∈ Z" or something like it.

> 2) You need to call an exception handler, and the routine with the overflow
> 	is ended.  We need to know which exception handler to call.

Not sure when that would be useful, other than for low-level coding.

> 3) You want to clamp the value to a reasonable range and continue.  The
> 	reasonable values need to be looked up somewhere.

Here overflow detection can be useful only to the extent that the
wrap-around may hide the range-error (or confuse its nature between
over<->under).

I'm not familiar with code needing this, but I heard such needs are
common in some fields.

> 4) You just want to crash the program.  If a debugger is attached, it can
> 	say where the overflow occurred.

Beside debugging, this corresponds to the case where the code thinks
it's manipulating some "mathematical number ∈ Z" or something like it
yet we have a good reason to think that this number will "never"
overflow, so we never want to switch to bigint because an overflow means
our "good reason" was crap and we we're in trouble anyway.

IME, this shows up typically for integers related to the size of some
data-structure, where the limited address space "guarantees" that we'll
never go beyond some limit.  They're *very* common (think array indices
and things like that) and using overflow-trapping operations for them
would make sense.  At the same time, they *should* never overflow, and
if some error somewhere means one of them can overflow (e.g. mistakenly
using (u)int32 for array indices in a 64bit system), there's a good
chance that the error will cause other trouble which may prevent us from
even reaching the overflowing operation.


        Stefan