Emulating a processor

[Everett M. Greene]

I wouldn't have chosen the 386 as the best place to start. I would've
chosen something like an 8-bit micro such as Z80 or 6502.

You also don't say what your background is, and what sort of
emulation/simulation you're looking at. ie. software? hardware (FPGA?).
I'm guessing software from your comments about bochs.

Another place to look would be MAME/MESS. They emulate a whole host of
processors. The architecture of the project is quite mature, and the
processors should be quite nicely done, but the implementation could be
clouded somewhat by the abstraction layers built around the memory and
interrupt interfaces. None-the-less, a rich source of reference material.

What's a MAME/MESS?

 

[Alexei A. Frounze]

Another use is testing code from a cross-compiler for a
processor that doesn't exist yet. With this application,
you also get to deal with the vagaries of the documentation.
It teaches you that some people have unusual ideas as to
what constitutes a good processor design ["you don't need
no steenkin' signed arithmetic"].

I beg your pardon, what's so bad about signed arithmetics?

Not a thing. Just try doing signed comparisons without
any signed operations.

No problem. Consider the most common case of 2's complemented representation
of signed integers and a pair of integers of the same bit size. You subtract
them the same way as you'd do with unsigned ones. If the result is 0,
they're equal. Otherwise, they're not and you need to determine which one is
smaller/bigger than the other. To find out which one is bigger/smaller, you
only need the sign of the result (the most significant bit). But since the
overflow can occur (e.g. when subtracting 16-bit integer 1 from 16-bit
integer -32768 you want to get -32769 but that can't fit into just 16 bits
anymore and you get 32767 and overflow), you must take that into account.
So, you take the most significant bit of the result and treat it as the
sign, which is subject to further correction. You can then simply XOR that
MSBit with the overflow flag of the CPU (I haven't seen a CPU w/o that flag
yet, so I consider that to be available) and the outcome of the XOR
operation is the true sign of the result, whether there was overflow or not.

This is my 16-bit comparison routine for i8051 8-bit micro controller:

; R3(MSB) R2(LSB) is comared to R5(MSB) R4(LSB)
CMP16:
CLR C ; clear carry/borrow flag before 1st subtraction
with borrow (there's no subtraction w/o borrow on this CPU)

MOV A, R4
SUBB A, R2
MOV B, A

MOV A, R5
SUBB A, R3

JNB ACC.7, CMP16_1 ; jump if MSBit of accumulator is 0, if the
jump is taken the overflow (OV) flag is equal to true sign of the result of
subtraction; otherwise OV is the inverse of the true sign
CPL OV ; invert OV
CMP16_1: ; got subtraction result's sign in OV!

ORL A, B ; now, find out if the subtraction gives us 0 (i.e.
equal numbers), this doesn't affect carry/borrow and OV

RET

Now, this routine can be used to compare both signed and unsigned numbers.
To differentiate between the two you use different conditional jumps after
calling this routine:

For unsigned numbers:
R5R4 = R3R2, if A = 0 (JZ)
R5R4 <> R3R2, if A <> 0 (JNZ)
R5R4 < R3R2, if CY = 1 (JC)
R5R4 > R3R2, if CY = 0 and A <> 0
R5R4 >= R3R2, if CY = 0 (JNC)

For signed numbers:
R5R4 = R3R2, if A = 0 (JZ)
R5R4 <> R3R2, if A <> 0 (JNZ)
R5R4 < R3R2, if OV = 1 (JO)
R5R4 > R3R2, if OV = 0 and A <> 0
R5R4 >= R3R2, if OV = 0 (JNO)

There's no special zero flag on this CPU and JZ/JNZ compares the whole
accumulator to 0 to make a decision on whether or not the jump is taken.

While I agree there's a bit more work involved in comparing signed numbers,
it's not that big. In this case, just 2 extra instructions (JNB ACC.7,...
and CPL OV). It will be different on a different CPU (if you can't test
MSBit of a register directly or flag inversion is absent for OV) but it's
doable. And if your signed numbers are small (and their subtraction can't
give you the overflow), just to compare them you could add a positive bias
to the two before doing subtraction to get away with effectively unsigned
comparison. Or you could sign extend the numbers before subtraction to get
rid of the overflow altogether. Depends on your CPU and maybe application.
The next more complicated signed operation to implement would probably be
division, especially if you want to get the remainder and both overflows (it
can be that there's no overflow in the quotient, but there's in remainder!).
2's complemented multiplication is actually implemented easily with unsigned
multiplication and even w/o finding the absolute values of the
multiplicands.
And you don't probably need signed numbers everywhere...

Alex

 

[Chris Hills]

Hi all,

I'm interested to understand the processor architecture in depth. So i
decided on emulating the processor itself (as my project). The best one
to start would be 386.

Why a 386?

You mean simulation. emulation id a hardware system (see Lauterbach,
Ashling, Nohau, Hitex, isystem, Signum etc etc

So i wud require some documents which explains on how to emulate any
processor or devices. ( Apart from the Intel Architecture documents
available).

If you have to ask here don't start..... You are out of your depth.

How to emulate a 386 processor. I want to kno how usually this is done.
I wonder how bochs has been developed so elegantly...the resource
they've used.

It wud be appreciable if someone can guide me on any documents or
reference books avaliable on Emulating processors and devices.

.
Wht are the resources I should have in hand to start up up this
project.

Degree in electronics specialising in MCU's
several years experience.
Knowledge of some (if not most) of the tools out there now.

 

[luiguo]

Why a 386?

May be We fomilar with x86 architecture.

You mean simulation. emulation id a hardware system (see Lauterbach,
Ashling, Nohau, Hitex, isystem, Signum etc etc




If you have to ask here don't start..... You are out of your depth.




Degree in electronics specialising in MCU's
several years experience.
Knowledge of some (if not most) of the tools out there now.

I suguest to find the "PCE"--IBM PC hardware emulator. It's simple
enough to learn. It emulates most hardware of an IBM PC. and enable boot
a DOS system

 

[David Schwartz]

I have one basic doubt on how MEM WR/RD# cycles are emulated.. (i.e
memory read & write cycles emulated in software).. i mean how are the
rd/wr (ASSERT/DE-ASSERT) signals sychronised for a memory access in
software...( eg: var = *(someMEM))..

The same way you emulate the CPU's power consumption of the physical
space it occupies. Software can't tell about these things, so there's no
need to emulate it. When we talk about emulating a CPU, we're always talking
about emulating only specific aspects of the CPU. We don't emulate its mass
or each electron that moves through it.

DS

 

[Del Cecchi]

The same way you emulate the CPU's power consumption of the physical
space it occupies. Software can't tell about these things, so there's
no need to emulate it. When we talk about emulating a CPU, we're always
talking about emulating only specific aspects of the CPU. We don't
emulate its mass or each electron that moves through it.

DS

Maybe the OP needs to clarify their understanding of the difference
between emulation and simulation.

 

[David Schwartz]

Maybe the OP needs to clarify their understanding of the difference
between emulation and simulation.

Probably, but even in a simulation, there are things you simulate and
things you don't. Otherwise, a simulation would have to be identical to the
thing simulated, at which point it would cease to be a simulation.

DS

 

[Del Cecchi]

Probably, but even in a simulation, there are things you simulate and
things you don't. Otherwise, a simulation would have to be identical to the
thing simulated, at which point it would cease to be a simulation.

DS

Right. But at some point in a processor simulation the memory interface
functionality and timing will have to be verified.

 

[Bill Davidsen]

basically you have two choices:

full emulation: you read a byte from (emulated) ram and
interpret/execute it (use a huge switch-statement). then advance to the
next byte and interpret/execute it, ...

Not if you want to finish the run in your lifetime... For a simple byte
code, like 8080, you use an array of pointers to functions, so you can
just branch without doing any compares. For a machine with prefix codes,
like x86, when you decode the prefix you add another level of
indirection, and jump through a pointer to array of pointer to function.
That pointer sort of converts the emulation to a state machine.

Note that if you just want to run the program and get the right results,
this is relatively simple, although you need emulated hardware to go
with the i/o instructions, or with more effort and per-byte flags memory
mapped i/o.

If you want to handle timing, cache, etc, it's a BIG project!

 

[oldfogie]

Hi all,

I'm interested to understand the processor architecture in depth. So i
decided on emulating the processor itself (as my project). The best one
to start would be 386.

So i wud require some documents which explains on how to emulate any
processor or devices. ( Apart from the Intel Architecture documents
available).
How to emulate a 386 processor. I want to kno how usually this is done.
I wonder how bochs has been developed so elegantly...the resource
they've used.

It wud be appreciable if someone can guide me on any documents or
reference books avaliable on Emulating processors and devices.

.
Wht are the resources I should have in hand to start up up this
project.

It was a long time ago, but I wrote an 80186 emulator in C (with some
assembly) that ran on an IBM-PC (or clone). It was good enough
to access screen, hard drive, keyboard, floppy, etc., and do so in
such a way that the emulated processor crashing (destroying
interrupt vectors, etc) did not affect the "real" processor it was running
on (virtual memory for the emulated processor).

It was also capable of emulating itself emulating running itself.

If you want to check it out, go to www.datapackrat.com/source/source.html

Bill