Hacker Newsnew | past | comments | ask | show | jobs | submit | thesnide's commentslogin

I'm wondering if we'll see some riscv extensions specifically designed to improve x86/amd64 emulation, such as what the M1 and other did.

Some upcoming chips are supposed to support switching individual processes to x86's "TSO" memory model. That might be the most significant extension that Apple has for x86 emulation: it allows eliding all memory fence instructions used to adapt to the weaker memory model.

LoongArch could have instructions that emulate specific x86 behaviour and flags, but there is practically no documentation available.


Is it just "some upcoming chips" inventing their own extensions? Or is this a standardized ARM extension?

Basically, will writing against these upcoming chips mean writing one implementation for Qualcomm, one implementation for Rockchip, one implementation for Samsung, etc? Or will it just require one implementation for the standard ARM "switch to total store ordering memory model" extension


I'm sorry, I meant RISC-V, not ARM. So far the RISC-V standard has specified behaviour under the TSO memory model and a flag in the ELF header for code that has been compiled for TSO. There is not yet any ratified extension for dynamic switching of memory model but I'd expect anything vendor-specific to be wrapped behind a Linux syscall.

>Is it just "some upcoming chips" inventing their own extensions? Or is this a standardized ARM extension?

RISC-V has an official ratified extension for TSO, and a work-in-progress one for dynamic switching between RISC-V's standard memory model and TSO.


to be fair, it fits my exact needs. and without common javacript bloat.

so kudos to its authors


Ian Jackson (the author of this article) also wrote debbugs.


i'd say that wine has much less dev effort and the specs they re up against aren't as public as the web ones, so huge kudos to the wine team.


i'm starting to wonder what if those rust rewrites might be covert attempt to introduce back doors in plain sight?


for such security devices, there is OTP.

I prefer to have my auth device bricked than compromised.

for anything else, i want to be able to reprogram.

so for vendors, a simple choice :

* be OTP, but no "patching"

* be R/W, but also by its owner


Fair enough. Sort of. You can get the same assurances OTP gives you using secure boot + open source + reproducible builds.

Regardless the rest us who don't want to go through the extra work OTP creates still of use want to put our credit cards, fido2 keys, government licences, concert tickets and whatever else in one general purpose computing device so we don't have to carry lots of little auth devices. To do pull that off securely this device must have firmware I can not change.

The OP wants to make it illegal to sell a device with firmware I can not change.

In asking for that, they've demonstrated they don't have a clue how secure and opening computing works. If they somehow got it implemented it would be a security disaster for them and everybody else.


> more choice and greater value for me

That will exactly follow Netflix's price hikes.

As in "value for money", they silenced the latter part :D


indeed. and the fact that it can be resold at will makes it much worse as you just created an gambling ecosystem


lsw :)


Video tech is driven by pr0n and OS tech is driven by games.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: