411–420 of 467 posts
This feels like Andy Tennenbaum's LINUX is OBSOLETE post from 30 years ago.
don't see how? the last section is pretty explicit: > None of this is to say that RISC-V is doomed. As I said, I fully expect it to take over the space currently occupied by [...] Much like the linux kernel -- the price is right.
Earlier quoted context omitted.
ARM was also rooted in an academic exercise. A lot of the drawbacks for modern ARM PC platforms stem from the aversion to actually advanced features like SVE/SVE2 and UEFI. It's sad, but it was also wildly successful. RISC-V has already replaced ARM in highly-custom embedded spaces like Nvidia's GPU controllers, and it likely won't stop unless ARM finally changes their tune vis-a-vis licensing.
> ARM was also rooted in an academic exercise. Where do people get ideas like this from? Just nonsense.
What do you think happened? RISC-I and RISC-II never existed, ARM means "Automated Reasoning Mechanism" and the ISA was never RISC whatsoever?
Talk about nonsense, damn...
Earlier quoted context omitted.
Why? It'll still run fine. Just like Debian still runs on original x86-64-v1 from 1999, not x86-64-v3 (needs AVX2,FMA, BMI1, BMI2, LZCNT) or even x86-64-v3 (needs AVX-512). Similarly, Debian for arm64 still requires only ARMv8.0-A from 2011 not even ARMv8.2-A (everything from A75/A55 to A78/N1/V1) let alone ARMv9-A (A710, A510, X2 and on). Why would they do in the RISC-V world what they totally haven't done in amd64…
No, debian requires ARMv8.0-A + FP + NEON, as those are optinal extensions (even optional in ARMv9.0-A)
Earlier quoted context omitted.
So a VLIW, interesting but usually compressed instructions are at most two-registers..
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…
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 byte of the immediate would be a 'special noop' and the first immediate byte would be inside the Load Immediate Next PC instruction instead.
This feels like Andy Tennenbaum's LINUX is OBSOLETE post from 30 years ago.
don't see how? the last section is pretty explicit: > None of this is to say that RISC-V is doomed. As I said, I fully expect it to take over the space currently occupied by [...] Much like the linux kernel -- the price is right.
I read that as a hat tip to the legendary argument, and a partial adoption of Linus's rebuttal, “Linux wins heavily on points of being available now.” Besides the general tone, I guess.
Earlier quoted context omitted.
If China leapfrogs EUV, this could happen.
What does this have to do with anything? You do know that a bunch of American corporations are shipping RISC-V cores, right? Including Jim Keller's current company, Tenstorrent.
Earlier quoted context omitted.
Yes, I'm serious. I think the overlap is an aesthetic problem rather than a practical one, given that: * The profile used by "Big SoCs" already explicitly depends on F + D + C, implying ZcdZcf, so the newer Zce won't be implemented. * The compressed float load/store opcodes repurposed for Zce are often unimplemented on embedded processors. * The ELF file has an attribute section telling you the exact ISA string. If y…
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…
Some early 386 CPUs had XBTS/IBTS instructions (extract/insert bit string). They used 0F A6 and 0F A7 encodings.
Some early 486 CPUs had CMPXCHG encodings that reused the XBTS/IBTS encodings. That apparently screwed up some programs that tried to execute XBTS/IBTS to see if they were running on early (buggy) 386s so Intel moved CMPXCHG to different encodings (0F B0 and 0F B1).
0F A6 and 0F A7 are still left unused by Intel and AMD in their modern chips.
There's also the delightfully petty story about SYSENTER/SYSEXIT and SYSCALL/SYSRET for fast system calls. Intel came up with the first pair, AMD with the second. AMD of course had to support both and operating systems generally only supported Intel's pair.
Then AMD extended the x86 to 64 bits and of course required SYSCALL/SYSRET for 64-bit system calls (and did not support SYSENTER/SYSEXIT in 64-bit mode). Intel had to support AMD's instructions in 64-bit mode but decided to also support SYSENTER/SYSEXIT there (which I don't think any operating system has ever bothered to support).
To summarize: AMD supports both methods outside of 64-bit mode and only their own in 64-bit mode. Intel supports both methods in 64-bit mode and only their own in 32-bit mode. Or at least that's how it used to be. Maybe they've mellowed out by now.
Earlier quoted context omitted.
No, debian requires ARMv8.0-A + FP + NEON, as those are optinal extensions (even optional in ARMv9.0-A)
SVE2 is compulsory in ARMv9-A, but NEON is optional?
> In an Armv9.0 implementation, if FEAT_FP and FEAT_AdvSIMD are implemented, the following features are implemented: ...
This implies they don't have to be implemented.
https://support.arm.com/documentation/109697/2026_06/Feature...
> FEAT_FP is OPTIONAL from Armv8.0.
> FEAT_AdvSIMD is OPTIONAL from Armv8.0.
But also:
> All Armv8-A systems that support standard operating systems with rich application environments also provide hardware support for Advanced SIMD instructions.
and
> All Armv8-A systems that support standard operating systems with rich application environments provide hardware support for Advanced SIMD and floating-point instructions. All Armv9-A systems that support standard operating systems with rich application environments also provide hardware support for SVE2 instructions. It is a requirement of the ARM Procedure Call Standard for AArch64, see Procedure Call Standard for the Arm 64-bit Architecture
So, both FEAT_FP and FEAT_AdvSIMD are optional for Armv9-A and Armv8-A.
But both are mandated in cores for "rich operating systems", which basically means it's mandated by the OS.
Also, Armv9-A on OS level mandates SVE2.
Earlier 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…
> There are edge cases in x86 Some early 386 CPUs had XBTS/IBTS instructions (extract/insert bit string). They used 0F A6 and 0F A7 encodings. Some early 486 CPUs had CMPXCHG encodings that reused the XBTS/IBTS encodings. That apparently screwed up some programs that tried to execute XBTS/IBTS to see if they were running on early (buggy) 386s so Intel moved CMPXCHG to different encodings (0F B0 and 0F B1). 0F A6 and…
Earlier quoted context omitted.
This is a load of bullshit that largely exists as copium to explain how x86 did the impossible and made a superscalar CISC processor. x86 is doing the same thing that (to my knowledge) all high-end processors do, yet no one tries to call out those chips as compiling to a different internal ISA. But you also don't see any chips trying to run with multiple ISA modes: the closest you get is 32-bit and 64-bit modes coexi…
I haven't kept up with POWER after POWER9, but I recall it to be a true hardwired control RISC, pure as the driven snow. This had some interesting properties (along with other clever designs like eFuses and pNOR) for creating a really credible security posture. They do have a millicode system and chicken bits for oops moments (which are kind of an opposite risk, if you don't get those right for unexpected problems).