“Risc V greatly underperforms”

Carry flag and overflow checking? We don't need those things because C doesn't support it! That sadly seems to be the kind of thought process behind RISC-V, and a lot of other "modern" computing:

Everything should be written in C, or some scripting language implemented in C. Writing safe code is easy, just wrap everything in layers of macros that the compiler will magically optimize away, and if it doesn't, computers are fast enough anyway, right? The mark of a real programmer is that every one of their source files includes megabytes of headers defining things like __GNU__EXTENSION_FOO_BAR_F__UNDERSCORE_.

You say your processor has a single instruction to do some extremely common operation, and want to use it? You shouldn't even be reading a processor manual unless you are working on one of the two approved compilers, preferably GCC! If you are very lucky, those compiler people that are so much smarter than you could hope to be, have already implemented some clever transformation that recognizes the specific kind of expression produced by a set of deeply nested macros, and turns them into that single instruction. In the process, it will helpfully remove null pointer checks because you are relying on undefined behaviour somewhere else.

You say you'll do it in assembly? For Kernighan's sake, think about portability!!! I mean, portable to any other system that more or less looks the same as UNIX, with a generous sprinkling of #ifdefs and a configure script that takes minutes to run.

Implement a better language? Sure, as long as the compiler is written in C, preferably outputs C source code (that is then run through GCC), and the output binary must of course link against the system's C library. You can't do it any other way, and every proper UNIX - BSD or Mac OS X - will make it literally impossible by preventing syscalls from any other piece of code.

IMO this is like a cultural virus that seems to have infected everything IT-related, and I don't exactly understand why. Sure, having all these layers of cruft down below lets us build the next web app faster, but isn't it normal to want to fix things? Do some people actually get a sense of satisfaction out of saying "It is a solved problem, don't reinvent the wheel"? Or do they want to think that their knowledge of UNIX and C intricacies is somehow the most important, fundamental thing in computer science?

> It's certainly possible that another compressed encoding might do better using fewer opcode, and I've seen the suggestions. The main thing wrong with the standard one in my opinion is that it gives too much prominence to floating point code, having been developed to optimise for SPEC including SPECFP (no, not the Linux kernel or Dhrystone ... I have no idea where you got that from).

Javascript is limited to 64-bit floats as is lua and a couple other languages.

Sure, you can optimize to 31/32-bit ints, but not always and not before the JIT warms up.

> What sticks in my mind from my limited exposure to SuperH is that there's no load immediate instruction, so you have to do a PC-relative load instead.

SuperH has a mov #imm, Rx that can take an 8-bit #imm. But you're right, literal pools were used just like on ARM.

Things I liked about SuperH: 16 bit fixed-width insn format (except for some SH2A and DSP ops), T flag for bit manipulation ops, GBR to enable scaled loads with offset, xtrct instruction, single-cycle division insns (div0, div1), MAC insns.

In terms of code density SH was quite effective, see here http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_dens... or here http://www.deater.net/weave/vmwprod/asm/ll/ll.html

> I encourage anyone to open the original document published in 2011 [1] and compare it with current RISC-V specification documents [2].

And for extra credit, look how much it changed with respect to the thing that's being discussed around this submission. Integer arithmetic and carry or overflows in base ISA. Carry flag, add? Sltu? Oh right, the base ISA hasn't changed so much after all.

> Moreover, it mainly consists of the basic RISC-V ISA which is indeed designed to be simple and minimalist, whereas the current RISC-V full spec. consists of a multitude of extensions.

Hand waving about 10 years of extensions and shuffling things around does little to address criticism concerning the base ISA. Hilariously so when these extensions fail to address the criticism at all.

Still no analysis either. I'm not going to call out misinformation in a post free of information.

wasm functions must have a fixed number of results[1]. Lisp functions may have variadic results. A wasm function call must explicitly pop every result off of the stack[2].

These rules add significant overhead to implementing:

  (foo (bar))

Which calls foo with just the first result of bar, and the number of results yielded by bar is possibly unknown.

In psuedo-assembly for a register machine, implementing this is roughly:

  CALL bar
  MOVE ResultReg1 -> ArgumentReg1
  CALL foo

And this works regardless of how many values the function bar happens to return[3].

Any implementation that is correct for any number of results of "bar" will be slow for the common case of bar yielding one or two results.

1: https://webassembly.github.io/spec/core/syntax/types.html#sy...

2: https://webassembly.github.io/spec/core/exec/instructions.ht...

3: Showing only the caller side of things, when the caller doesn't care about extra values hides some complexity of implementation of returning values because you also need to be able to detect at run-time how many values were actually returned. e.g. SBCL on x86 uses a condition flag to indicate if there are multiple values, because branching on a condition flag lets you handle the only-1 value case efficiently.