Jim said in the video that the ISA didn't matter, from a software perspective as he was talking about porting between architectures. I expect abstractions such as LLVM help more than ever with portability. I suppose it will become even less relevant in the future. That's why I thought he was talking about the licensing aspect (and still do).
But your comment that AMD doesn't have to care about the ISA is thought provoking. Could AMD pivot to a different ISA and still maintain a strong technological/competitive edge? There's no need to, if the ISA doesn't really matter, but could Intel be left behind with the weight of their legacy while AMD develops or adopts a different ISA?
RISC-5
-
Little stoned kiwi
- Baaaaaa!
- Posts: 4597
- Joined: Mon Oct 27, 2003 6:05 am 0
- Location: Christchurch
Re: RISC-5
If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy.
Re: RISC-5
It's just that the technology that makes a CPU go really fast is largely ISA-agnostic (for ultra performance cores at least; it certainly can matter more if you're trying to make a very small and low power core that doesn't have out-of-order execution).
Anyone can pivot to any ISA if they want, but for many use cases the ISA ecosystem (i.e. Windows -> x64) is the most important part. (Which has always been true. This billion-transistor Ryzen CPU is based on the architecture of a discrete logic 1972 terminal because backwards compatibility is a doozy).
Anyone can pivot to any ISA if they want, but for many use cases the ISA ecosystem (i.e. Windows -> x64) is the most important part. (Which has always been true. This billion-transistor Ryzen CPU is based on the architecture of a discrete logic 1972 terminal because backwards compatibility is a doozy).
Re: RISC-5
RISC is good.
(Sorry, couldn't resist the meme.)
(Sorry, couldn't resist the meme.)
"Words ought to be a little wild - for they are assaults of thought on the unthinking."
- John Maynard Keynes
- John Maynard Keynes
Re: RISC-5
I've not messed with RISC-V yet.
Though I have posted about it in the past, about how rapidly it's advancing - how there's RISC-V SBCs out there, which aren't that far behind the Raspberry Pi now, and SiFive even made a RISC-V Linux PC. But, well, it's new stuff, so I'm waiting for a RISC-V SBC or Linux PC that's got the same sort of price tag as a Raspberry Pi or x86 desktop. I'm curious about it all, but not "waste loads of money on prototypes" curious. Once it's genuinely, price-wise, an equivalent competitor, then I might grab one to play with.
But one thing I've noted in discussions about this is that ARM does something that's not in the RISC-V "core" (though I do believe there is an RISC-V extension that introduces these instructions).
ARM has condition codes within machine instructions. So you can have stuff like "move if not zero" and the move instruction only happens when the processor flags say "not zero".
The benefit of this is that you can write more "branch-less" code in the first place.
Admittedly, if the condition isn't true, the instruction becomes a wasteful "NOP" for that cycle, but better that than flushing the entire pipeline and starting again. To implement it as a more traditional "BNE JumpOverNext; MOV; JumpOverNext:" sequence, with a branch that may or may not be taken, and could force a flush - for the sake of skipping over a single instruction, which really ain't worth all the hassle.
When, instead, you can have a bunch of condition codes - "if not zero", "if greater than", "if overflow", etc. - in the machine instruction themselves and make every single instruction potentially conditional to support more "branch-less" code (there will still be branches - can't be avoided entirely - but if you can do conditional stuff without taking any branches in the first place, then you can keep the pipelines filled. "Prevention is better than cure", to just not have as many branches in the first place).
Plus, also, simply less bytes - condition codes are just bits in the instruction itself, rather than a whole sequence of bytes to wade through for the traditional conditional-branch-over-a-single-instruction.
This sort of thinking, though, is apparently not in the RISC-V "core".
But I think I'm with Dio that, increasingly, the ISA isn't that important. The RISC-V advantage is not in it being "the best ISA ever", it's that it's an open source ISA. Anyone can make a RISC-V chip, without paying any licence fees.
THAT is the advantage. You are actually likely taking a step backwards - x86 and ARM have a lot of maturity to them, after all - to go with RISC-V. But the advantage is gained from no licence fees and being able to Frankenstein together a bunch of "extensions" that suits what you need, and drop the rest. It's going to have tremendous cost and control advantages.
Mind you, I'm a Linux user, so I can immediately say "expect fragmentation" (because this is the intrinsic price of "freedom" - if anyone is allowed to do whatever they want, then people WILL do things in 999 different ways every time and, indeed, that's just what "freedom" looks like. It's good but it's always a bit messy / janky with it. If you're a big fan of perfectly regimented uniformity, then fascism's what you're looking for, not "free as in freedom". Them Nazis always looked dapper in their Hugo Boss uniforms).
But the RISC-V "core" is compatible. And while the presence of a particular "extension" is not guaranteed, those are compatible when present (and one can imagine that, in future, some of these extensions become "core" later on - just like how AMD and nVidia introduce new things as OpenGL / Vulkan extensions, but once it's proved itself and everyone's implemented it, it's now "core" in a future release).
Though I have posted about it in the past, about how rapidly it's advancing - how there's RISC-V SBCs out there, which aren't that far behind the Raspberry Pi now, and SiFive even made a RISC-V Linux PC. But, well, it's new stuff, so I'm waiting for a RISC-V SBC or Linux PC that's got the same sort of price tag as a Raspberry Pi or x86 desktop. I'm curious about it all, but not "waste loads of money on prototypes" curious. Once it's genuinely, price-wise, an equivalent competitor, then I might grab one to play with.
But one thing I've noted in discussions about this is that ARM does something that's not in the RISC-V "core" (though I do believe there is an RISC-V extension that introduces these instructions).
ARM has condition codes within machine instructions. So you can have stuff like "move if not zero" and the move instruction only happens when the processor flags say "not zero".
The benefit of this is that you can write more "branch-less" code in the first place.
Admittedly, if the condition isn't true, the instruction becomes a wasteful "NOP" for that cycle, but better that than flushing the entire pipeline and starting again. To implement it as a more traditional "BNE JumpOverNext; MOV; JumpOverNext:" sequence, with a branch that may or may not be taken, and could force a flush - for the sake of skipping over a single instruction, which really ain't worth all the hassle.
When, instead, you can have a bunch of condition codes - "if not zero", "if greater than", "if overflow", etc. - in the machine instruction themselves and make every single instruction potentially conditional to support more "branch-less" code (there will still be branches - can't be avoided entirely - but if you can do conditional stuff without taking any branches in the first place, then you can keep the pipelines filled. "Prevention is better than cure", to just not have as many branches in the first place).
Plus, also, simply less bytes - condition codes are just bits in the instruction itself, rather than a whole sequence of bytes to wade through for the traditional conditional-branch-over-a-single-instruction.
This sort of thinking, though, is apparently not in the RISC-V "core".
But I think I'm with Dio that, increasingly, the ISA isn't that important. The RISC-V advantage is not in it being "the best ISA ever", it's that it's an open source ISA. Anyone can make a RISC-V chip, without paying any licence fees.
THAT is the advantage. You are actually likely taking a step backwards - x86 and ARM have a lot of maturity to them, after all - to go with RISC-V. But the advantage is gained from no licence fees and being able to Frankenstein together a bunch of "extensions" that suits what you need, and drop the rest. It's going to have tremendous cost and control advantages.
Mind you, I'm a Linux user, so I can immediately say "expect fragmentation" (because this is the intrinsic price of "freedom" - if anyone is allowed to do whatever they want, then people WILL do things in 999 different ways every time and, indeed, that's just what "freedom" looks like. It's good but it's always a bit messy / janky with it. If you're a big fan of perfectly regimented uniformity, then fascism's what you're looking for, not "free as in freedom". Them Nazis always looked dapper in their Hugo Boss uniforms).
But the RISC-V "core" is compatible. And while the presence of a particular "extension" is not guaranteed, those are compatible when present (and one can imagine that, in future, some of these extensions become "core" later on - just like how AMD and nVidia introduce new things as OpenGL / Vulkan extensions, but once it's proved itself and everyone's implemented it, it's now "core" in a future release).
"Words ought to be a little wild - for they are assaults of thought on the unthinking."
- John Maynard Keynes
- John Maynard Keynes
Re: RISC-5
I just learned about delay slots some months ago. My brain is still hemorrhaging.Dio wrote:things like branch delay slots
This is an obvious manifestation of the "the compiler knows best" idea, programming those ISAs in assembly is brutal. The conditional instructions of the ARM ISA are a stroke of genius, the "nop" argument is moot, if you have to use a branch instruction, that takes cycles, too.
Re: RISC-5
The main cost if you put a NOP in a branch delay slot is code density, which does turn out to be important - there's a reason ARM moved from the no-decode 32-bit instructions to the some-decode Thumb, because it turns out wasting bits in your instruction - yes, including conditional fields - with stuff you rarely use means you need more icache.
Nothing's too brutal about MIPS. VLIW architectures are much, much worse.
Nothing's too brutal about MIPS. VLIW architectures are much, much worse.