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


Groups > comp.lang.forth > #135408

Re: OT: Epic RISC-V rant

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: OT: Epic RISC-V rant
Date 2026-08-24 07:55 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2026Aug24.095510@mips.complang.tuwien.ac.at> (permalink)
References <87qzk0nejz.fsf@nightsong.com> <116d89d$27baf$1@paganini.bofh.team>

Show all headers | View raw


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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web