Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #118786

Re: Binary translation

Show all headers | View raw

On 10/23/2026 2:55 AM, Anton Ertl wrote:
> BGB <cr88192@gmail.com> writes:
>> On 10/22/2026 11:47 AM, Anton Ertl wrote:
>>> OTOH, it seems to work ok for Apple with Rosetta.
>>>
>>
>> Yes.
>>
>> ARM64 works well here.
> 
> I think that Apple's *implementations* of ARM A64 (all OoO on the
> Macs) work well.
> 

OK.

So, yeah, maybe not so hot then on the A53 or similar in a cheap 
smartphone?...

Have noted that things like DOSBox do seem to be painfully slow, but had 
mostly just figured it was DOSBox just using a plain interpreter in this 
case or something.


>> There also seems to be some interest in the RISC-V space for dynamic
>> translation of x86 to RISC-V; though emulating x86 on RISC-V is likely
>> to lead to a not exactly small number of things that are difficult to
>> emulate efficiently (EFLAGS being almost kinda evil in some ways; and
>> then on an ISA that is in some ways rather poorly equipped to try to
>> fake it).
> 
> The flags are always a problem, and I don't think that ARM A64 has
> significant advantages over RISC-V here.  Yes it has flags of its own,
> but the instructions do not set them the same way as AMD64.  AMD64 has
> instructions that sometimes set the flags and sometimes don't, it has
> instructions that set C and/or V separately from NZP.  And AFAIK ARM
> A64 has subtract with carry (and corresponding carry handling on
> compares), while AMD64 has subtract with borrow; so the meaning of the
> carry is inverted between the two after a subtract or compare
> instruction, while it agrees after an add instruction.
> 

The main thing I think would be to have some way to cheaply compute them 
and store them away until needed (or restore them from a snapshot state, 
do the op, and then snapshot them again).

Potentially, with the snapshots of the non-x86 flags, one could use 
these to synthesize the x86 view of the flags if/when they became 
architecturally visible in the x86 space (with things like moving bits 
around or inverting some bits, etc, being potentially cheaper than fully 
faking the flags).


> So the binary translator essentially has to prepare for the worst case
> and generate all the AMD64 flags in case they are then used in a way
> that the binary translator does not see (e.g., after an indirect
> branch), and if the usage is known, can eliminate most or all of this
> flag-generation code.  Pretty much the same for RISC-V.
> 

OK.

When I tried before, I had a lookahead to detect if a later instruction 
would fully mask away any flags updates from the current instruction, 
and if so emulate it as a no-flags variant.

But, this still meant needing to emulate flags for when they were not 
needed. But, in this case, was doing logic to directly mimic the state 
of EFLAGS.

And, then there were instructions that update parts of a register:
   ADD AX, CX
   XCHG AL, DH
   ...

That can also be a hassle sometimes.


But, it has been a long time.
After I wrote an x86 emulator originally, I realized I didn't have a 
strong use-case. The use-cases I had thought I had was better served by 
"just recompiling stuff" or "compile stuff to nearly anything other than 
32-bit x86, and use that instead".


As can be noted, my newer custom emulators (such as jx2vm) still use a 
very similar structure internally to my original x86 emulator.

Decode as traces, dispatch via a big hash table, and interpret by a 
sequence of decoded instructions with function pointers, ...

All this was stuff that was originally used in that interpreter.
Decoder was a bit different, as ironically I was effectively using a 
listing-driven disassembler for the first pass of the instruction 
decoding. First it would disassemble the instruction and then use the 
mnemonic and instruction-form and similar to select which function 
pointer to use.


Had considered trying to use big switch blocks over the bytes to decode 
x86, but this is a more painful way to try to approach x86 decoding vs 
the use of looking something up in a listing (and the encoding rules are 
reasonably consistent if taken from the POV of an instruction listing; 
just arguably bulkier and less efficient).

Well, similar for writing an assembler:
   Listing: OK;
   Big switches and byte crafting: More painful.

Kind of an inversion from the case of RISC-style ISAs.


> - anton

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-18 18:39 +0000
  Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-18 18:47 +0000
    Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-18 22:00 +0000
      Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-20 17:12 +0000
  Re: Almost Ready to Repeat the Cycle jgd@cix.co.uk (John Dallman) - 2026-10-20 20:21 +0100
    Re: Almost Ready to Repeat the Cycle BGB <cr88192@gmail.com> - 2026-10-21 15:28 -0500
      Re: Almost Ready to Repeat the Cycle John Levine <johnl@taugh.com> - 2026-10-22 04:52 +0000
        Re: Almost Ready to Repeat the Cycle Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-22 23:42 +0100
      Re: Almost Ready to Repeat the Cycle MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-22 16:10 +0000
        Re: Almost Ready to Repeat the Cycle anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-22 16:47 +0000
          Re: Almost Ready to Repeat the Cycle BGB <cr88192@gmail.com> - 2026-10-22 20:23 -0500
            Binary translation (was: Almost Ready to Repeat the Cycle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 07:55 +0000
              Re: Binary translation BGB <cr88192@gmail.com> - 2026-10-23 03:50 -0500
                Re: Binary translation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 16:21 +0000
                Re: Binary translation jgd@cix.co.uk (John Dallman) - 2026-10-23 23:51 +0100
              Re: Binary translation antispam@fricas.org (Waldek Hebisch) - 2026-10-25 00:10 +0000
                Re: Binary translation aph@littlepinkcloud.invalid - 2026-10-25 19:49 +0000
          Re: Almost Ready to Repeat the Cycle Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-22 15:45 -0400
            Binary translation (was: Almost Ready to Repeat the Cycle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 08:13 +0000
              Re: Binary translation (was: Almost Ready to Repeat the Cycle) Michael S <already5chosen@yahoo.com> - 2026-10-23 12:24 +0300
                Re: Binary translation (was: Almost Ready to Repeat the Cycle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 16:41 +0000
              Re: Binary translation (was: Almost Ready to Repeat the Cycle) jgd@cix.co.uk (John Dallman) - 2026-10-23 23:51 +0100
            Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-23 14:53 +0000
              Re: Almost Ready to Repeat the Cycle quadibloc@invalid.com (John Savard) - 2026-10-23 15:08 +0000
          Re: Almost Ready to Repeat the Cycle jgd@cix.co.uk (John Dallman) - 2026-10-23 17:22 +0100
            Re: Almost Ready to Repeat the Cycle anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-23 21:20 +0000

csiph-web