Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: John Ames <commodorejohn@gmail.com>
Newsgroups: comp.lang.forth,comp.arch
Subject: Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)
Date: Tue, 1 Sep 2026 14:31:06 -0700
Organization: A place where nothing fits quite right
Lines: 31
Message-ID: <20260901143106.00006dd7@gmail.com>
References: <87qzk0nejz.fsf@nightsong.com> <116d89d$27baf$1@paganini.bofh.team> <2026Aug24.095510@mips.complang.tuwien.ac.at> <87a4q0afu7.fsf_-_@debian>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 01 Sep 2026 21:31:11 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="2250378"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/3FW2wc/CH6Q3WH/0SEA+Pzb2Seo6yCXk="; posting-host="8c0b8a103aadf988976ffde894443734"
Cancel-Lock: sha1:6rGSO2SZEftF0PQxE8/+RBxskWk= sha256:c9iQZFdo8Wyjxw3sfyI07tM0UlOlT4EAN/tFr7DEbhU= sha1:vrKXW41FERn+kZt3VOFqykwysuU= sha256:K+s+un6TpY6eWesGPKLy+Jy/yVA2b7vOGixBT10gRC0=
X-Newsreader: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32)
Xref: csiph.com comp.lang.forth:135515 comp.arch:117723

On Tue, 01 Sep 2026 17:15:12 -0300
Kragen Javier Sitaker <kragen@canonical.org> wrote:

> > RISC-V follows its ancestor MIPS (from where it also has many
> > mnemonics) in this respect.  For a new way to add the carry
> > functionality without adding a condition code register, read
> >
> > https://www.complang.tuwien.ac.at/anton/tmp/carry.pdf
> >
> > (unpublished). =20
>=20
> This is a fascinating idea.  I guess the MuP21 had a carry bit in
> every =E2=80=9Cgeneral-purpose register=E2=80=9D, making them 21 bits, bu=
t I=E2=80=99ve never
> seen any other architecture do this, nor a version that separates out
> overflow bits from carry bits.
>=20
> I also didn=E2=80=99t realize that (base) RISC-V needed 5 instructions *p=
er
> word* for multi-precision addition.

Hm, that *is* a bit interesting, though the idea of including non-
number info in a numeric register drives me a little crazy. (It is,
admittedly, no weirder than what you already deal with in floating-
point hardware.)

The idea I had last time I dabbled with this stuff was to extend the
basic add/subtract instructions with an option to save the carry/borrow
value in another GPR, instead - but I never gave any thought to how to
represent overflow that way. Hmm.