Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135344 > unrolled thread

OT: Epic RISC-V rant

Back to article view | Back to comp.lang.forth

Contents

  OT: Epic RISC-V rant Paul Rubin <no.email@nospam.invalid> - 2026-08-14 22:22 -0700
    Re: OT: Epic RISC-V rant jkn <jkn+nin@nicorp.co.uk> - 2026-08-15 10:10 +0100
    Re: OT: Epic RISC-V rant albert@spenarnc.xs4all.nl - 2026-08-22 18:23 +0200
      Re: OT: Epic RISC-V rant anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 16:45 +0000
    Re: OT: Epic RISC-V rant antispam@fricas.org (Waldek Hebisch) - 2026-08-22 22:36 +0000
      Re: OT: Epic RISC-V rant albert@spenarnc.xs4all.nl - 2026-08-23 13:44 +0200
        Re: OT: Epic RISC-V rant antispam@fricas.org (Waldek Hebisch) - 2026-08-29 19:49 +0000
      Re: OT: Epic RISC-V rant anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-24 07:55 +0000
        adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-01 17:15 -0300
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) John Ames <commodorejohn@gmail.com> - 2026-09-01 14:31 -0700
            Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) BGB <cr88192@gmail.com> - 2026-09-01 17:18 -0500
            Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-02 02:04 +0000
              Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) John Ames <commodorejohn@gmail.com> - 2026-09-02 08:23 -0700
                Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 13:48 -0300
                  Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 18:03 +0000
            Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 11:16 +0000
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-02 01:53 +0000
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 10:50 +0000
            Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Paul Rubin <no.email@nospam.invalid> - 2026-09-09 22:10 -0700
            Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 14:28 -0300
      Re: OT: Epic RISC-V rant antispam@fricas.org (Waldek Hebisch) - 2026-08-29 20:12 +0000
      interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-01 17:00 -0300
        Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-01 20:51 +0000
        Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-02 01:43 +0000
      interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Andy Valencia <vandys@vsta.org> - 2026-09-02 08:11 -0700

Page 1 of 2  [1] 2  Next page →

#135344 — OT: Epic RISC-V rant

https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV

About various flaws in the RISC-V design.  Not since the days of Erik
Naggum have I seen a rant like this.  Bellissimo.

[toc] | [next] | [standalone]

#135345

On 15/08/2026 06:22, Paul Rubin wrote:
> https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV
> 
> About various flaws in the RISC-V design.  Not since the days of Erik
> Naggum have I seen a rant like this.  Bellissimo.


Thanks for the link - I can see why you posted it here, heh heh...

[toc] | [prev] | [next] | [standalone]

#135387

In article <87qzk0nejz.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV
>
>About various flaws in the RISC-V design.  Not since the days of Erik
>Naggum have I seen a rant like this.  Bellissimo.

If Intel can make i86 work, then the concerted efforts of the
Chinese economy can make RISC-V work.
If they can make a thorium reactor work, they can make RISC-V work.
It is showing already.
All the under 10 cent risc-v chips have already 1000% overkill
for most tasks. The economics of not paying royalties and
being invulnerable to USA tactics count for much incentive.

I find the [ebx + esi * 4] example particular unconvincing.
A decent compiler results in
     Rd = [Rs]
     Rs +:= 4

21 cycle interrupt latency doesn't say much if the
clock speed is approaching 100 Mhz.

Having no way to inspect capabilities is probably a manco.
An instruction like the CPUID is missing. Had the 8086
a CPUID instruction? (You know the answer.)
The first transputers had no way to identify
themselves, that came later.

Standardization of addresses of peripherals.
I had no problem with the DongshanNezha board (running linux) to
select an io pin, set it a the midi frequency (30 Khz or so) and play
the Fig Leaf Rag (Scott Joplin) on my keyboard.
(The classic midi interface is brilliant, you only use on resistor
and wiring and the grounds are isolated, unlike USB).
It is a matter of documentation.

I'm working on a RISC-V Forth optimiser, after giving up
on i86. Conflicts in the compressed instructions?
I don't even consider the compressed instruction
codes. I rejoice by seeing a plethora of registers.
We'll see.

