MIPS or PowerPC is also free. We can use them too.
Not free enough. If your stuff becomes popular, you'll see patent holders popping and ask for money.
RISC-V: They Should Have Known Better
441–450 of 467 posts
Re: RISC-V: They Should Have Known Better
#442Earlier quoted context omitted.
In x86 land, there are, as a practical matter, four ISAs: real/v8086 mode, 16-bit protected mode, 32-bit protected mode, and 64-bit “long” mode. Machine code targeting one of these will be executed correctly by the CPU as long as the CPU is in the right mode. (Really it’s messier — there are the CS.D, CS.L, and SS.B bits plus the control bits for v8086, protected and long mode, but this barely matters.) Sure, this is…
> But you will not find multiple different CPUs that decode valid instructions differently. If I run your weird old x86 code, either it will run correctly or it will fault. Oh, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encod…
Pretty sure 3DNow's instruction space has been repurposed too. There are a few like that, or worse extremely similar but ever so slightly different between vendors or even generations of the same vendor. I won't claim to be an expert, this is all in IIRC territory for me.
Re: RISC-V: They Should Have Known Better
#443Earlier quoted context omitted.
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…
Are all registers caller-saved in RISC-V, or are you blaming the ISA for a specific inefficient implementation and ABI?
The delta is that no, not all registers are caller saved. However, that's how it does interrupts. So they're different. In cortex-m, they're not
The hardware/ISA matches the ABI. I'm struggling to find the RV doc that describes it on mobile, but I am confident about it. So in RV, there's no pushing required at all which can save time. Interestingly, it looks like GCC (didn't check others) can compile compilation units with only using some registers. So presumably you could implement some compiler-driven banking of registers... Which I'd never thought about and actually is interesting. RV gives you that flexibility. But you really have to work for it. Which goes back to my other comment. NVIC just handles it pretty well. Especially with ARM recommending 64 bit memory alignment for the stack, it allows devices like the STM32H7 to have 64 bit buses on 32-bit CPUs to halve the transfer time. RV can't do that. No hardware memory ops, no multiple load/store. Trade offs, certainly
Re: RISC-V: They Should Have Known Better
#444Earlier quoted context omitted.
How many people are working on this in your couple years example? Is that just one guy or a team of 20 or something else? Whats the average salary for the team *n this scenario?
I said "me" and "four weeks" because laying out an ISA is a pretty straightforward job for one person in one month. The deliverable would be a (theoretically) complete specification PDF like RISC-V's. I have little doubt that I or Adrian could do it, or plenty of others. It might not reach the quality of something like AArch64 with that level of resources, but it's not hard to beat RISC-V.
I am trying to figure out if i can afford to make it happen or not lol. Would the labour coat of getting to something good with the support infra be a fewmillion or tens of millions?
Re: RISC-V: They Should Have Known Better
#445Earlier quoted context omitted.
I said "me" and "four weeks" because laying out an ISA is a pretty straightforward job for one person in one month. The deliverable would be a (theoretically) complete specification PDF like RISC-V's. I have little doubt that I or Adrian could do it, or plenty of others. It might not reach the quality of something like AArch64 with that level of resources, but it's not hard to beat RISC-V.
I am trying to figure out if i can afford to make it happen or not lol. Would the labour coat of getting to something good with the support infra be a fewmillion or tens of millions?
Are you trying to get to a working simulator, a working core in HDL/FPGA, a thoroughly debugged and validated core in HDL, a fast core in HDL, a validated fast core in HDL, or functioning silicon in hand?
I'd guess low six figures for the beginning of that list and mid eight figures for the end. Real silicon also needs all the uncore stuff, which is easy if you don't care how it performs and very very hard if you do.
Re: RISC-V: They Should Have Known Better
#446Earlier quoted context omitted.
> RISC-V is... fine Exactly. > It satisfies my two requirements for an ISA as a hobby CPU designer... You probably have some unstated requirements as well, such as available toolchains and "vetted well enough to actually be able to run code." Risc-V now occupies the Schelling point for people who, for whatever reason (rent-seeking and security top the list) want to leave the x86 and Arm ecosystems.
Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.
Are we talking about rp2350 ? Because the rp2350 can be config as pure arm soc.
In fact, if we are talking about successfull riscv soc, RISC-V esp32 may have better chance
Re: RISC-V: They Should Have Known Better
#447Earlier quoted context omitted.
The effort to support architectures is now minimal with AI assistance. I made a hobby architecture (based on Intel, but with some changes; I was making an "alternate history" as if a few decisions in the past had been different) and it was pretty much trivial to spit out support not just in gcc and llvm, but I also, for fun, made WATCOM backends and a few other things. With that said, RISC-V is a nice baseline for de…
> and it was pretty much trivial to spit out support not just in gcc and llvm, but I also, for fun, made WATCOM backends and a few other things No links? You may have dreamt about it instead.
It was vibed-level stuff definitely not worth sharing.
Re: RISC-V: They Should Have Known Better
#448Earlier quoted context omitted.
The combined comparison-branch instructions of RISC-V are its only good feature in terms of instruction encoding design. This allows a significant code size reduction in comparison with ARM Aarch64, but unfortunately for RISC-V this advantage is frequently not enough to compensate its other defects, especially when reliable code is desired, i.e. where overflow detection is necessary. Despite that from this point of v…
> I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64. Nope. Again , the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.
Also I haven't looked closely but I don't know if you could find space to fit it in the remaining Aarch64 encoding space.
The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch".
Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused opcode space to find.
Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it
So could do ...
[31:28] (4 bits): 0b1000 (Fixed primary opcode .. or 0b1001, 0b1010, 0b1011)
[27:23] (5 bits): Rs1
[22:18] (5 bits): Rs2
[17:15] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, + possible 2 more)
[14:4] (11 bits): Offset (Signed ±4k PC-relative offset)
[3:0] (4 bits): 0b0000 (Fixed minor opcode/extension identifier)
Maybe...
[31:28] (4 bits): 0b1000 (Fixed primary opcode)
[27:21] (7 bits): Offset[12:6]
[20:16] (5 bits): Rm
[15:13] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, etc)
[12:10] (3 bits): Offset[5:3]
[9:5] (5 bits): Rn
[4:2] (3 bits): Offset[2:0]
[1] (1 bit): sf (Size flag: 0 = 32-bit compare, 1 = 64-bit compare)
[0] (1 bit): 0b0 (Fixed)
Some ::coff:: would criticise the split up offset field. Not RISC-V fans of course. And this puts sf in a non-standard place.
Some more playing around is needed .. over to you Arm.
Re: RISC-V: They Should Have Known Better
#449Earlier quoted context omitted.
> But you will not find multiple different CPUs that decode valid instructions differently. If I run your weird old x86 code, either it will run correctly or it will fault. Oh, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encod…
Pretty sure 3DNow's instruction space has been repurposed too. There are a few like that, or worse extremely similar but ever so slightly different between vendors or even generations of the same vendor. I won't claim to be an expert, this is all in IIRC territory for me.
No, the 0f 0f opcode (most of 3DNow was encoding-wise a single RMI-encoded opcode where the immediate specified the operation) and the 0f 0e opcode (FEMMS) were not repurposed by either Intel or AMD.
Re: RISC-V: They Should Have Known Better
#450> What does a cheap microcontroller core need? Let's inspect what they are used for. Typical use cases are to interface with and quickly reconfigure hardware blocks in a larger chip, eg in an MP3 player, an SD card, or a USB stick. The hard work is done by custom IP and the CPU core is just there to occasionally prod a register or configure something. He forgot electronic cigarettes (vapes)
My apologies. I’ll update my shitpost with this example. :)
Did