A high-level core?

[blueshogun96]

Hey, a few days ago, I had this idea for an HLE interpreter. Ok, let's say that I'm emulating an x86 CPU. Would it be possible to do this?

switch( dwOpcode )
{
...
case 0x38354fae: // Let's say... mov eax, ebx
__asm mov eax, ebx
...
}

It's just an Idea that I havent gotten around to trying for myself, but has anyone ever done anything similar?

[Doomulation]

Yeah, but that would mean putting a case for thousands of different cases. You'd need to extract the opcode first and no the data... unless that isn't what you're doing, because that sure doesn't seem like an instruction.

[ShizZy]

Well, that really isn't HLE, that's an interpreter written with assembly (which is faster than a C interpreter, if done right). The purpose of HLE is to override cpu instructions with fast, exact, C code. You don't execute per opcode, instead you detect a function from the game's engine or sdk, and you replace the cpu instructions with an emulator function that does the equivelent. And thus you can override the need for real cpu and hardware emulation, at the expense of compatibility. Some stuff you might HLE are OS calls (OSEnableInterrupts, OSDisableInterupts, OSSelectThread), or graphics vector math, etc.

[_Zack_]

Well, that really isn't HLE, that's an interpreter written with assembly (which is faster than a C interpreter, if done right). The purpose of HLE is to override cpu instructions with fast, exact, C code. You don't execute per opcode, instead you detect a function from the game's engine or sdk, and you replace the cpu instructions with an emulator function that does the equivelent. And thus you can override the need for real cpu and hardware emulation, at the expense of compatibility. Some stuff you might HLE are OS calls (OSEnableInterrupts, OSDisableInterupts, OSSelectThread), or graphics vector math, etc.

ShizZy your making my head spin!

You gus certainly know your stuff on HLE!

[smcd]

doing operations such as changing the actual eax, ebx of the machine currently running the interpretation will mess up the state/execution of the emulator...

[civilian0746]

Should not be writing cores in c or other high level languages because u have do lots of preprocessing in identifying the insts and ophs. In addition, the way suggested on the first post is like...having a case statement for all the combinations of instructions and values.

[Doomulation]

Oh? So you suggest doing a core in assembly, then?
It doesn't matter which language you use, you still need to identify the opcode. Unless it IS the system being emulated, of course.

[Exophase]

I think part of what he's suggesting is having a switch case for every possible instruction to avoid decoding the operands or other opcode fields. For platforms with fixed width 16bit instructions this is possible (like SH, Thumb, etc). For platforms with 32bit instructions this isn't feasible, there are too many possible cases. For platforms with variable length instructions (x86 falls under this, as per your example) it's not possible, you have to fetch in multiple steps, although if you fetch to the largest size and pad the remainder with something producing otherwise invalid opcodes (they'd probably have to be) and switch on that it might work. This is only possibly feasible with instructions that vary between 1 and 2 or 3 bytes like 6502. It's really a trade-off between speed and space, but very large switch sets will thrash cache (and possibly RAM at that) pretty quickly.

[blueshogun96]

Ok, so I'm gonna scratch that idea.

Anyway, forgive me if I see this incorrectly, but you all are saying that it's not a good idea to do an interpreter on an x86 CPU? This is my first time emulating a RISC cpu btw. So used to the CISC stuff. Also, to do it the normal way, should I set up my union this way? I'll be honest, out of all the years I've been programming (started with basic in 1989) the one thing I never learned how to use in C were unions, but I know everything else lol.

typedef union
{
  DWORD w;
  WORD w;

  struct
  {
    unsigned char h,l;
  }b;
}iPIIIReg;

[ShizZy]

The union looks fine, but keep in mind a Word is 32bits (well, on most systems), and 2 bytes is only 16. So for that to work, you'd have to map 4 bytes in that switch, or two 2byte switches in a switch within the union. As for a risc interpreter on x86 - why not? What else would you write it on, a MAC?

Here's a crash course in RISC arcitecture emulation- (using PPC as an example)
Unlike CISC, where opcodes are of variable size, and can be identified simply by a one or 2 byte field, RISC is as you know fixed length opcodes, usually 32bit. Take a pseudo PPC opcode:

--------------32 Bits----------------------------------------------
[Bits 0-5][Bits 6-10][Bits 11-15][Bits 16-20][Bits 21-30][Bit 31]

As you know, it's divided up into sections (PPC is big endian btw). In this example, the first 6 bits, 0-5, are the opcode identifier, which has a possible range from zero to 64. Each identifier specifies an instruction, or, in some cases, a branch to other instructions. So, a simple way to do this, would be to do:

switch((opcode >> 26)&0x3F)
{
case 0: Opcode_NOP(); break;
case 1: Opcode_OR(); break;
...
case 31: Opcode_31(); break;

In this case, the value of 31 has multiple opcodes, so you'd call a function with another switch, and this time, check the opcode extension. On PPC, this extension is bits 21-30. It's probably different on the cpu your emulating. So, just do switch((opcode >> 1)&0x3FF).

Tada... instruction decoding on RISC, no strings attached. It's really very easy to do an interpreter like this. Now, take the other sections. Bits 6-10, 11-15, and 16-20 are register fields in this example. Thus, each field represents a value of the GPR to manipulate by the instruction. In this example, the first would be REGD, the second REGA, and the third REGC. Each is 5 bits, thus can have a value from 0-31, which points to one of the PPC's 32 general purpose registers, respectivly. Here's a pseudo op:

In your cpu manual, it might say something like this:

Opcode: MUL
regDest = regSrcA * regSrcB

Now, in C++:

void Opcode_MUL(u32 opcode)
{
    reg.gpr[(opcode>>21)&0x1F] = reg.gpr[(opcode>>16)&0x1F]  * reg.gpr[(opcode>>11)&0x1F] ;
}

A good tip is to use macros for all that shifting, ie #define REG_D ([(opcode>>21)&0x1F) - so you are less prone to making mistakes. As for Bit31, it could be on anything, on PPC though it's a flag called Rc to calculate a field of the CR register.

There you have it. As for most of the other parts, it acts pretty much in the same nature as a CISC processor, to an extent. Hope that helps a little