I do development work on a Orange RISC-V an under 100
euro machine with 8 cores 8 GByte and a ssd disk,
case, power supply and fan included).
I log in from my main machine, and install all the same tools
for RISC-V ciforth as in my main machine.
I test the assemblers (8080, 8086, 8038, pentium, amd, alpha,
6809, riscv) same on that machine.
Then I disassemble my AMD forth and reassemble it to the exact
same code. Panic! The test fails until I realize that
an AMD Forth doesn't run on RISC-V ...

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#135391

albert@spenarnc.xs4all.nl writes:
>If they can make a thorium reactor work, they can make RISC-V work.

There is no Thorium reactor, only a Thorium fuel cycle, which is even
more uneconomical than mainstream nuclear power, if they manage to
make it work at all.  For the THTR-300 (read
<https://de.wikipedia.org/wiki/Kernkraftwerk_THTR-300>, using a
translation service if necessary; it is much more informative than the
article in en.wikipedia.org) <30% of the energy it produced were due
to the Thorium fuel cycle, the rest came from U-235).  Looking at
<https://en.wikipedia.org/wiki/TMSR-LF1>, its fuel consists of Uranium
with 19.75% U-235 (i.e., 80% U-238) and Thorium.  Given that the
THTR-300 used Uranium with 95% U-235, I expect that the contribution
from Thorium in the TSMR-LF1 will be even less.

However, the Chinese are very strong and have a good growth path on
wind and especially solar power, with more than twice the amount of
wind power than nuclear power in 2025, and also more than twice the
amount of solar power than nuclear power.  Solar power surpassed
nuclear power in 2022, wind power surpassed it in 2013
<https://en.wikipedia.org/wiki/Renewable_energy_in_China#Renewable_electricity_overview>.

Back to the RISC-V rant: It's interesting that RISC-V acquired some
warts from the start.  I doubt that these warts will prevent it from
succeeding.  The winner-takes-all principle may, but we will have to
see about that.

In any case, a pointer to that rant might have received more interest
in comp.arch.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135396

Paul Rubin <no.email@nospam.invalid> wrote:
> https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV
> 
> About various flaws in the RISC-V design.  Not since the days of Erik
> Naggum have I seen a rant like this.  Bellissimo.

Some comments.

1) Interrupt latency claim is half-truth.  First, normal RISC-V has
32 registers while ARM has 16.  If you can do with 16 registers
divide register set into 2 parts, use one part for normal code
and the other for interrupt handler.  That way you will get few
cycle overhead, impossible feat for Cortex M.  So it is really
a tradeof, do you want to have modest overhead for pretty
typical use case or do you for very low overhead in cases that
need it and higher overhead for typical cases.

2) What he writes about irregulaties in instruction encodings looks
really bad.  OTOH that should mostly affect programmer tools, that
is compilers, assemblers, debuggers.  And there is gcc port.  There
is other software (including ciforth).  So to me it is not clear if
this aspect will lower RISC-V adoption.

3) Missing instructions.  I am disappointed that to get effect of
2 word add (with carry between words) one needs 5 instructions.
But other machines disappointed me by making some instructions
slow, frequently slow enough that there is no speed benefit from
using them.  Also, once instrutions in in architecture there is
hard to get rid of it.  You get legacy of binaries using such
instruction and if you try to remove it those binaries will no
longer work.  OTOH adding instructions is easy.  So it is
natrual that new architecture start with small instruction set
and needed things get added when need is clear.

4) Code density.  Various people claim that some RISC-V features
lead to lower code density.  But all that I saw indicates that
RISC-V has very good code density.  Cortex M too has good code
density and they seem to be close one to another, with RISC-V
frequently being slightly better.  So, while code density
probably will not be deciding factor it certainly will not
prevent adaption of RISC-V (which could easily happen with less
dense encoding).  Mitch Asup in comp.arch claim that his
architecture routinly need about 30% less instructions than
RISC-V to do the same task.  But with code size his archiecture
seem be about even.  So for bigger machines it is mainly
question how well instruction fusion will work.

5) Optionality.  I do not like it and it is probably biggest
problem of RISC-V.  OTOH to have any chance of success RISC-V
need a buy-in from several independent parties.  I suspect that
the only practical way to get consensus from varied parties is
by making most of specification optional.  It is likely that
in the future modest number of variations will dominate.  In
microcontoller world I see 2 variations, and modest number for
bigger cores.  RISC-V may loose if vendors will push too many
variations.


-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#135401

In article <116d89d$27baf$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV
>>
>> About various flaws in the RISC-V design.  Not since the days of Erik
>> Naggum have I seen a rant like this.  Bellissimo.
>
>Some comments.
>
<SNIP>
>4) Code density.  Various people claim that some RISC-V features
>lead to lower code density.  But all that I saw indicates that
>RISC-V has very good code density.  Cortex M too has good code
>density and they seem to be close one to another, with RISC-V
>frequently being slightly better.  So, while code density
>probably will not be deciding factor it certainly will not
>prevent adaption of RISC-V (which could easily happen with less
>dense encoding).  Mitch Asup in comp.arch claim that his
>architecture routinly need about 30% less instructions than
>RISC-V to do the same task.  But with code size his archiecture
>seem be about even.  So for bigger machines it is mainly
>question how well instruction fusion will work.

I presume that code density is dependant on the normal
or condensed instruction set. Where are you referring to?
>
>
>--
>                              Waldek Hebisch
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#135481

albert@spenarnc.xs4all.nl wrote:
> In article <116d89d$27baf$1@paganini.bofh.team>,
> Waldek Hebisch <antispam@fricas.org> wrote:
>>Paul Rubin <no.email@nospam.invalid> wrote:
>>> https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV
>>>
>>> About various flaws in the RISC-V design.  Not since the days of Erik
>>> Naggum have I seen a rant like this.  Bellissimo.
>>
>>Some comments.
>>
> <SNIP>
>>4) Code density.  Various people claim that some RISC-V features
>>lead to lower code density.  But all that I saw indicates that
>>RISC-V has very good code density.  Cortex M too has good code
>>density and they seem to be close one to another, with RISC-V
>>frequently being slightly better.  So, while code density
>>probably will not be deciding factor it certainly will not
>>prevent adaption of RISC-V (which could easily happen with less
>>dense encoding).  Mitch Asup in comp.arch claim that his
>>architecture routinly need about 30% less instructions than
>>RISC-V to do the same task.  But with code size his archiecture
>>seem be about even.  So for bigger machines it is mainly
>>question how well instruction fusion will work.
> 
> I presume that code density is dependant on the normal
> or condensed instruction set. Where are you referring to?

For code density I consider compressed extention.  Note that
unlike say early Thumb this in not an alternative instruction
set, you can freely mix normal and compressed instructions
(without things like ARM "interworking").

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#135408

antispam@fricas.org (Waldek Hebisch) writes:
>2) What he writes about irregulaties in instruction encodings looks
>really bad.  OTOH that should mostly affect programmer tools, that
>is compilers, assemblers, debuggers.  And there is gcc port.  There
>is other software (including ciforth).  So to me it is not clear if
>this aspect will lower RISC-V adoption.

It also affects the hardware.  More instruction formats means more
transistors, i.e., are needed to implement this architecture, and
possibly more gate delays in decoding.

Concerning programming tools, everything that has to deal with
binaries is affected.  Compilers that emit binary code directly rather
than going through assemby language (e.g., Forth compilers),
assemblers, linkers, disassemblers.  There is a reason why, even in
embedded space, having a toolchain is seen as a strong competetive
advantage.

>3) Missing instructions.  I am disappointed that to get effect of
>2 word add (with carry between words) one needs 5 instructions.

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).

>OTOH adding instructions is easy.  So it is
>natrual that new architecture start with small instruction set
>and needed things get added when need is clear.

Well, adding also has its drawbacks: Programs that use the added
instructions won't work on the old hardware, so everybody avoids using
them for a decade or so at least (in the Linux world, distributions
start compiling the code to use AVX around now, 15 years after Intel
introduced AVX (although Intel's non-implementation or disabling of
AVX on lower-end CPUs probably delayed the process for many years).

So, ideally you would start with the right instructions already
present.

>4) Code density.  Various people claim that some RISC-V features
>lead to lower code density.  But all that I saw indicates that
>RISC-V has very good code density.

