Posted by Narishma 5 hours ago
This is especially good if one scopes out a family of ISAs that are ABI compatible such that one can compile down to a semi-pre-optimized portable IR, and just do the last bit per ISA.
And the approach you mentioned here:
> a family of ISAs that are ABI compatible such that one can compile down to a semi-pre-optimized portable IR, and just do the last bit per ISA
I think this is basically WebAssembly and PTX, and one may argue, Java bytecode. Yet look at how much efforts and time it took for WASM runtimes and JVMs to actually produce performant machine code (the "last bit per ISA" you mentioned) for just a couple of architectures! (e.g. X86 and ARM). And I wouldn't surprised if NVIDIA pour even more money on building optimization pipeline from PTX to each of their different uArchs.
I bet it would be pretty easy for a user to interoperate between 67 different drafts of the HTTP spec once they were all written, validated, and library implementations coded. But what would that Cambrian explosion of API revs actually get you?
I mean that is not even 10 page view per second. We are not living in 2006. Actually even in 2006 Apache with static page would have been able to handle that on a small VPS. And that is excluding CDN.
Your Requests: 500 Request Limit: 500 per minute
Your Requests: 500 Request Limit: 500 per minute
with no vpn
The 386 and 486 patent should have expired more than 20 years ago. No one tried to open source it. https://github.com/EI2030/Low-power-E-Paper-OS/blob/master/0... There were many companies that had clones in the early 90s, and I wonder whether any of them still have the rights to manufacture them.
" That is a better reason than elegance. and I want to tell Mr Grinberg, that the word priviledge he tosses around in his article also extends beyond the ISA depending on where you are in the world."
Grinberg is an emigre from Ukraine, which isn't the most privileged place in the world. In fact his research articles go deeper than the average software developer in Silicon Valley.
Edit: It also appears Nvidia might also have an x86 license: https://www.nvidia.com/en-us/drivers/uli-m6117c/
Also, https://www.tomshardware.com/pc-components/cpus/intel-licens... (Caveat: The startup is acquainted with the Intel CEO, so it's rare for them to grant the x86 license to non-buddies.)
"Intel provided Rosaic access to an unknown Atom-class core, which enables the company to build its own custom processors based on x86 general-purpose cores, according to the report. The renowned chipmaker plans to ship Rosaic register-transfer level (RTL) code for the Atom processor core, which will let the startup build its custom system-on-chip (SoC) both at Intel Foundry and elsewhere."
What's interesting is that a startup with limited funds would most likely seek a 32-bit x86 license if a) they don't need more than 4GB of RAM, and b), if they don't want to pay AMD for the 64 bit license add-on. :)
OpenFirmware came out of OpenSPARC and is also used by POWER too. Parts of it are used in ARM and RISC-V today (mostly DeviceTree, though arguably quite badly).
Nobody actually wants to make good cores for cheap. Nobody wants to make compatible systems unless forced to. That's why ARM and RISC-V are fragmented messes.
I would personally love to see more Power Systems based projects. Everything is out there, just someone has to want to do something with it.
Fedora Linux even fully supports POWER8+ little-endian systems, and Fedora KDE offers a live ISO you can install on something like a Talos Workstation.
https://lists.libre-soc.org/pipermail/libre-soc-dev/2024-Sep...
To do that they, at least, should still exist. For most of them this is not the case.
I read the "They Should Have Known Better" article and forgot it. I've seen this before. I know it's hot air and does not matter, and I can't afford to worry about things that don't matter.
When I say I've seen this before, I'm talking about ancient history: controversies so old and so laughable that they've been forgotten. When, for example, AMD handed the world AMD64/X86_64, the same things were said: fragmentation, legacy+flawed ISA, etc. That has not aged well, and "They Should Have Known Better" won't either.
The "fragmentation" argument has no merit. The jumble of extension names and profiles in RISC-V are, in fact, direct evidence that RISC-V is succeeding: it's the RISC-V ecosystem aggressively, collaboratively and successfully tackling pain points and solving them. This is what RISC-V is supposed to be doing, and it's doing it, and empires are being built on it.
Take this part: "The existence of CLIC and various proprietary 'fast IRQ' / auto-stacking extensions is an additional indictment."
CLIC is miraculous. It's an advanced embedded interrupt controller, and it's wonderful: it brings the equivalent of ARM's NVIC to RISC-V, except better. You can implement an extremely efficient scheduler that guarantees deadlock-free concurrency: bare-metal, real-time, hardware-accelerated "Fearless Concurrency," on an MCU with no RTOS![1] Its appeal is so great that, despite still being a draft spec, the leading RISC-V MCU designers are adopting it. Espressif's ESP32-S31 has it, for example. The chaotic emergence of this awesome thing is what is condemned as an "indictment."
Speaking of ESP32-S31, it's going to be a monster when silicon becomes available in quantity. This RV Embedded writing mentions MMUs a lot. Guess what? The S31 has an Sv32 MMU. It can run Linux. Not μClinux. Real Linux. It's already been done twice (that I know of) on the Espressif eval boards. People like Armstrong Subero are going to change the world with it.
That's the froth of RISC-V. The ground is shaking, and the peanut gallery of ISA wizards has no power over it. In a few years, after RISC-V has lain waste to our world of proprietary ISAs and Western IP regime rent seeking, "They Should Have Known Better" will look as silly to everyone as it already looks to me.
> Simply put, the things a high-end CPU needs are diametrically opposed to the things a small cost-saving microcontroller core needs.
> The conclusion he draws is that no single ISA can serve both ends, and that RISC-V fans are fooling themselves, in theory the premise is true. The conclusion does not follow, and I can show you why from three parts sitting on my desk as we speak.
> CH32V003. This is the cheap "RV32EC" with sixteen registers, no multiplier, no divider, machine mode only,
> CH32H417. A dual core MCU that is unmatched in performance to price point and is at the higher end of the MCU line
> Baochip. A VexRISC-V with an MMU built around a stack thats open from silicon to os Baochip-1x: A Mostly-Open, 22nm SoC for High Assurance Applications
Uh, which one of these is a datacenter server cpu? Or a workstation cpu? Or at least a developer laptop cpu? How about a Raspberry Pi 4 level SBC (supporting latest ubuntu and fedora releases, driving a display that runs a browser and plays video ...)
There's a lot of angry indignation but it seems obvious that Dmitry is quite right about this.
But I found this is where this blog post starts making a lot of sense:
> Has anyone tried adding an MMU to a Cortex-M? The physical tradeoffs are real, the difference is that with RISC-V, the ISA owner does not decide for you where that boundary must be drawn. If you want virtual memory on ARM you license a Cortex-A instead, which is a different core family, a different profile, a different negotiation, and a different royalty.
> Compare what happened with Baochip. The RISC-V privileged specification defines supervisor mode and Sv32 paging as optional things an implementation may provide. VexRISC-V is an open core, somebody added an MMU to it. bunnie built a chip around it and runs a microkernel with real process isolation on it
Yeah, that is a good point. We're still in the low-end specialty realm, but that is real interesting advantage for RISC-V, a good reason for it to exist.
As for shipping to Trinidad and Tobago ... this post is trying too hard to turn this into moral issue, but it seems a bit random (OrangePi cost $30 and shipped free? you can also get arm-based and stuff from the same places), and the vast majority of people don't live on semi-remote islands, it doesn't make sense to consider this kind of accessibility above all else, and it's strange to blame Dmitry for not thinking of you here.