Earlier quoted context omitted.
I thought cortex-m0 was taking over that slice of the pie.
Not really. Before RISC-V, the low end was held firmly by 8051, and at the high end, it was a fight between Xtensa, ARC, M0, and "others", be that custom ISAs or something like legally distinct MIPS. Now, both ends have RISC-V seeping into them.
RISC-V: They Should Have Known Better
431–440 of 467 posts
Re: RISC-V: They Should Have Known Better
#432Earlier quoted context omitted.
Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary. 2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core regi…
One thing I noticed with your clever encoding is that you can avoid some nops: instead of having 2 15 bits instructions followed by two nops, you could have two 30 bits instructions, saving maybe a little decoding energy. Also the 60bit format will really help for loading immediates.. That said I wonder why normal ISA do not contain a 'Load Immediate on Next PC'? And if you want to allow parallel decoding the first b…
RISC-V does a 20-bit LUI (load upper immediate) then a 12-bit addi to the same register for the lower bits. Having access to 40-60 bit immediates makes 32-bit immediates a lot easier (with 64-bit immediates being multi-step, but quite uncommon).
Re: RISC-V: They Should Have Known Better
#433Earlier quoted context omitted.
I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX ) that RISC projects were in opposition to. [1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.
> In comparison VAX needed separate pipeline for instruction decoding. That's how the VAX 9000 and NVAX did it. It's not the only way. It is absolutely possible to decode a number of normal VAX instructions in parallel using a pipelined decoder similar to x86 decoders. It is also possible to use a µop cache similar to many x86 and ARM implementations. Fallbacks are only needed for the weirder addressing modes and for…
DEC didn't try to parallelize the decoder further because it already could face 56 bytes for a single instruction, and the NVAX design was costly as hell. x86 in comparison has limit of max 15 bytes per instruction, and most instructions in x86 code fall in 4 bytes
Re: RISC-V: They Should Have Known Better
#434Earlier quoted context omitted.
This is a "microcontroller core", not a "microcontroller". We're talking "deep embedded" applications - where an ASIC is designed for a very specific purpose, and that design just so happens to call for a programmable CPU core to be included in it. This is the kind of design that lives in your keyboard, your mouse, your USB stick, your USB hub, your HDD, your SSD, your eMMC chip, your memory card and more. Remember:…
I thought cortex-m0 was taking over that slice of the pie.
Now-a-days, I actively avoid RVxxx Zwhatever because those guys had their chance and seemed to have learned nothing from the IBM 360: SOFTWARE is what ultimately matters, as long as you don't have ridiculously expensive chips, keep the ABI consistent!
And, ARM learned from M0 and quickly came out with the M0+ --- which SHOULD be the 8051 killer (no offense to my friend John Wharton (RIP), 8051 designer https://en.wikipedia.org/wiki/John_Harrison_Wharton): M0+ is a lower-power, more efficient redesign of M0, 2-stage pipeline, Harvard bus, and optional features (MPU, MTB, fast I/O) that M0 lacks. The RPi Pico has all of these optional features except the MTB (Micro Trace Buffer), but does have 4 breakpoints / 2 watchpoints per core, 8 memory regions, single-cycle I/O port access, 30% less power than M0, and 12% less die area, 32x32 single-cycle multiply, Thumb-2: "32‑bit Performance at 8‑bit Cost" https://documentation-service.arm.com/static/60411750ee93794...
Maybe certain Chinese RV32E variants will get uber popular (WCH CH32V003 under a dime in quantity https://wch-ic.com/products/CH32V003.html ). Maybe.
Re: RISC-V: They Should Have Known Better
#435Interestingly, in the Olden Days, machines often had custom instructions. The pdp-1/D had a tad instruction for 2's complement addition (it was normally 1's complement machine), and there were also new pdp-1 instructions for timesharing.
For the IBM 1401, there were all sorts of add on 'features', e.g. the Multiply / Divide Feature (sped up * and / in HW), High-Low-Equal Compare feature, Advanced Programming (added Index Register, Subroutine Linkage), Move Record feature (allows right-to-left movement until hitting a Record Mark, useful for Tape), Expanded Print Edit Feature (float $ sign, automatic * insertion, etc), various memory sizes from 1,400 characters up to 16,000 characters. The point is that manufacturer-distributed software had to deal with having features (or not); and this was handled e.g. in the assembler by having a CTL card that listed (coded) the features, e.g. "CTL 31110" says this is a 12K machine, with Automatic Multiply / Divide, the High-Low-Equal Compare, the Move Record Feature, but NOT the Expanded Print Edit Feature -- that told the Macro Generator what it needed to know to properly expand macros for a specific HW configuration. (Certain Features did not require SW mods, e.g. the notorious "Print Overlap" feature that would speed up print operations by having a hardware buffer to hold the Print Line, so the CPU did not need to stall. The feature was notorious because the sub-rack of HW required to implement it connected into probably 75% of the machine's instruction decoder & execution units; when it failed, it was incredibly painful to find the fault(s)).
And, there have been Writeable Control Stores like, forever. It was a feature on the Burroughs B1700, where different control stores could be loaded on-the-fly depending if you were executing COBOL or FORTRAN or Pascal - the 'instruction set' would be optimized for running that particular language. The pdp-11 had some version of this, and CMU's custom C.MMP had something like this.
So, the desire for certain customers to have machines specifically honed to their use cases was normal. It has only been this brief period of homogenization of single-chip(ish) CPUs (8008, 8080, Z80, 8086... amd64 etc) that introduced new instructions in tranches.
The End-Users now get their custom instructions in other ways (e.g. PCIe and GPUs)
Re: RISC-V: They Should Have Known Better
#436Earlier quoted context omitted.
Tell that to Valve or the millions who use it as a desktop. Also, have you used Windows recently?
I keep saying Linux can win on desktop by just sitting still while Windows sucks more and more.
Re: RISC-V: They Should Have Known Better
#437https://chatgpt.com/share/6a81dbb7-1934-83ea-8a47-6d1d1b4c0f...
Re: RISC-V: They Should Have Known Better
#438Earlier quoted context omitted.
And USB-C is known as a compatibility mess.
Is it though? Is it really? Outside the HN rant circles which want to return back to times where you needed an adapter for every single laptop model or be shit out of luck for connecting your mouse or projector?
Re: RISC-V: They Should Have Known Better
#439Earlier quoted context omitted.
Don't you have to save registers on any architecture, or not use them in the interrupt handler?
No. That's also partially in the article. But even in ones that do, usually it's a subset. In arm-m, some registers get stacked on interrupt (basically the caller saved ones in the ABI so any regular functio is automatically IRQ compatible). In this implementation, 64 registers do. Very different from I think it's r0-r3, lr, and pc. Some architectures bank them, so as long as you don't nest or call functions you can…
Re: RISC-V: They Should Have Known Better
#440Earlier quoted context omitted.
If everyone has equal ability to build a moat, it's not a moat.
If every one has a hammer and a saw and identical wood planks, everyone can build a frame that holds up 100 years? Think it through. This is the HN comment section after all.