Definitely.  RV64GC has the best code density of all 64-bit
architectures in my code density measurements, and roughly ties with
ARM T32, but that is only a 32-bit architecture, which tends to result
in smaller code.

>5) Optionality.

Similar to option extension word sets and other options in the Forth
standards.

>It is likely that
>in the future modest number of variations will dominate.  In
>microcontoller world I see 2 variations, and modest number for
>bigger cores.

RV64GC has been the dominant set for bigger systems, and now there is
a strong push for RVA32 (which is RV64GC plus some additional
extensions).

In the Forth world, the large systems have implemented nearly all
words from all optional wordsets (and in the meantime out of the box),
and the smaller systems implement whatever words they want, without
consideration of whether the words are CORE or extensions, and they
don't implement the words they don't want, even if they are in CORE.

CORE is mainly used as a target in proof-of-concept work.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135511 — adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> 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).

This is a fascinating idea.  I guess the MuP21 had a carry bit in every
“general-purpose register”, making them 21 bits, but I’ve never seen any
other architecture do this, nor a version that separates out overflow
bits from carry bits.

I also didn’t realize that (base) RISC-V needed 5 instructions *per
word* for multi-precision addition.

Thank you for sharing your draft!

Kragen

[toc] | [prev] | [next] | [standalone]

#135515 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

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).  
> 
> This is a fascinating idea.  I guess the MuP21 had a carry bit in
> every “general-purpose register”, making them 21 bits, but I’ve never
> seen any other architecture do this, nor a version that separates out
> overflow bits from carry bits.
> 
> I also didn’t realize that (base) RISC-V needed 5 instructions *per
> 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.

[toc] | [prev] | [next] | [standalone]

#135516 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

On 9/1/2026 4:31 PM, John Ames wrote:
> 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).
>>
>> This is a fascinating idea.  I guess the MuP21 had a carry bit in
>> every “general-purpose register”, making them 21 bits, but I’ve never
>> seen any other architecture do this, nor a version that separates out
>> overflow bits from carry bits.
>>
>> I also didn’t realize that (base) RISC-V needed 5 instructions *per
>> 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.
> 

In my case, for my XG3 ISA, which could nominally be considered a RISC-V 
extension, I ended up re-adding the SR.T and ADC/ADDC mechanism that my 
ISA originally inherited from SuperH.

Granted, this still doesn't address the issue for RISC-V proper.


As for me, adding extra/hidden bits to registers is not an idea I take 
fondly...



( Meanwhile, still dealing with hassles from the unresolved issue of my 
Twitter/X account having been hacked... And the account recovery process 
being very much unhelpful about it... Debatable actually if there are 
any real people in the loop, or if maybe it is just Grok dealing with it 
and sending out boilerplate responses or similar. )

[toc] | [prev] | [next] | [standalone]

#135521 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

John Ames <commodorejohn@gmail.com> posted:

> 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).  
> > 
> > This is a fascinating idea.  I guess the MuP21 had a carry bit in
> > every “general-purpose register”, making them 21 bits, but I’ve never
> > seen any other architecture do this, nor a version that separates out
> > overflow bits from carry bits.
> > 
> > I also didn’t realize that (base) RISC-V needed 5 instructions *per
> > 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.

That is what CARRY does. The Rd register in CARRY supplies a register
used to carry the additional values from calculation to calculation.
The Immediate in CARRY selects which instruction consume Rd {i},
which instructions generate the next Rd {o} and which do both {io}
and which do neither {}.

For ADD, carry Rd contains only 1 bit, but for others, it contains
"all the bits that did not make it into the standard result". This
makes CARRY suitable for all integer multiprecision arithmetic and
for significant quantities of FP arithmetic.

Standard integer calculations {ADD, MUL, DIV, SL, SR, ROL, ROR, PERM,
and a few more esoteric ints}

CARRY {o}  IMUL produces a 128-bit result
CARRY {i}  IMUL performs IMAC
CARRY {io} IMUL performs IMAC producing a 128-bit result

Multi-precisions shifts use carry

IEEE 754 augmented FADD and FMUL use CARRY
> 

