Cheaplets
Looks like CPUs get their microservices equivalent. wrong What go can ?
A Silicon Valley startup is stepping out of stealth mode today, publicly vowing to supply high-performance data-center-class RISC-V processors. Ventana Micro Systems said since its founding in 2018 it has secured $53m in funding in series A and B rounds, the latter of which totaled $38m and was led by Marvell founders Sehat …
"The CPU core running that code sees those instructions and communicates with the custom die to complete the operations fast, and returns the results to the calling code "
And to think that we all thought that Meltdown and Spectre were the worst that could happen. Now a hacker is going to be able to actually re-code the CPU.
And you'll never notice.
Neither will AV software.
Welcome to the future !
Meltdown/Sceptre rely on understanding cache timing relationships to determine the contents of ostensibly unreadable memory. What an attacker is going to learn from timing a co-processor operation depends on what the co-processor designer deems important -- the microcode in the co-processor could be adjusted to always give the result during a specified window rather than a result as quickly as possible if that was thought to be important.
RISCs by design have simple, regular, instruction sets so nobody's going to be able to re-code those instructions. Extensions are usually implemented by an unimplemented instruction trap vectoring to code or hardware that decodes the apparently failing instruction and dispatches it to the relevant routine or piece of hardware but in this design the processor's instruction decoder itself identifies the instruction and alerts the relevant co-processor.
I like LibreSoC's approach to hardware Spectre mitigation, block access the timing side channel if required.
"Spectre-style timing mitigation
Spectre-style timing attacks are defined by one instruction issue affecting the completion time of past and future instructions. The key insight to mitigation against such attacks is to note that arbitrary untrusted instructions must not be permitted to affect trusted instructions. Consequently as long as there is a firebreak (a "Fence") between trusted and untrusted, timing attacks can be held off.
Two instructions ("hints") shall therefore be added:
One that stops speculation, multi-issue and any out-of-order resource allocation for a minimum of 16 instructions.
Another that cancels all speculation and reservations, cancels "nameless" registers, waits for and ensures that all outstanding instructions have completed and committed, before permitting the processor to continue further.
This latter shall occur unconditionally without requiring a special instruction to be called, on ECALL as well as all exceptions and interrupts."
(ref: https://libre-soc.org/3d_gpu/requirements_specification/ )
In the (equally royalty-free) Power & MIPS ISAs there are provisions for co-processors right in the ISA itself, which it sounds like what these guys are advertising, only by brutalising an ISA and making it incompatible with standard toolchains.
You'd think that as essentially a straight MIPS clone, RISC-V would have similar provisions instead of making ecosystem (and ISA) fragmentation seem like a feature. But maybe custom ISAs without all the effort was what these customers are going for anyway?
You post demonstrates a significant level of ignorance about the state of previous ISAs and about how and why RISC-V architecture is looking towards todays requirements and those anticipated in the future.
Your comment on tool chains is nonsense, the same tool chains and the their optimizations are already being utilised by the new ISA. However there will still be variations, like with Intel/AMD have concerning ahead of time optimizations like instruction scheduling because Intel Netbust works differently to Skylake. This area of optimization is set to explode because there will be a zillion different implementations in silicon of RISC-V.
Luckily they will all still run the same code ok just some specific silicon may do something in one clock cycle and another take three.
Of course everything has a coprocessor in the era of SoC.
The demarcation between what is the CPU, what is hardware is getting ever more vague. Take a look at modern RISC multiply/divide methods. The custom silicon that is considered CPU will be more like SIMD for things like neural net maths.
You keep your POWER and MIPS ISAs they don't scale so well from the 512bytes ram microcontroller all the way upto 512exabyes ram datacenter storage array. They also bring with them their own unique baggage that the world does not need today. They were great in their day, but if you could start over would you simply remake them again? Or take their best ideas and make something better?