Completely off-topic, but: TIL arstechnica has ""vim keybindings"" (j/k) for navigating their comments. It's always fascinating when my muscle memory discovers all the places where j/k works for scrolling.
"arm secure" ... why can't the hardware designer do something simple and clean: remove this arm stuff, don't forget to allow ppl to remove physicaly and easily the bluetooth and wifi modules.
And now, time to write some assembly (without abusing the assembler preprocessor...), coze compilers (aka backdoor injectors, or absurd and grotesque bloats) should become, finally, useless (well some hardware vendor drivers will be provided as gcc/linux C dialect...)
always interesting how i've lived 30 years of life, 10 of which as a reasonably successful backend server/"business logic" developer, and the above comment still sounds like alien language to me :)
If risc-v is successful, no need of those backdoor injectors which are compilers anymore (and absurd and grotesque bloats). Just write risc-v assembly without abusing the macro preprocessor.
A decade ago, some geniuses at the gcc steering committee decided to switch gcc from a simple C dialect to c++. Now you need at least a c++98 compiler to compile gcc (then linux). It is probably one of the biggest mistakes done in the open software, ever. Why, well we all know the abysmal gap in complexity between simple C and c++.
If you don't understand why it is a good thing to generate machine code with an assembler of a few thousands of lines (simple C or even assembly, see fasmg) instead of an absurdely and grotesquely massive (several millions of lines of c++-written code) compiler completely impossible to audit and which generated machine code has to be checked each time it changes... cannot do much about it, sorry.
> why can't the hardware designer do something simple and clean
If it was easy, it would not need firmware in the first place. Firmware is there because people expect certain features and quality of life. See softmodems.
> write some assembly (without abusing the assembler preprocessor...)
Ofc, it could be indeed 100% silicon... but for very complex hardware like GPUs, better to have some jingle software room in order to be able to fix "complexity bugs".
> Firmware often decreases the quality of life. See Intel remote management/backdoor mechanism for example.
IME is a bad example here. That's an entire upgradeable MINIX OS embedded in your system - if it was really firmware, Intel would not be able to update it, or you be able to neuter it.
It depends on the context: GPUs are probably the most complex chips out there, and if you want to them to be ready to render at power on, they probably need firmware (which you would be able to update to fix "bugs") or we end up like what we have now, namely massive drivers locked-in with the gcc C kernel dialect, only there to expose a few 2^n bytes ring buffers (3D/dma/compute/irq/video_encode/video_decode) with their hardware doorbells.
if risc-v is a success we don't need anything except a risc-v assembler: then the main pitfall would be the abuse of the macro preprocessor.
> It depends on the context: GPUs are probably the most complex chips out there, and if you want to them to be ready to render at power on, they probably need firmware
Nvidia believes in shipping a garbage, throttled down and limited firmware to get you some initial rendering, but if you need anything that's not basic rendering, you load a proprietary signed blob, with proprietary "microcode" for it's proprietary GPU instruction set when you initialize the OS graphics driver.
For AMD GPUs the situation is more or less the same, except that without said "binary blob" the GPU isn't on-purpose throttled down near as much.
Or are you implying that we need RISC-V success as a GPU ISA too?
Regarding AMD GPU firmware, let's take the linux case, "bug fixed" firmware images are shipped in the linux firmware repo. The drivers loads those images once some AMD GPU is detected. What's weird is the huge amount of additional work the driver does after loading the firmware images in order to setup the hardware programing interfaces (the command ring buffers and the irq ring buffer). It should be near-0 work beyond loading the "bug fixed" firmware images.
The now open sourced nvidia kernel modules should do something similar I guess: loading "bug fixed" firmware images.
The "near-zero" drivers means the default firmware does provide already the hardware programing interfaces at power on. On such complex hardware, expect bugs in this default firmware. Currently, we have a driver written in gcc kernel C dialect and for linux, not ideal.
I spotted a RISC-V GPU the other day. I guess I wish for CPU/GPU ISAs without toxic PI tied to them (like x86/arm) to succeed. I dunno if AMD GPU isa has any PI tied to them though a la arm though. Rumors: AMD may be interested in RISC-V ISAs for its GPUs and CPUs.
> What's weird is the huge amount of additional work the driver does after loading the firmware images in order to setup the hardware programing interfaces (the command ring buffers and the irq ring buffer). It should be near-0 work beyond loading the "bug fixed" firmware images.
Some (most?) programs expect a high level OpenGL GPU API, instead of dealing with Vulkan/bare-metal directly. Converting some very high level OpenGL calls to actual API is part of what is expected from the driver. To implement this, you would most likely require a high performance, high IPC CPU embedded in the GPU - a waste since you already have one in the system.
> The now open sourced nvidia kernel modules should do something similar I guess
Those open sourced nvidia kernel modules does this - it is "near-zero" as you describe - they just moved almost everything important to the proprietary binary blob loaded to the GPU.
> Rumors: AMD may be interested in RISC-V ISAs
Everyone is interested in RISC-V, not necessarily in user-visible RISC-V ISAs.
When I said the AMD drivers were doing tons of things beyond simple firmware image loading, that was not to prepare for opengl. It is a sh*t ton of additional hardware setup in order to get the basic hardware programing interfaces, those used by opengl _and_ vulkan. If you say that nvidia was successful at getting a near-0 driver once the firmware images were loaded, that would explained the rumors that AMD would like a near-0 driver too.
If true for nvidia, it means their kernel driver is almost empty, some firmware loading, and only memory mappings around for the ring buffers (dunno if nvidia has virtual memory spaces). Without the compute/3D pipeline programing from userspace, the lapsus hackers will feel kind of even more ripped off, since the kernel modules are somewhat basic.
Ofc, when I was talking about RISC-V ISAs, I was actually talking about user visible ISAs.
Sounds great except it doesn't give much information about performance, and the little it says it sounds like it will have performance equivalent to Intel or AMD 20 years ago...
The fact this isn't coming from SciFive or Pinebook makes me suspicious as well, as does the massive lack of details. I can't find anything really on this OEM which is not promising. In this case they'd probably have been better off going kickstarter IMO just to get their names out there and have at least a pretend ounce of accountability.
I tried to grok what "free silicon upgrades" means and the closest I can get is the SoM package is user upgradable. The actual SoM replacement or upgrade module will cost money but you don't need to buy another laptop or pay someone else to do the upgrade for you. Doesn't really fit my definition of "free" but it's my best guess at what's being announced here.
My initial thought was this laptop is somehow FPGA based and new designs can be loaded with near zero cost to the user at the moment of upgrading. But after reading the article, I don't think that's at all what they're implying.
I think the MNT Reform project is heading in this direction. But many people don't want to lug around a laptop that looks like it's straight out of the early 00s.
Thank you for pointing this out. I think most people assume that companies are just being greedy when they solder previously socketed parts, for example. I'm not saying it's never a factor. But it also solves real engineering problems.
Modern technology often requires tighter integration. We accept integrated circuits because we're accustomed to them. But then people flip out when they see what's effectively a naked module because it looks like a greedy version of the old thing.
Trusted execution environments can serve all kinds of useful purposes. Secrets management (TPM/tokens/etc.) is a very common use case, as is DRM (though I don't expect too working DRM on a RISCV system).
If the chip can be disabled or if its firmware can be controlled with custom signatures (i.e. a ROM managed through an open boot mechanism such as coreboot) then I don't see any problems with such a core, even in a fully FOSS system.
It's unlikely that this freedom will actually be given to customers, but I don't see any theoretical problems here.
I think Chinese need badly some open source architecture to "catch up" on the market. Maybe they don't even realize that, but most probably that is their biggest chance to start to exist in a tech world independently.
But if I'm to predict the future - they'll fail as their biggest issue now is that over past 10-15 years they "learned" well how to be "greedy" and are looking for short term maximized profits.
45 comments
[ 3.8 ms ] story [ 87.8 ms ] thread[1]: https://addons.mozilla.org/firefox/addon/vimium-ff/
And now, time to write some assembly (without abusing the assembler preprocessor...), coze compilers (aka backdoor injectors, or absurd and grotesque bloats) should become, finally, useless (well some hardware vendor drivers will be provided as gcc/linux C dialect...)
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
If it was easy, it would not need firmware in the first place. Firmware is there because people expect certain features and quality of life. See softmodems.
> write some assembly (without abusing the assembler preprocessor...)
You want https://terralang.org/ and not "just C"/"just Assembler" instead ?
IME is a bad example here. That's an entire upgradeable MINIX OS embedded in your system - if it was really firmware, Intel would not be able to update it, or you be able to neuter it.
if risc-v is a success we don't need anything except a risc-v assembler: then the main pitfall would be the abuse of the macro preprocessor.
Nvidia believes in shipping a garbage, throttled down and limited firmware to get you some initial rendering, but if you need anything that's not basic rendering, you load a proprietary signed blob, with proprietary "microcode" for it's proprietary GPU instruction set when you initialize the OS graphics driver.
For AMD GPUs the situation is more or less the same, except that without said "binary blob" the GPU isn't on-purpose throttled down near as much.
Or are you implying that we need RISC-V success as a GPU ISA too?
The now open sourced nvidia kernel modules should do something similar I guess: loading "bug fixed" firmware images.
The "near-zero" drivers means the default firmware does provide already the hardware programing interfaces at power on. On such complex hardware, expect bugs in this default firmware. Currently, we have a driver written in gcc kernel C dialect and for linux, not ideal.
I spotted a RISC-V GPU the other day. I guess I wish for CPU/GPU ISAs without toxic PI tied to them (like x86/arm) to succeed. I dunno if AMD GPU isa has any PI tied to them though a la arm though. Rumors: AMD may be interested in RISC-V ISAs for its GPUs and CPUs.
Some (most?) programs expect a high level OpenGL GPU API, instead of dealing with Vulkan/bare-metal directly. Converting some very high level OpenGL calls to actual API is part of what is expected from the driver. To implement this, you would most likely require a high performance, high IPC CPU embedded in the GPU - a waste since you already have one in the system.
> The now open sourced nvidia kernel modules should do something similar I guess
Those open sourced nvidia kernel modules does this - it is "near-zero" as you describe - they just moved almost everything important to the proprietary binary blob loaded to the GPU.
> Rumors: AMD may be interested in RISC-V ISAs
Everyone is interested in RISC-V, not necessarily in user-visible RISC-V ISAs.
If true for nvidia, it means their kernel driver is almost empty, some firmware loading, and only memory mappings around for the ring buffers (dunno if nvidia has virtual memory spaces). Without the compute/3D pipeline programing from userspace, the lapsus hackers will feel kind of even more ripped off, since the kernel modules are somewhat basic.
Ofc, when I was talking about RISC-V ISAs, I was actually talking about user visible ISAs.
Besides not publishing pricing or detailed specs this close to the planned shipping date, this rings so many alarm bells.
Modern technology often requires tighter integration. We accept integrated circuits because we're accustomed to them. But then people flip out when they see what's effectively a naked module because it looks like a greedy version of the old thing.
Is it me or is one of the main RISC-V advantage is that it's free of mandatory backdoors ? Why would you need this enclave ?
If the chip can be disabled or if its firmware can be controlled with custom signatures (i.e. a ROM managed through an open boot mechanism such as coreboot) then I don't see any problems with such a core, even in a fully FOSS system.
It's unlikely that this freedom will actually be given to customers, but I don't see any theoretical problems here.
But if I'm to predict the future - they'll fail as their biggest issue now is that over past 10-15 years they "learned" well how to be "greedy" and are looking for short term maximized profits.