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

you don't like my title?


Your title is fine. Idk what they're talking about.


I tried to fix the typo. It should be better now. And yeah, Box86/Box64 let you run x86 linux programs on non-x86 platforms, like Rosetta on macOS.


New releases, with some benchmarks acrosse previous version and vs Rosetta. Also introducing Box32 to run 32bits apps on 64bits systems


IMHO title of the blog post sabotages visibility when posted in places like HN.

It would be better if it contained some details on what is new, like "Native Flags (RISC-V, ARM), Strong Memory Emulation".


Thanks for the tip, I'll try to keep that in mind next time :)


Actually, Box64 can also store operands for later computation, depending on what comes next...


No, it's Box64, a completly different project.

(But I do remember the time I had an Amstrad PC1512 too :D )


It will be interesting to try out Box64 as soon as I get my hands on some suitable RISCV hardware. I have played with RISCV microcontrollers they're quite nice to work with.


The milk-v pioneer comes with 128GB of RAM.


New version of Box86 and Box64 out. Box64 now support RISC-V Dynarec. Also support 32bits proces in experimental Wine WoW64.


Dynarec can optionnaly handle Strong Memory Model emulation, but it's disable by default to have maximum emulation speed (it's the BOX86_DYNAREC_STRONGMEM env. var.).


The presence of Zba and Zbb extension is tested before using it.


Yes, it would be more efficiant, but it will also be more costly to generate. It would also render the handling of Signal more tricky (need to always be able to go back from the RV64 address to the orignial x86_64 address in case of a SEGFAULT for example). Also, intra-block jump make this more complicated. Box64 does a limited full-block optimisation for the Flags handling and SSE/x87/MMX register attribution, but that's pretty much. Some constant propagation mecanism would be nice and could save a lot of opcode, but no worked as been done it that direction for now (maybe later, it always bother me when I look at generated code dump to see also those multiple constant assigned multiple time).


Constant propagation and also tracking of nonzero bits has been a huge performance improvement in QEMU. The latter helps a lot with x86's automated zero extension, because if you know the high 32 bits are zero you can use a 64-bit move instead of an AND.

But QEMU only does one basic block at a time without jumps so it's relatively easy to implement.

(I tested "7z b" and QEMU user mode emulation is about 30% for x86-on-x86, I'm curious to see how it fares for x86-on-RISCV but I don't have a board to test on).


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

Search: