RISC-V Stumbling Blocks | Hacker News Reader

RISC-V Stumbling Blocks

x86.lol

123 pointslelf85 comments

I wrote an educational simulator for RISC-V [0] two and a half years ago and the documentation for RISC-V has gotten marginally better. There a fair number of universities using RISC-V to teach that have published their slides and such publicly [1]. However those is not super helpful for people who already understand assembly and computer architecture reasonably well. The best way I can see to get up to speed is to read some example demonstrating each instruction. I have thought about a site that has a table of instructions that links to an online simulator [2] to let you step through an example detailing edge cases.

The best source of simple assembly examples I know of would be the tests from my project [3]. Though those could be a lot more helpful for a human reading them.

As for simulators, there are quite a few. The website lists a bunch [4]. I am not sure how many would support any kind of machine mode memory mapping though.

[0]: https://github.com/TheThirdOne/rars

[1]: https://github.com/riscv/riscv-teach

[2]: https://venus.cs61c.org/

[3]: https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d...

[4]: https://riscv.org/software-status/

I just tried the Project Trellis open source FPGA tool chain for RISC-V. I was forced into it: a few years ago I bought the Lattice ECP5-5G Versa Dev kit (on sale at the time for $99, $200 now I think). The Lattice tools for the FPGA on this board requires a license. Well the license ran out, and I don't want to pay $900 for a Diamond license.

Anyway, I got this example from Project Trellis to work on this board. It uses this "PICO RISC-V" (the entire CPU is in a single Verilog file):

https://github.com/SymbiFlow/prjtrellis/tree/master/examples...

I think it would be straightforward to build a Linux capable RISC-V system for this board using this free tool chain. The board has SDRAM, FTDI UART and SPI-flash. It does not have an SD slot, but maybe could be wired in with the expansion headers.

This ULX3S board also looks promissing, but is not available yet:

https://www.crowdsupply.com/radiona/ulx3s

What's very cool is that low end ECP5 FPGAs are around $5. I think RISC-V on an ECP5 with LCD touch interface might be the cheapest available option for a Linux microcontroller with a touch LCD interface. By available, I mean where you can easily buy the chips on mainstream distributors (otherwise it would for sure be some AllWinner chip).

A RISC-V linux system for the ECP5 can be built with the FOSS toolchain using vexriscv and litex:

https://github.com/litex-hub/linux-on-litex-vexriscv

also, step by step using a different core (rocket): https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-build-a...

I'm amazed to see the preferred toolchain for LiteX for ECP5 listed as "Yosys/Trellis/Nextpnr" (and vendor proprietary tools for the other families).

The rocket core mentions 102% of space used of an 85K LUT FPGA and having to deal with it. I wonder which core is using so much space? I have more experience with vendor soft cores, and they would use much less..

This:

> If you want to do any OS work, you need a system that implements the Privileged ISA. Supporting the Privileged ISA is synonymous to being able to run UNIX-like systems, because it brings user-/supervisor-mode distinction and paging. Working on real hardware is generally preferred to working in emulators, because the code eventually has to run on metal anyway and emulators can be too forgiving for certain classes of problems. There is a plethora of RISC-V microcontrollers for a couple of dollars that all don’t support the Privileged ISA. At the time of writing, the only board you can buy that does support it is the $1000 HiFive Unleased, which was beyond my “I just want to play around with this” budget.

Suggests to me that it's at least part of why Stephen Marz [0] isn't trying to target a specific board with his project (which has been posted here a few times and I'm sorta following along). That pretty much kills most of the interest in RISC-V that I had in me.

I guess I'll wait a few more years and check back again later.

[0]: https://osblog.stephenmarz.com/index.html

For some reason, people have a fantasy that RISC-V is going to give them a sub-dollar microcontroller that runs Linux, rather than being like ARM where "microcontroller" and "Linux capable" and "server grade" are three entirely different market segments.

I have several ARM dev boards and am thinking of getting a PinePhone, am happy to pay upto $200 for something to play with but not $1000.

The HiFive Unleashed is interesting in that it has a lot more RAM than cheap ARM dev boards, for the same money though I could get a HoneyComb LX2K ARM system.

Not for the same money, for much cheaper.

HiFive Unleashed is $1000 for the board with onboard RAM… but it does not have PCIe onboard, so if you want that, you could pay $2000 extra (!!) for the "HiFive Unleashed Expansion Board" that has a giant FPGA that has a PCIe root complex programmed on it.

HoneyComb LX2K is $750 for the board with 64GB eMMC + bring your own SODIMMs for RAM.

SolidRun also offers the MACCHIATObin for $339. 4-core A72 + 4GB full-size DIMM included. (The single-channel-ness of the RAM is not good for performance, but you can install a big 16GB DIMM no problem.) Both the LX2K and the mcbin have PCIe of course :)

