CPU simulator written in C

[/* frank */]

I have to do a homework: make a CPU simulator using C language.

I have a set of asm instructions so I have to write a program
that should:
- load .asm file
- view .asm file
- do a step by step simulation
- display registers contents

I tried to search con google with no success.

Any help (links, tricks/tips...)
would be really appreciated.

Thanks in advance.

[Gordon Burditt]

><OT>

Why not simply use the pc as an index in memory? This
would allow you to write memory[pc]. And doesn't this
This is a great idea for simpler CPUs without memory management
hardware, and especially for CPUs where the maximum addressable
memory of the emulated CPU (e.g. Z80 or 8086) is small (e.g. 64k
bytes or even 1MB) compared to the available RAM of the host CPU
running the emulation.
perfectly match what a PC does, being an index into a
block of data?
Yes, given the absence of memory management. Just Intel segment-register
mappings don't make it THAT hard, but protected-mode memory management
can make it much harder. With memory management, things get
complicated all of a sudden, especially if it's allowed for a
multi-byte integer fetch to straddle memory-management pages, and
where multiple very-different addresses can refer to the same block
of memory.
<\OT>

Gordon L. Burditt

[Case -]

Gordon Burditt wrote:

<OT>
Why not simply use the pc as an index in memory? This
would allow you to write memory[pc]. And doesn't this

This is a great idea for simpler CPUs without memory management
hardware, and especially for CPUs where the maximum addressable
memory of the emulated CPU (e.g. Z80 or 8086) is small (e.g. 64k
bytes or even 1MB) compared to the available RAM of the host CPU
running the emulation.

perfectly match what a PC does, being an index into a
block of data?

Yes, given the absence of memory management. Just Intel segment-register
mappings don't make it THAT hard, but protected-mode memory management
can make it much harder. With memory management, things get
complicated all of a sudden, especially if it's allowed for a
multi-byte integer fetch to straddle memory-management pages, and
where multiple very-different addresses can refer to the same block
of memory.

I didn't think of this in the context of OP's homework
assignment. Thanks for the extra info! CPU (and virtual
machine) design is and remains a very interesting subject.

Case

<\OT>

[John Cochran]