[toc] | [prev] | [next] | [standalone]

#135527 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

On Wed, 02 Sep 2026 02:04:51 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

> > 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.  
> 
> That is what CARRY does. The Rd register in CARRY supplies a register
> used to carry the additional values from calculation to calculation.
> The Immediate in CARRY selects which instruction consume Rd {i},
> which instructions generate the next Rd {o} and which do both {io}
> and which do neither {}.
> 
> For ADD, carry Rd contains only 1 bit, but for others, it contains
> "all the bits that did not make it into the standard result". This
> makes CARRY suitable for all integer multiprecision arithmetic and
> for significant quantities of FP arithmetic.
> [...]
> Multi-precisions shifts use carry

Yes, exactly - add/subtract set the designated overflow/carry register
to 1 on a carry/borrow (which can then be added/subtracted from the next
more significant word) but e.g. multiply can set it to the whole most-
significant half of the product, multi-place shifts can catch all the
bits that fall off one end in the other so that rotate becomes shift-
and-OR, etc. Very flexible, especially if you have the capability to
branch on the value of a GPR.

[toc] | [prev] | [next] | [standalone]

#135666 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

John Ames <commodorejohn@gmail.com> writes:
> On Wed, 02 Sep 2026 02:04:51 GMT
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>> For ADD, carry Rd contains only 1 bit, but for others, it contains
>> “all the bits that did not make it into the standard result”. This
>> makes CARRY suitable for all integer multiprecision arithmetic and
>> for significant quantities of FP arithmetic.
>> [...]
>> Multi-precisions shifts use carry
>
> Yes, exactly - add/subtract set the designated overflow/carry register
> to 1 on a carry/borrow (which can then be added/subtracted from the next
> more significant word) but e.g. multiply can set it to the whole most-
> significant half of the product, multi-place shifts can catch all the
> bits that fall off one end in the other so that rotate becomes shift-
> and-OR, etc. Very flexible, especially if you have the capability to
> branch on the value of a GPR.

A bit-shift operation with two source registers is sometimes called a
“funnel shift”, which is sort of the inverse of this:
<https://www.eevblog.com/forum/programming/funnel-shifter-where-are-useful/>
<https://stackoverflow.com/questions/12767113/funnel-shift-what-is-it>
<https://github.com/rust-lang/rust/issues/145686>

That is, instead of one source register (for a given bit shift size) and
two destination registers, a funnel shift has two source registers (plus
the amount to shift) and possibly just one destination register.

An interesting thing about funnel shifts is that, if both source
registers are the same, it provides bit rotation, not just shift.
Conceivably you could get the same result from this inverse funnel
shift, depending on how you handle the case where the destination
register is the same as the CARRY register.

Kragen

[toc] | [prev] | [next] | [standalone]

#135670 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

Kragen Javier Sitaker <kragen@canonical.org> posted:

> John Ames <commodorejohn@gmail.com> writes:
> > On Wed, 02 Sep 2026 02:04:51 GMT
> > MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> >> For ADD, carry Rd contains only 1 bit, but for others, it contains
> >> “all the bits that did not make it into the standard result”. This
> >> makes CARRY suitable for all integer multiprecision arithmetic and
> >> for significant quantities of FP arithmetic.
> >> [...]
> >> Multi-precisions shifts use carry
> >
> > Yes, exactly - add/subtract set the designated overflow/carry register
> > to 1 on a carry/borrow (which can then be added/subtracted from the next
> > more significant word) but e.g. multiply can set it to the whole most-
> > significant half of the product, multi-place shifts can catch all the
> > bits that fall off one end in the other so that rotate becomes shift-
> > and-OR, etc. Very flexible, especially if you have the capability to
> > branch on the value of a GPR.
> 
> A bit-shift operation with two source registers is sometimes called a
> “funnel shift”, which is sort of the inverse of this:
> <https://www.eevblog.com/forum/programming/funnel-shifter-where-are-useful/>
> <https://stackoverflow.com/questions/12767113/funnel-shift-what-is-it>
> <https://github.com/rust-lang/rust/issues/145686>
> 
> That is, instead of one source register (for a given bit shift size) and
> two destination registers, a funnel shift has two source registers (plus
> the amount to shift) and possibly just one destination register.
> 
> An interesting thing about funnel shifts is that, if both source
> registers are the same, it provides bit rotation, not just shift.
> Conceivably you could get the same result from this inverse funnel
> shift, depending on how you handle the case where the destination
> register is the same as the CARRY register.

