Sujet : Instruction counts (was: Decrement And Branch)
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.archDate : 16. Aug 2024, 06:23:30
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2024Aug16.072330@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6
User-Agent : xrn 10.11
mitchalsup@aol.com (MitchAlsup1) writes:
And RISC-V ends up with over 448 instructions
How do you count this? Looking at chapter 19 of
https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf, I
count for RV64G:
47 RV32I
15 RV64I additional instructions
8 RV32M
5 RV64M additional instructions
11 RV32A
11 RV64A additional instructions
26 RV32F
4 RV64F additional instructions
26 RV32D
6 RV64D additional instructions
---------------------------------
159 RV64G
whereas My 66000 has but 65.
There are also One-instruction set computer designs
<
https://en.wikipedia.org/wiki/One-instruction_set_computer>, and by
that metric they are the best, no?
The main thing I dislike about Celio's talk and work is that he uses
the same metric for advocating his approach without giving any reason
why it should be relevant.
He also makes the mistake of using instruction count for discerning
between RISC and non-RISC (which would make the PDP-11, 6502 and
probably 8086 more RISC than RV64G) instead of using John Masheys
approach of identifying common traits; and instruction count was not
among the criteria that John Mashey identified as discerning between
RISC and non-RISC (not surprising given non-RISCs like PDP-11).
Patterson (who is also on that paper and who failed to define RISC
when he wrote the papers that introduced the term) makes the same
mistake when arguing for his vector approach (which, I think, resulted
in RV64V) over the approach taken in, e.g., AVX512. So maybe Celio
just was Patterson's voice in his talk, but he appeared to speak his
conviction.
- anton
-- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>