In article <40************ **@sun.com>,
Eric Sosman <Er*********@Su n.COM> wrote:
SNIP....`

I once worked on an actual machine whose program counter
registers (there were two) were signed -- the explanation
given was that the same circuitry implemented all the machine's
registers, so the signedness of the PCs was just a by-product
of parsimonious hardware design. However, only the low-order
bits of the active PC participated in address generation; the
sign bits and high-order bits were simply ignored.

So far, just an amusing peculiarity. But the really odd
thing was that the operation of "increment the program counter"
was implemented as the arithmetic operation "add one to the
program counter" -- so if the PC contained a negative value,
the effect was that the program ran backwards! I got some
diversion out of dreaming up a code sequence that executed
in the usual fashion for a while and then negated the PC and
"backed out" by re-executing the preceding instructions in
reverse order ...

Huh?

0x8000 = -32768
0x8000 + 1 = 0x8001 = -32767
0x8001 + 1 = 0x8002 = -32766
....

Show me where adding 1 to a negative binary number will cause the low
order bits to "run backwards" compared to adding 1 to an unsigned binary
number.

[osmium]

Dan Pop

OP:> >> I tried to search con google with no success.

Osmium:> >You are searching with the wrong target word. The proper word is
emulate,

not simulate.

POP:> You're splitting hairs. Try googling for "8051 simulator".

If you think you will shock me by revealing that people sometimes use the
wrong word, you have failed miserably.

When using something such as google, where the basic commodity is the right
word spelled properly, it is best to use the right word if you know it. If
you consider that hair splitting, feel free to continue to think so.

[Dingo]

jd*@smof.fiawol .org (John Cochran) wrote in message news:<cb******* ***@smof.fiawol .org>...

0x8000 = -32768
0x8000 + 1 = 0x8001 = -32767
0x8001 + 1 = 0x8002 = -32766
...

Show me where adding 1 to a negative binary number will cause the low
order bits to "run backwards" compared to adding 1 to an unsigned binary
number.

Repeat your demonstration using sign and magnitude representation in
place of two's complement.

[RoSsIaCrIiLoIA]

On Wed, 23 Jun 2004 19:10:38 GMT, RoSsIaCrIiLoIA <[e-mail]> wrote:

for me it is difficult write a portable and *fast* x86 cpu in C
(it has to execute an OS)
I'm a beginner but I would 'solve' the problem in this way:

______________ _______________ ______
#include <stdio.h>
#include <stdint.h> /* or stddef don't remember for uintxx_t */

struct r16{
uint8_t rl; /* uintXX_t would be in the standard c c89 */
uint8_t rh; /* so it is portable: it is ok in every cpu */
}; /* but in the x86 cpu a register is good for
signed
and unsigned calculation */
struct r32{
struct r16 ac;
uint16_t sn;
};
/* all global */
struct r32 eax_={0}, ebx_={0}, ecx_={0}, edx_={0};

/* they are static so until I don't write ={0} they are ={0} ie all 0
at the start of prog */

struct r32 esi_, edi_, ebp_, esp_, eip_;
uint16_t cs_, ds_, es_, ss_, fs_, gs_, flags_;

struct r32 *eax= &eax_, *ebx= &ebx_, *ecx= &ecx_, *edx= &edx_;
struct r32 *esi= &esi_, *edi= &edi_, *ebp= &ebp_, *esp= &esp_,
*eip = &eip_;
uint16_t *cs=&cs_, *ds=&ds_, *es=&es_, *ss=&ss_, *fs=&fs_,
*gs=&gs_, *falgs=&flags_;

But I prefer this:

#include <stdio.h>
#include <stdint.h> /* or stddef don't remember for uintxx_t */

struct r32{
uint32_t e;
uint16_t x;
uint8_t h;
uint8_t l;
};
/* all global */
struct r32 eax_={0}, ebx_={0}, ecx_={0}, edx_={0};
struct r32 esi_, edi_, ebp_, esp_, eip_;
uint16_t cs_, ds_, es_, ss_, fs_, gs_, flags_;

struct r32 *eax= &eax_, *ebx= &ebx_, *ecx= &ecx_, *edx= &edx_;
struct r32 *esi= &esi_, *edi= &edi_, *ebp= &ebp_, *esp= &esp_, *eip
= &eip_;
uint16_t *cs=&cs_, *ds=&ds_, *es=&es_, *ss=&ss_, *fs=&fs_,
*gs=&gs_, *falgs=&flags_;
#define ax eax->x
#define al eax->l
#define ah eax->h

#define bx ebx->x
#define bl ebx->l
#define bh ebx->h

#define cx ecx->x
#define cl ecx->l
#define ch ecx->h

#define dx edx->x
#define dl edx->l
#define dh edx->h

#define sp esp->x
#define bp ebp->x
#define si esi->x
#define di edi->x
#define ip eip->x
#define U unsigned
#define P printf

void assign(struct r32* a, uint32_t b)
{uint8_t l, h;
/*--------------*/
a->e = b;
a->x = (b>>16) & 0xFFFF;
a->h = (b>>8) & 0xFF;
a->l = b & 0xFF;
}
void Pr(struct r32* a)
{printf("%x", (int) a->e);
fflush(stdout);
}

void somma(struct r32* a,struct r32* b)
{assign(a, a->e + b->e);}

int main(void)
{
assign( eax , 0xFEFEFEFE); assign( ebx , 0xFAFAFAFA);
P("eax="); Pr(eax); P(" ebx="); Pr(ebx); P("\n");
assign(ecx, 50000); assign(edx, 512341);
somma(ecx, edx);
P("ecx="); Pr(ecx); P(" edx="); Pr(edx); P("\n");
printf("somma=% x", (int)(50000 + 512341) );
return 0;
}

[RoSsIaCrIiLoIA]

On Thu, 24 Jun 2004 07:28:14 GMT, RoSsIaCrIiLoIA <[e-mail]> wrote:

But I prefer this:

#include <stdio.h>
#include <stdint.h> /* or stddef don't remember for uintxx_t */

struct r32{
uint32_t e;
uint16_t x;
uint8_t h;
uint8_t l;
};
/* all global */
struct r32 eax_={0}, ebx_={0}, ecx_={0}, edx_={0};
struct r32 esi_, edi_, ebp_, esp_, eip_;
uint16_t cs_, ds_, es_, ss_, fs_, gs_, flags_;

better this:

#include <stdio.h>
#include <stdint.h> /* or stddef don't remember for uintxx_t */
/* all global */
uint32_t eax, ebx, ecx, edx;
uint32_t esi, edi, ebp, esp, eip;
uint16_t cs, ds, es, ss, fs, gs, flags;

union u{
uint32_t e;
uint16_t x;
uint8_t l;
};

#define ax (eax & 0xFFFF)
#define al (eax & 0xFF )
#define ah ( (eax >>8) & 0xFF )

#define bx (ebx & 0xFFFF)
#define bl (ebx & 0xFF )
#define bh ( (ebx >>8) & 0xFF )

#define cx (ecx & 0xFFFF)
#define cl (ecx & 0xFF )
#define ch ( (ecx >>8) & 0xFF )

#define dx (edx & 0xFFFF)
#define dl (edx & 0xFF )
#define dh ( (edx >>8) & 0xFF )

#define sp esp & 0xFFFF
#define bp ebp & 0xFFFF
#define si esi & 0xFFFF
#define di edi & 0xFFFF
#define ip eip & 0xFFFF
#define U unsigned
#define P printf

void inc_x(uint32_t* a)
{uint16_t r;
/*-------------*/
r = *a & 0xFFFF; ++r;
// P(" r=%x ", (int) r );
*a = *a & ((uint32_t) 0xFFFF0000 | r);
}

void inc_l(uint32_t* a)
{uint8_t r;
/*-------------*/
r = *a & 0xFF; ++r;
*a = *a & ((uint32_t)0xFF FFFF00 | r);
}

/* don't know if it is ok */
void inc_l1(uint32_t * a)
{++( (*(union u*)a).l );}

/* don't know if it is ok */
void inc_x1(uint32_t * a)
{++( (*(union u*)a).x );}

void inc_h(uint32_t* a)
{uint8_t r;
/*-------------*/
r = (*a>>8) & 0xFF; ++r;
*a = *a & ( 0xFFFF00FF | (uint32_t) r << 8 );
}

int main(void)
{
eax = 0xFEFEFEFE; ebx = 0xFAFAFAFA;
P("eax=0x%x ebx=Ox%x\n", (int) eax, (int) ebx);
ecx=50000; edx=512341;
ecx += edx;
printf("somma=0 x%x\n", (int)(50000 + 512341) );
eax=0xFFFFFFFF;
printf("eax=0x% x ", (int) eax );
inc_x(&eax); /* inc ax */
P("inc ax -> eax=0x%x ax=0x%x\n", (int) eax, (int) ax );

eax=0xFFFFFFFF;
printf("eax=0x% x ", (int) eax );
inc_x1(&eax); /* inc ax [& union] */
P("inc ax -> eax=0x%x ax=0x%x\n", (int) eax, (int) ax );

eax=0xFFFFFFFF;
printf("eax=0x% x ", (int) eax );
inc_l(&eax); /* inc al */
P("inc ax -> eax=0x%x al=0x%x\n", (int) eax, (int) al );

eax=0xFFFFFFFF;
printf("eax=0x% x ", (int) eax );
inc_h(&eax); /* inc ah */
P("inc ah -> eax=0x%x ah=0x%x\n", (int) eax, (int) ah );

return 0;
}

[Alex Fraser]

"Case -" <[e-mail]> wrote in message
news:40******** **************@ dreader2.news.t iscali.nl...

Dan Pop wrote:

An usigned integer type would be a much better choice for the program
counter. Ditto for the other integer registers.
I didn't say what kind of int, so technically what you propose
is covered by my statement ;-)

;-)
Yes, you're right, the PC is best typed as unsigned. I'm not sure
about the registers. Values in registers are seen as 2-s complement
by instruction in at least some CPU's (e.g., MIPS has pairs of
similar instructions for singed and unsigned register operand).

It's straightforward to simulate a 2's complement CPU using unsigned
integers, with the semantics C guarantees. This is for the same reason that
2's complement is popular.

Alex

[Dan Pop]

In <2j************ *@uni-berlin.de> "osmium" <r1********@com cast.net> writes:

Dan Pop

OP:> >> I tried to search con google with no success.

Osmium:> >You are searching with the wrong target word. The proper word is
emulate,

>not simulate.

POP:> You're splitting hairs. Try googling for "8051 simulator".

If you think you will shock me by revealing that people sometimes use the
wrong word, you have failed miserably.

Many of these people were vendors of such products. But, of course,
you know better than them...

If you were capable to conceive the notion that you might be wrong, the
google exercise would have been quite useful to you.

Contrary to your narrow ideas, there are many levels of software
CPU simulation, serving different purposes, and none of them is less
entitled to the name "simulation " than the others:

- sub-transistor level simulation: used for checking the correctness of
the chip design.

- transistor level simulation: used for checking the correctness of the
CPU implementation.

- gate level simulation: used for checking the correctness of the CPU
design.

- register to register transfer level simulation: used to evaluate the
CPU design performance.

- functional simulation, kernel mode: used for developing operating
system kernels and freestanding applications.

- functional simulation, user mode: used for developing hosted
applications (much faster than kernel mode simulation, as the OS kernel
functionality is provided by the simulator, instead of having the
simulated processor execute kernel code).

The last two simulation levels are *also* called emulation. In the case
of some very popular embedded control CPUs, hardware emulation is often
used for software development purposes instead of the real processor,
because it has much better debugging capabilities.

The Linux to Itanium port was done using "ski", a functional simulator
developed by HP and gcc as a cross-compiler on x86 hardware.
The kernel people used ski in kernel mode, the glibc people used it in
user mode. Everything was ready by the time Intel produced the first
silicon prototypes of Itanium. I don't remember anyone calling ski
"emulator", although it wouldn't have been technically incorrect.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Case]

Eric Sosman wrote:

Case - wrote:

Dan Pop wrote:

In <40************ ***********@new s.xs4all.nl> Case <[e-mail]> writes:
The key idea is to map all parts of a CPU on C structures
and routines. For example: the program counter (PC) can
be simply mapped to an int variable.


An usigned integer type would be a much better choice for the program
counter. Ditto for the other integer registers.

I didn't say what kind of int, so technically what you propose
is covered by my statement ;-)

Yes, you're right, the PC is best typed as unsigned. I'm not sure
about the registers. Values in registers are seen as 2-s complement
by instruction in at least some CPU's (e.g., MIPS has pairs of
similar instructions for singed and unsigned register operand).

Note that you must issue the occasional no-op when
using instructions of the first type, to give the singed
registers time to cool.

Is this some kind of joke?

Case