Yes, CARRY is how one gets shift double-wide in My 66000. So, when we
added Rotates, we use a length field (rather than a 2^(3+n) specifier)
so, one can rotate a 6-bit field or a 19-bit field in either direction.
 
> Kragen

[toc] | [prev] | [next] | [standalone]

#135626 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

John Ames <commodorejohn@gmail.com> writes:
>Hm, that *is* a bit interesting, though the idea of including non-
>number info in a numeric register drives me a little crazy.

The Carry bit is bit 64 of the addition or subtraction of the
zero-extended operands.

Concerning the signed oVerflow bit, one could store bit 64 of the
addition or subtraction of sign-extended operands instead of the
overflow bit, and then check for a signed overflow by checking if this
bit 64 is different from bit 63.  In that way that bit would also be a
"number info".

However, one advantage of storing an overflow bit (i.e., the result of
this xor) is that we can then combine these bits with "or" or "and".

>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

That has the disadvantage of occupying a write port in the register
set and in the renamer.

>- but I never gave any thought to how to
>represent overflow that way. Hmm.

A GPR has many bits:-)

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135520 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

Kragen Javier Sitaker <kragen@canonical.org> posted:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > 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).
> 
> This is a fascinating idea.  I guess the MuP21 had a carry bit in every
> “general-purpose register”, making them 21 bits, but I’ve never seen any
> other architecture do this, nor a version that separates out overflow
> bits from carry bits.

In comparison, My 66000 can perform multi-wide addition using the CARRY
instruction-modifier.

add256:  //R1-R4=Operand 1 R5-R87=Operand 2
         CARRY R9,{{o}{io}{io}{i}}
         ADD   R1,R1,R5             // {o} generates output
         ADD   R2,R2,R6             // {io} consumes input generates output
         ADD   R3,R3,R7             // {io} consumes input generates output
         ADD   R4,R4,R8             // {i}  consumes input
                                    // R9 may or may not have been written
         RET
       
> I also didn’t realize that (base) RISC-V needed 5 instructions *per
> word* for multi-precision addition.

While My 66000 only needs 1+epsilon per DoubleWord.
 
> Thank you for sharing your draft!
> 
> Kragen

[toc] | [prev] | [next] | [standalone]

#135625 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

Kragen Javier Sitaker <kragen@canonical.org> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> 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).
>
>This is a fascinating idea.  I guess the MuP21 had a carry bit in every
>"general-purpose register", making them 21 bits,

<https://www.ultratechnology.com/mup21.html> says this:

|Internally, MuP21 maintains a 21 bit data/address bus. The MSB bit 20
|is the carry bit in ALU operations.

And it mentions an instruction JCZ without explaining it, but given
that it also has JZ, and the existance of C0 below, I expect that JCZ
is "jump if carry is zero", while JZ corresponds to T0 (jump if T0-T19
is false).

That's pretty much it.  I see on
https://www.ultratechnology.com/f21data.pdf that instruction 03,
called C0 jumps if T20 (bit 20 of the TOS) is false, and that the
Forth source would look like "CARRY? IF".  F21 is a further
development of uP21.

<https://www.ultratechnology.com/mup21.html> has the instruction JCZ

>Thank you for sharing your draft!

I should finally polish it up with all the parts I left away thanks to
page limits and publish it on arxiv.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135641 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> I should finally polish it up with all the parts I left away thanks to
> page limits and publish it on arxiv.

I remember we had a discussion of this idea here on clf, some of which
spilled to comp.arch.  I don't know if it contained anything that would
be useful in your paper that's not already in it.

[toc] | [prev] | [next] | [standalone]

#135668 — Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Kragen Javier Sitaker <kragen@canonical.org> writes:
>>Thank you for sharing your draft!
>
> I should finally polish it up with all the parts I left away thanks to
> page limits and publish it on arxiv.

I agree wholeheartedly.

Kragen

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web