Loongarch Improvements with Box64
box86.org
Loongarch Improvements with Box64
1–7 of 7 posts
Re: Loongarch Improvements with Box64
#2I'm wondering if we'll see some riscv extensions specifically designed to improve x86/amd64 emulation, such as what the M1 and other did.
Re: Loongarch Improvements with Box64
#3I'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.
Re: Loongarch Improvements with Box64
#4I'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
Re: Loongarch Improvements with Box64
#5Why editorialize the title?
Actual title is "New Box64 v0.4.0 released".
I get you're trying to summarize it, but what's most relevant depends on the person reading.
Re: Loongarch Improvements with Box64
#6Earlier quoted context omitted.
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
>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.
Re: Loongarch Improvements with Box64
#7Earlier quoted context omitted.
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.