search

ptitSeb / box64

Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices
https://box86.org
MIT License
3.9k stars 288 forks source link

[LA64_DYNAREC] Made eflags synchronization lazy #1329

Closed ksco closed 8 months ago

ksco commented 8 months ago

image

Isn't this gorgeous?

ptitSeb commented 8 months ago

Mmm, so it's not that flag sync is lazy, it's that part of the eflags (cznaps) are handled exclusivly by lbt, while the others are still on eFlags. Sync would be lazy if the f struct had a lbt_ok flag to track when flags are in lbt and when there are not. Here, everything that change / read flags needs a lbt code path to handle lbt eflags.

ptitSeb commented 8 months ago

image

Isn't this gorgeous?

The ORI x3, x3, 0 is useless and can be removed, that would make the code even tastier ;)

ksco commented 8 months ago

Mmm, so it's not that flag sync is lazy, it's that part of the eflags (cznaps) are handled exclusivly by lbt, while the others are still on eFlags. Sync would be lazy if the f struct had a lbt_ok flag to track when flags are in lbt and when there are not. Here, everything that change / read flags needs a lbt code path to handle lbt eflags.

Ah, ok, that would be more complicated to implement I think. Considering the LBT extension cover most of the scenarios (or is it?), the simple method here should be enough (or is it?)

The ORI x3, x3, 0 is useless and can be removed, that would make the code even tastier ;)

Yeah, the MOV64xw macros is over-simplified now.

ptitSeb commented 8 months ago

Mmm, so it's not that flag sync is lazy, it's that part of the eflags (cznaps) are handled exclusivly by lbt, while the others are still on eFlags. Sync would be lazy if the f struct had a lbt_ok flag to track when flags are in lbt and when there are not. Here, everything that change / read flags needs a lbt code path to handle lbt eflags.

Ah, ok, that would be more complicated to implement I think. Considering the LBT extension cover most of the scenarios (or is it?), the simple method here should be enough (or is it?)

That should be enough, but the constraint "always a lbt code path" should be clear for everyone doing commit on LA64. Stuff like PUSHF / POPF will need special care. Not sure MUL/IMUL are also covered by lbt (it's not too difficult to do anyway).

The ORI x3, x3, 0 is useless and can be removed, that would make the code even tastier ;)

Yeah, the MOV64xw macros is over-simplified now.

Later optim....

ksco commented 8 months ago

but the constraint "always a lbt code path" should be clear for everyone doing commit on LA64.

Yeah, but you mean we do by pay special attention to it when reviewing or have some kinda docs?

ptitSeb commented 8 months ago

but the constraint "always a lbt code path" should be clear for everyone doing commit on LA64.

Yeah, but you mean we do by pay special attention to it when reviewing or have some kinda docs?

Unsure. Probably both. At least, we start with the review, then document if needed?