I've never met anyone who believed that RISC-V was going to give them a sub-dollar microcontroller that ran Linux before. That seems like a fairly unreasonable expectation, given today's market and RISC-V's position in it.

I've met folks like that - ones who're getting ready to bet the farm on RISC-V taking-over not merely IoT, but mobile devices (phones, tablets, watches, wearables)

Are there sub-dollar ARM microcontrollers that run Linux? Anyway there are a bunch of cheap (not sub-dollar, but sub $30) RISC-V chips coming out of China this year which will run Linux.

Not quite, but the "Linux business card" that went round recently uses the F1C100s, which is $3.50 including RAM in package. https://www.thirtythreeforty.net/posts/2019/12/my-business-c...

According to this link, the F1C100s has 32 Mbytes (!) of DRAM, which is pretty amazing for $1.42 USD in small quantities: https://www.cnx-software.com/2018/08/17/licheepi-nano-cheap-...

This is untrue. Hifive1 supports the privileged instructuons and comes with machine mode and user mode. Cost is ~50$

Linux and other UNIX-like systems (with virtual address space and the like) need Supervisor mode (S-mode), not just U+M mode.

TBF Intel's x86 documentation has evolved incrementally over the last 40+ years. And it comes from an older tradition of engineering documentation which seems to have fallen by the wayside over the last 20 years or so. At an extreme, some ARM vendors like Mediatek don't even produce data sheets, as their model is one of chip+consulting.

The riscv people missed some serious opportunities for fundamental improvements, probably the last such opportunity in this generation.

Perhaps the biggest was that the comparison instruction should have had the condition being looked for in the instruction, and put the result in register 0 as a 0 or ~0 (= -1). Register renaming can then carry it through pipelines. Subsequent instructions may AND register 0 with other values, or subtract it from them, avoiding frequently mispredicted branches.

I am not quite understanding the missed improvement you are talking about.

Are you saying that instead of (or in addition to) "branch if equal", "branch if less than", etc there should be a "set if equal", "set if less than", etc? In case you are, there is a "set if less than" instruction. The floating point extension does have a "set if equal" instruction despite there not being an integer equivalent.

Alternatively if you are complaining about 1 representing True rather than ~0, I don't think that matters much from a technical POV.

The condition codes from comparison operations have always been a problem for out-of-order execution units. Feeding the result directly to the register bank sidesteps the problem. Conditional-move instructions have also been a problem, which this also sidesteps. Branch-register-zero and -nonzero instructions complete the set.

The extra step to get a comparison result into a register, and another to extend it to the whole register, is an inefficiency I would prefer to leave behind.

It's a single instruction to then subtract 1 from the result of SLT/SLTI, which then gives you 0xffffffff or 0x00000000 rather than 0 or 1, which you can use as a mask.

RISC-V was designed to be a good target for a C compiler, given that's what people almost always need. Compilers frequently see code line `int x = (a > b)` and SLT is perfect for that. Compilers don't do clever masking tricks to avoid branches, in general (there are a few hard-coded tricks like divide by signed constant).

In other words, two more instructions, instead of zero.

That compilers fail to do clever masking tricks to avoid branches frequently results in 2x slower programs.

No, as jleahy said, it cost a single instruction to transform 0 to 0b00..00 and 1 to 0b11..11 - SUB X, $0, X.

And your proposal - using the zero register as a flag register - breaks way more micro-optimizations (like the simple ones described in "The RISC-V Reader" book) than it allows

> Compilers don't do clever masking tricks to avoid branches, in general

They actually do a lot of such tricks. Check out the GCC sources, for example tree-ssa-phiopt.c[1] and ifcvt.c[2]

[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-p...

[2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ifcvt.c

Well I was thinking of ifcvt when I mentioned a few special cases. Particularly things like minmax and abs are very specific.

They do it a bit, but they leave a very great deal on the table. Clang will convert

  a = (b&m)|(c&~m)

into cmov, but gcc won't.

> The condition codes from comparison operations have always been a problem for out-of-order execution units.

RISC-V doesn't have condition codes.

> The extra step to get a comparison result into a register, and another to extend it to the whole register, is an inefficiency I would prefer to leave behind.

Can you provide RISC-V assembly that demonstrates this problem? Common branching patterns in RISC-V are all a single instruction.

The core branching comparison instructions:

`a >= b` maps to `bge a, b, label`

`a = b` maps to `beq a, b, label`

`a != b` maps to `bne a, b, label`

`a < b` maps to `blt a, b, label`

Comparisons with 0 just use the x0 register and for <= and > just flip the order of the operands.

I know it does not have condition codes. Instead, it has a mess of very complex compare-and-branch instructions.

It has exactly 6 = != < >= and signed < >= - hardly "a mess" or particularly "complex"

These do not seem, to you, complex instructions?

I boggle.

Pretty much all architectures have those as a natural consequence of the way 2's complement arithmetic works? Even the tiny 6502 spends eight of its 256 opcodes on eight different branch-if-comparison opcodes.

The RISC-V compare-and-branch instructions are objectively a great deal more complex than the 6502 instructions.

No, compare and branch is kind of the expected instruction in an architecture that has no condition codes (mips has compare with 0 but essentially the same 6) - compare works well in an out of order pipe

If I was going to change anything I'd add compare eq/ne with an immediate

That is insane.

You're saying that you want an isa where a branch is done something like

Cmp rx ry rz # compare rx ry, write result to rz

Jmple rz, ra, imm # jump +- ra+imm if rz < 0

Which would avoid the use of a implicit condition register, as well as the short offsets that a combined compare+jump suffers from?

No. That is close to what existing chips do.

  r31 = (rx<=ry)? ~0:0

(or <, etc.), result in r31 implicitly. Followed by

  pc = r31? pc + n : pc

i.e. a single conditional branch instruction, for all conditions; or

  rx &= r31

effectively a conditional move instruction, or

  rx -= r31

effectively a conditional increment.

I.e., actually reduced, but more powerful. (Implicit destination followed by mov is free, because of register renaming.)

Decoding the RISC-V compare-and-branch instruction is a whole project.

9 lines of verilog in my decoder, 3 more in the branch unit - about the same as for, say jalr, or add immediate

> (Implicit destination followed by mov is free, because of register renaming.)

There is no need for an implicit destination register, just do it explicitly and you get the same result but without any magic and with more control. Register renaming can do the same job with an implicit or explicit register destination, there is no incidence on register dependencies.

> r31 = (rx<=ry)? ~0:0

Reading your first post I know that you want to use 0 and ~0 instead of the traditional 0 and 1 as the result of condition statements. I don't think that's a particularly great idea because: - there are so many places where you need 1 instead of ~0; - translating 1 into ~0 only costs one "SUB" instruction. If this feature is required for a specific domain, it's sufficient to add an extension with this feature or - more drastically - to add a macro-operation fusion step to detect this pattern.

> Decoding the RISC-V compare-and-branch instruction is a whole project.

RISC-V encoding is made to keep decoding as simple as possible. Have you ever checked the RISC-V encoding? It looks a bit confusing at the beginning to a human but if you think about the implementation, it immediately becomes clear.

In RISC-V ISA, we can criticize: the absence of a standard SIMD extension (with a big abstract vector extension instead) or the fact that some extensions require 3 read ports on the register bank instead of 2, which can make the implementation more complex. But it's trade-offs

Where do you ever need 1 instead of -1? If you are using it to increment something, -1 is just as good. Storing a bool value in memory is rarely done, vs. using and discarding it. But in use, having a value to AND with, without need to dink around first, makes a big difference, particularly when cmov instructions are lacking.

If the cost of negating before storing got to seem excessive, a single negate-and-store-word instruction could translate, but it would be used a very great deal less than negating the 1 to make a mask.

However simple it looks to decode the thicket of compare-and-branch instructions, decoding and executing exactly one conditional branch instruction that just checks for zero will be simpler and faster.

You still have the SET family to decode, but you need them anyway.

RISC-V is meant to be a simple, unsurprising, boring architecture, with any clever stuff (such as macro op fusion) being done at the microarchitecture level. It's not a project for researching new architectures.

I really wish it was just one tiny less bit simple. The RISC-V spec doesn't specify that multiplication instructions (if implemented) need to be constant-time. Which means RISC-V cores will need stupid hacks for cryptography like these: https://bearssl.org/ctmul.html

It could be added in the future as a simple extension. (In fact I found at least two proposed crypto extensions with a simple search although neither mentions constant-time ops from a quick scan). There's a considerable penalty for all implementations if every multiply implementation has to be constant time.

That is another problem.

The "optional extensions" have all the useful instructions in them, but typically just a couple of the instructions in each extension would provide most of its value.

So, I don't get popcount because it's in the bitmanip extension along with 10M transistors' worth of clever stuff I don't need. Similarly, each of the other extension sets.

It would be much more useful to define slices through all the defined ones, so you get either the absolute minimum core instructions, or add just the coremost of each extension set, or a more comfortable subset of each, or half of each, spiraling outward as transistor budget grows.

10 million transistors is a tenth of a square millimeter on current nodes, but that aside you really wouldn't want such a complicated system of "sub-extensions" because it would be a nightmare to write software for. Either the software would only work for very specific sub-extension mixes, or would require layers of ifuncs to deal with all combinations of missing sub-extension features.

The current system of fairly granular extensions, a useful base architecture, and profiles defining what extensions are guaranteed for particular application classes (eg "Unix server") is a nice compromise between extensibility and software/distro complexity.

A big part of the RISC-V story is the idea that microarchitecture decisions belong to the implementation and not the ISA specification. Specifying that multiplication must be constant-time would effectively be specifying that area-optimized cores aren't allowed to provide the multiplication instructions.

Couldn't this be solved by having constant-time and regular multiplication instructions?

Sure, but the constant-time instructions would presumably be defined in an extension along with other constant-time or crypto-optimized instructions.

Arm 8.4 has a constant time flag that makes most instructions constant time, without changing the instruction set. You could definitely add this to risc-v. Or just make a constant time implementation.

It is supposed to be the basis for a lot of future work, incorporating what we have learned thus far. But it doesn't, much. It seems not different from anything from the '80s, when we knew less.

If it is supposed to be simple, then great! Actually make it simple, instead of copying old complexities.

What "old complexities" are you talking about? It's a very simple and clean architecture.

No: it is just very familiar. It is like architectures we are used to, that we got used to because old designs were like that.

If you're an academic doing research into new techniques for branch prediction or some other topic it can be very useful to have well tested designs as a starting point you can modify to try out your idea which are starting from a very basic place.

It isn't architecturally innovative, isn't meant to be, and isn't a good place to start if you're thinking about doing architectural innovation. A lot of people are talking up RISC-V like it'll solve every problem but there are many problems in both academia and the real world where it represents a solution.

"While reading the rest of this post, please keep in mind: RISC-V is simple!"

That's either a lie, or the author is severely traumatized from coding on x86 and is suffering from the Stockholm syndrome. Poor author; I feel sorry for the bloke.

Code on UltraSPARC or MC68000 family of processors and then you will know what simple means. The instruction set of RISC-V is insane, absolutely insane.

As I am someone who has never seen assembly from those languages, can you explain to me what is insane about RISC-V?

By definition, RISC stands for "reduced instruction set computer". And RISC-V exposes its internals so it has way more instructions than a conventional CISC processor, a lot of which deal with its internal states.

Here is a good example[1]:

For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative.

  add t0, t1, t2
  slti t3, t2, 0
  slt t4, t0, t1
  bne t3, t4, overflow

...good luck programming this insane design with anything other than a high level language compiler.

[1] https://riscv.org/specifications/

> And RISC-V exposes its internals

But your example shows no internal states exposure, it's just arithmetic to detect overflow. What are you trying to show ?

Generally, the "reduced instruction set" in RISC refers to how many instructions are available to the programmer, i.e. not many, rather than the larger number of instructions it then takes to accomplish anything.

And the difficulty isn't really about exposing the internals, this isn't like a branch delay slot for instance. It's about making the relationship between instructions conceptually simple where there's always up to 2 inputs and up to one output. That doesn't help much in cases where the processor is doing something close to what the instructions are saying but it makes the simplest possible out of order processor, where the internals diverge wildly from the ISA, much easier to create.

EDIT: Also, the using C and compiling rather than doing assembly by hand is really a fundamental part of the whole RISC philosophy and RISC-V is just a more extreme form of that.

The Reduced means that the instructions themselves are reduced, as in easier to implement and easier to implement in a pipelined implementation. As opposed to having instructions with plenty of addressing modes, you have a lot of register-register instructions and load and store opcodes: You compute the addresses explicitly, using the register-register opcodes, then load from that address using a load opcode which doesn't do much ALU work, then work on the loaded value in the registers.

Contrast this with a leading CISC design, the VAX, which had plenty of addressing modes which practically all opcodes could use. A single opcode could expand into a whole stream of micro-operations to compute the addresses being loaded from, actually perform the named opcode, and then compute the address being stored to, and possibly more. Doing that in the presence of virtual memory, where an opcode might have to be stopped and restarted so the OS could take a page fault, was rather nontrivial.

https://link.springer.com/chapter/10.1007%2F0-387-27446-4_3

That's main problem of RISC-V ISA: doing multi-precision arithmetic needs to do branching. It is not only a programming complexity issue, it is then very difficult to do large number arithmetic in constant-time due to the branch predictors of modern CPUs. This can create timing-attacks problems (side-channel attacks) in algorithms like RSA.

But that's the only big issue, saying that the whole ISA is insane due to this specific point of design is totally overstated

And also if it's important to someone to fix this, then extensions will be proposed for multi-precision arithmetic and constant time crypto primitives. RISC-V is an extensible architecture for this very reason.

I don't think you need branches, you can just add in the output of the correct lte (which returns 0 or 1) as the extra carry in.

You left out the paragraph introducing this in the footnote:

> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.

So this boils down to "there's no platform overflow (V) flag", which is also a problem on other RISC systems, and is in any case rarely used in C code because it doesn't check for overflow.

yes, exactly - if you want to add 2 registers use:

add t0, t1, t2

in the occasional case where you want overflow as well add the other 3 instructions - if you're hand coding in assembler you probably know which you want, if you're using a compiler, it can map it's semantics where appropriate

> good luck programming this insane design with anything other than a high level language compiler.

That's been the RISC idea from day one. CISC ISAs were nice to the assembly programmer, RISC ISAs were nice to the C programmer and the hardware implementer. Do you know how to do integer multiplication on the MIPS? I'll tell you:

    li $a0, 5
    li $a1, 6
    mult $a0, $a1
    ... do some other stuff here ...
    mfhi $a2
    mflo $v0

Why do you want to do other stuff? What's that mfhi and mflo stuff? Why is mult not three-operand? Because RISC! The MIPS model is so RISCy it exposes the fact its multiplication isn't single-cycle. It does this by making it somewhat asynchronous: You issue the multiplication opcode, and your code continues to run while the arithmetic is performed. If you try to get the result immediately, you'll stall the pipeline, so you were encouraged to schedule opcodes that don't rely on the result of the multiplication to run in that hazard.

In a CISC chip, that would have been handled by microcode, and you would have gotten nice three-operand multiplication opcodes which could even do memory-to-memory operations, like on the VAX. In a RISC chip, the compiler was assumed to have all the intelligence the microcode used to have, so you got simpler-and-supposedly-faster hardware with really funky assembly language behavior.

https://devblogs.microsoft.com/oldnewthing/20180404-00/?p=98...

TL;DR: Compared to the MIPS, RISC-V is a model of rationality and clarity.

Yeah... no. I'd rather bang my head against the wall until it bleeds profusely and I figure out how to synthesize my own OpenSPARC cores and enjoy myself on 64-bit MC68080 which gets faster and faster with every accelerator update.

>enjoy myself on 64-bit MC68080 which gets faster and faster with every accelerator update.

Note that Apollo Core isn't OSHW, so you won't be synthesizing that one.

That's harsh. Have you written much assembler? If so, how often did you need to check for overflow? (I've written quite a bit of it, and the number of times I've checked the overflow bit in the x86's flags could be counted on one hand.) In the unlikely event you did need to check for overflow frequently, wouldn't you write a macro to generate the required instructions?

Compared to the earlier CPU's like Z80's, or god help us DSP's and GPU's, this thing an absolute delight. In fact even compared to x86, it's a model of clarity. Have you ever looked at the Intel architecture manuals for x86? The description of how a "jmp" operates runs for pages and pages of pseudo code. I'll guess you will counter "but most people don't use the more complex features like gates", but the reality is I've used jumps via gates far more times than I've tested for overflow - and I've had to digest those pages and pages of pesudo code and the related data structures many times because they are so damned complex and unintuitive you keep forgetting the details.

"Have you written much assembler?"

I have written lots of MOS6502, MC68000 and UltraSPARC assembler, as I come from the demo and cracking scene. That's where I grew up.

The parent comment is complete drivel. RISC-V has a very small instruction set (under 50 instructions in the base arch) and lacks the weirdness of UltraSPARC (register windows! branch delay slots!). 680x0 was a joy to program in assembly, I used to be a commercial 68k developer on VMEbus systems, but those days are long gone and are never coming back. There is simply no point optimizing a modern architecture for hand-written assembler coding.

tagged integers

I'm not a RISC-V fan-boi by any stretch of the imagination but I have to admit that they certainly cleaned up RISC which 40+ years later was in order for a thorough house cleaning. X86 is gloriously messy but RISC had become quite a mess as well.

> RISC had become quite a mess as well

That's kind of a nonsensical statement — "RISC" is not a particular ISA, RISC is a vague methodology/philosophy.

RISC-V is not officially related to any previous ISA, but people like to call it "MIPS in a trenchcoat". RISC-V got off the ground in academia, and MIPS was often used for teaching before. They are quite similar in some ways, but it's really independent.

That is being overly pedantic. I'm actually paraphrasing chapter 2 of Andrew Waterman's thesis, The Design Of The RISC-V Instruction Set Architecture.

https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

That link was a fantastic read. Thank you.

I wonder why they studiously avoided even ever mentioning IBM Power architecture. It is considerably more open than MIPS or ARM, and quite a lot cleaner than either has become.

Well, open-ness wasn't what RISC-V was looking at in ISA models.

Is Power clean? Myself, I've never liked its special purpose Condition, Link and Count registers. I don't see the need for a Branch Processing Unit being an architectural division. The last time I checked, pushing a register value across that boundary was slow. It wasn't handled by a renamer.

Clean-er.

Not suggesting it as a substitute for RV, just wondering why they saw nothing in it to learn from. It's not defunct like PA-RISC, Alpha, and (forgive me) SPARC, and quite some research has gone into it.

I have to admit that leaving Power out of the analysis is a bit odd; the Berkeley crew can be rather parochial. I wrote PowerPC assembly back when the Mac used that ISA and liked it. Alpha lives on, to a degree, in the Sunway Chinese supercomputers. Intel should have gone with Alpha rather than Itanium.

https://en.wikipedia.org/wiki/Sunway_(processor)

Is there an architectural feature in Power you think should have been considered by RISC-V for inclusion or omission?

My 2030 prediction is that Intel will have a simpler x86 where they discard a shit ton of legacy.

Don't know it well enough to suggest any. That is what inclusion in the survey would have been useful for.

It is conventional to complain about condition codes, but I don't see what would be debilitating about just appending a set of condition codes to each register, so that renaming a register carries them along. Going from storing 64 bits to 70 bits each would't break the bank.

That is a really good idea. Sadly, RISC-V is an ultra ultra conservative design bereft, nay avoiding anything resembling an idea.

I believe that an element of your idea is done in modern x86 microarchitectures. I was having an argument on LLVMdev about a peephole optimization and partial register update stalls. Eventually one of the Intel compiler people popped in on the thread and settled the argument, saying:

Regarding the partial EFLAGS write, modern OOO processors independently rename the carry flag, et al, so this is no longer a problem.

You haven't been paying attention: we now run 64-bit AMMX extended MC68080's which get faster and faster every firmware update. SPARC register windows are an awesome thing once you grok them; 256 virtual registers and pedal to the metal!

There are unofficial extensions to the architecture, but I don't think Moto/Freescale/NXP have gone ahead with anything like that. This matters for serious users who care about more than keeping up the 68k legacy. RISC-V is a big deal in computer architecture, the latest vanity extensions on the 68k not really.

RISC is not MISC (minimal instruction set computer)

The "Reduced" refers to reduced workload per instruction, not number or complexity of instructions for programmer. For example adding explicit load/store instructions.

Many modern RISC ISA's have more instructions than CISC processors.

A great way to think of the original RISC transition is as a tradeoff between instruction decode complexity (and speed) and instruction fetch bandwidth.

This trade-off equation changed enormously the moment that L1 I-caches moved on-chip - which was when the RISC revolution flowered

You may wish to re-calibrate your irony detector.

Reply on news.ycombinator.com