Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext ThreadShow in Flat Mode*

SubjectRe: Ahhh! That's genius! Reply to this message
Posted byElSemi
Posted on12/14/03 05:18 AM

> > I'm wondering if (because C makes quite a good job on the register copies but
> a
> > bad job on the flag calculation) dead flag analysis could bring C emulators
> very
> > close to Asm ones and possibly even past them!
> You could always write a better emulator in assembly which uses the same trick.
> What's nice about this approach is that you don't have to worry about
> instruction decoding anymore. This can normally take a considerable amount of
> time and memory. If you look at the fast assembly 68K emulators, they generate
> many different permutations of each instruction simply to avoid having to
> extract register fields.
> Starscream and Turbo68K had mostly the same approach and generated a lot of
> instructions. A68K is faster and I think that's mostly due to the fact that it
> generates much less code.
> I'm not sure exactly what Generator does, but you can easily generate different
> permutations for instructions based on flags and then have a fetch/decode stage
> which outputs code like this:
> push reg1
> push reg2
> call _OpXXXX
> add esp,4
> push reg1
> push reg2
> call _OpYYYY
> ... etc. ...
> Or, to make it truly portable, have an array of structs of a type like this:
> struct instruction
> {
> void (*Handler)(struct instruction *);
> UINT32 field1, field2, field3, etc. ;
> };
> And simply iterate through this. I think this is what ElSemi was talking about
> (correct me if I'm wrong.)
> It's a good approach, especially when you don't have to keep re-fetching code
> (if it's mostly in ROM, for instance, or in protected non-writeable memory
> pages) and you want to avoid having to write a full-blown dynarec.
> I don't know if it would be worth it for emulating a 68K on X86, though. Flag
> calculation is simple (LAHF, SETO AL), and decoding can be pretty optimal, as
> A68K shows.
> It's probably great for something like ARM or a low-end MIPS or PPC.
> ----
> Bart

Actually, I instead of pre decoding to the register value, I predecode to the pointer of the register.
I have 2 cases:

For the CPUs that don't have implicit side effect on register access (like i960 and SHARC) I store the address
of the register to read/write, with a structure like this:

struct _Inst
void (*Op)();
UINT32 *src1,*src2,*dst;


this way, an opcode like ADD can be written as:

void ADD()

in the case of cpu with register side effects, like the MB86235 used in model2c, I store handlers to perform
the register reading. Also DSPs can perform more than 1 op in the same inst in parallel, so all regs must be
fetched before any write. I can't use direct register write in the handlers because the "next" microop in the
same opcode might be reading the reg we have already written, and it will read the changed value,
not the original one, thus making the execution sequential, and not parallel.

struct _TGPInst
void (*OP);

UINT32 (*GetASrc1)();
UINT32 (*GetASrc2)();
void (*SetADst)(UINT32);
UINT32 (*AOP)();


OP controls the execution order of the ops, so a typical ADDER+MUL op is

void ALU2()
UINT32 ADD=thisinst->AOP();
UINT32 MUL=thisinst->MOP();


void AADD()
UINT32 dst=thisinst->GetASrc1()+thisinst->GetASrc2();
AFLAGS(dst); //This just compute simple flags like ADDERZero and ADDERSign.
return dst;

also side effects must be performed in the correct priority order. Emulating DSPs is a real pain :).

about the flags thing, I think I could generate the flags and noflags variation of each alu operation, using the
noflags by default and then when finding a conditional inst, trace back to the first op instruction that affects
that flag and replacing the handler by the flags version. I haven't thought on it too much, but it might have
some trouble with flags at the end of subs and such. I'll try when I have some free time.

Entire Thread
Subject  Posted byPosted On
*Does Generator have a 68000 Dynarec?  finaldave12/10/03 03:35 PM
.*Re: Does Generator have a 68000 Dynarec?  Bart T.12/10/03 03:48 PM
..*Ahhh! That's genius!  finaldave12/11/03 05:03 AM
...*Re: Ahhh! That's genius!  smf12/12/03 07:56 AM
....*Re: Ahhh! That's genius!  ElSemi12/13/03 07:31 AM
.....*Re: Ahhh! That's genius!  finaldave12/13/03 05:19 PM
......*Re: Ahhh! That's genius!  Bart T.12/13/03 08:31 PM
........Re: Ahhh! That's genius!  ElSemi12/14/03 05:18 AM
........*Re: Ahhh! That's genius!  Riff12/15/03 00:38 AM
.........*Re: Ahhh! That's genius!  Bart T.12/15/03 01:17 AM
..........*Re: Ahhh! That's genius!  Riff12/15/03 02:27 PM
...........*Re: Ahhh! That's genius!  Bart T.12/16/03 03:20 AM
...........*Re: Ahhh! That's genius!  finaldave12/15/03 03:48 PM
............*Re: Ahhh! That's genius!  Bart T.12/15/03 04:30 PM
.............*Re: Ahhh! That's genius!  Kayamon12/18/03 08:56 AM
..............*Re: Ahhh! That's genius!  finaldave12/18/03 09:36 AM
...............*Re: Ahhh! That's genius!  smf12/19/03 04:33 AM
.............*Re: Ahhh! That's genius!  finaldave12/16/03 05:16 AM
..............*Re: Ahhh! That's genius!  Bart T.12/16/03 01:04 PM
...............*Re: Ahhh! That's genius!  finaldave12/16/03 03:40 PM
................*Re: Ahhh! That's genius!  smf12/17/03 06:33 AM
.................*Re: Ahhh! That's genius!  finaldave12/17/03 06:39 AM
..................*Re: Ahhh! That's genius!  smf12/17/03 09:57 AM
...................*Re: Ahhh! That's genius!  finaldave12/17/03 12:39 PM
....................*Re: Ahhh! That's genius!  smf12/17/03 02:59 PM