I caught only the smallest drift of any of this...You know that modern Arm and X86 cpu designs have thing called AGU. That's alu unit responsible of generating those complicated indexed addressing addresses for each load. Risc-V design don't need them - they can expand their load/store capabilities without need to add more AGU-units. And with those hardware indexing instruction sets - actually when more complex indexing modes are used load latency is longer by one clock cycle. By Risc-V scheme that is avoided. Of course Risc-v type addressing can be used with arm and x86 too, but why to have instructions which when used made cpu performing worse.
Other key points of Risc-V is that SIMD. SVE tries to be SIMD-vector length agnostic but isn't - Risc-V other hand doesn't have SIMD hardware at all - instead it have vector ISA. Vector ISA presents vectors as loops of scalar instructions - and execution hardware, when done right, is totally vector length agnostic, those instructions can be executed with scalar or SIMD hardware at any given register length.
No matter how flawed I think RISC-V is, it'd be much wiser to teach it rather than MIPS. Even for teachers it wouldn't be that hard to switch their slides from one to the other given how close they are, and at least RISC-V is on the rising curve contrary to MIPS.MIPS assembly is still taught (last I checked) at many universities for students just learning about assembly. It is easier IMHO than x86 assembly.
What about X86-S ?
But MIPS powered the PSX. It's arguably more successful than RISC-V has been so far. Been hearing about it for years but what is the most successful RISC-V product at the moment? I can't recall reading anything about some RISC-V product making waves in the industry. It still seems to be under development. Or rather, development hell.No matter how flawed I think RISC-V is, it'd be much wiser to teach it rather than MIPS.
I caught only the smallest drift of any of this...
... but it sounds like you're saying "Risc-V evolved a more elegant design to improve on workarounds used by arm/x86 architectures"
Which sounds like exactly the kind of thing x86 haters say they want to trashbin the architecture: get rid of all this extraneous legacy stuff.
RISC-V has sold billions of cores. A huge proportion is deeply embedded.But MIPS powered the PSX. It's arguably more successful than RISC-V has been so far. Been hearing about it for years but what is the most successful RISC-V product at the moment? I can't recall reading anything about some RISC-V product making waves in the industry. It still seems to be under development. Or rather, development hell.
Multiplication is not needed. Any operation with immediate is not needed beyond move (and even then you can live without it), you don't even need reg + imm addressing mode. And so on. Keeping an ISA to the bare minimum is idiotic when pushed too far and IMHO RISC-V went too far. They basically made it sure that any higher end core will need instruction fusion to extract performance, or extensions.Where one type is those load-store instructions with combined address calculation - they aren't needed and Risc-V should not include them - to keep future hardware designs as free of hardware limitations as possible, like you say to have situation opposite of mess previous ISA:s are from adding instructions to support hardware instead of doing it other way around.
Multiplication is not needed. Any operation with immediate is not needed beyond move (and even then you can live without it), you don't even need reg + imm addressing mode. And so on. Keeping an ISA to the bare minimum is idiotic when pushed too far and IMHO RISC-V went too far. They basically made it sure that any higher end core will need instruction fusion to extract performance, or extensions.
Multiplication is not needed.
I caught only the smallest drift of any of this...You know that modern Arm and X86 cpu designs have thing called AGU. That's alu unit responsible of generating those complicated indexed addressing addresses for each load. Risc-V design don't need them - they can expand their load/store capabilities without need to add more AGU-units. And with those hardware indexing instruction sets - actually when more complex indexing modes are used load latency is longer by one clock cycle. By Risc-V scheme that is avoided. Of course Risc-v type addressing can be used with arm and x86 too, but why to have instructions which when used made cpu performing worse.
Other key points of Risc-V is that SIMD. SVE tries to be SIMD-vector length agnostic but isn't - Risc-V other hand doesn't have SIMD hardware at all - instead it have vector ISA. Vector ISA presents vectors as loops of scalar instructions - and execution hardware, when done right, is totally vector length agnostic, those instructions can be executed with scalar or SIMD hardware at any given register length.
Now that Nvidia failed to buy it, yes ARM currently is the best.So ARM is better than both!
I though it was sarcasm against RISC philosofy. Risc-V is extremely well thought ISA, they got instructions they need but same time keep instructions as hardware-independent as possible - something that AArch64 failed to do.So every address has to be a power of 2 ?
You don't need an instruction to do multiplication. Proof is that this comes as an extension in RISC-V.So every address has to be a power of 2 ?
That's good: they are trying to reduce the mess the use of extensions has started creating (I think it's already worse than what happened to MIPS fragmentation).The RVA23 profiles are intended to align implementations of RISC-V 64-bit application processors to allow binary software ecosystems to rely on a a large set of guaranteed extensions and a small number of discoverable coarse-grain options.
- M Integer multiplication and division.
- A Atomic instructions.
- F Single-precision floating-point instructions.
- D Double-precision floating-point instructions.
- C Compressed Instructions.
- Zicsr CSR instructions. These are implied by presence of F.
- Zicntr Base counters and timers.
- Zihpm Hardware performance counters.
- Ziccif Main memory regions with both the cacheability andcoherence PMAs must support instruction fetch, and any instructionfetches of naturally aligned power-of-2 sizes up to min(ILEN,XLEN)(i.e., 32 bits for RVA23) are atomic.
- Ziccrse Main memory regions with both the cacheability and coherence PMAs must support RsrvEventual.
- Ziccamoa Main memory regions with both the cacheability and coherence PMAs must support AMOArithmetic.
- Zicclsm Misaligned loads and stores to main memory regions with both thecacheability and coherence PMAs must be supported.
- Za64rs Reservation sets are contiguous, naturally aligned, and amaximum of 64 bytes.
- Zihintpause Pause instruction.
- Zba Address computation.
- Zbb Basic bit manipulation.
- Zbs Single-bit instructions.
- Zic64b Cache blocks must be 64 bytes in size, naturally aligned in theaddress space.
- Zicbom Cache-Block Management Operations.
- Zicbop Cache-Block Prefetch Operations.
- Zicboz Cache-Block Zero Operations.
- Zfhmin Half-Precision Floating-point transfer and convert.
- Zkt Data-independent execution time.
- V Vector Extension.
- Zvfhmin Vector FP16 conversion instructions.
- Zvbb Vector bit-manipulation instructions.
- Zvkt Vector data-independent execution time.
- Zihintntl Non-temporal locality hints.
- Zicond Conditional Zeroing instructions.
- Zimop Maybe Operations.
- Zcmop Compressed Maybe Operations.
- Zcb Additional 16b compressed instructions.
- Zfa Additional scalar FP instructions.
- Zawrs Wait on reservation set.
You don't need an instruction to do multiplication. Proof is that this comes as an extension in RISC-V.
And could be (theoretically) reprogrammed to run a different ISA than x86.Anyone remember Transmeta Crusoe? The CPU that reached full execution speed after working for about 24 hours?
Transmeta Crusoe: The Most Interesting Processor To Ever Exist?
An unusual type of processor from the early 2000s seemed to offer the best of all worlds—and may be the most inventive approach to the CPU ever developed.tedium.co
Successor of sorts' review: https://www.vanshardware.com/reviews/2004/04/040405_efficeon/040405_efficeon.htm