Developing a new simulator

Developing a new simulator

[Harshad R Joglekar]

Hi all,

I want to write a simulator for a processor. I want to
develop both a GDB embedded simulator and a stand alone version. I had a
glance at the available options, but was unable to decide on the best
approach. The options seem to be,

1. Develop the simulator from scratch
All features have to be implemented manually, with a little help from
sim/common/.

2. Use cgen
Cgen provides a lot of options (for the simulator), and documentation.
The approach is also very formal (it uses a RTL like language). But as
of now, not many ports seem to be using it. I am not sure if cgen would
support various kinds of instructions, registers, etc. I also don't know
of it's reliability (since it is in version 1.0).
A compromise could be to use cgen generated code as a template, and
tailor it as required. Is this feasible?

3. Use igen or sid
I could not find any documentation on igen and sid is not yet released.
Reliability is
still a concern as in cgen.

What option would you recommend?

Thanks for any help,
Harshad
From ac131313@cygnus.com Fri Sep 14 08:04:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Steven J. Hill" <sjhill@cotw.com>, binutils@sources.redhat.com, gdb@sourceware.cygnus.com, linux-mips@oss.sgi.com
Subject: Re: Continued MIPS kernel debugging symbols problem...
Date: Fri, 14 Sep 2001 08:04:00 -0000
Message-id: <3BA20E7F.3020506@cygnus.com>
References: <3BA16CAA.6B4DF4A1@cotw.com> <20010914002827.A2305@nevyn.them.org>
X-SW-Source: 2001-09/msg00123.html
Content-length: 169

> 
> If you'll post a binary that you're having trouble debugging, I'll try
> to find time in the next couple of days to see what GDB is doing wrong.

PUT UP FOR FTP!

Re: Developing a new simulator

[Frank Ch. Eigler]

Harshad R Joglekar <harshad.joglekar@wipro.com> writes on gdb@sourceware:

: [...]
: I want to write a simulator for a processor. [...]
: 
: 1. Develop the simulator from scratch
: All features have to be implemented manually, with a little help from
: sim/common/.

(IMHO, that'd be a waste.)


: 2. Use cgen
: Cgen provides a lot of options (for the simulator), and documentation.
: The approach is also very formal (it uses a RTL like language). But as
: of now, not many ports seem to be using it. I am not sure if cgen would
: support various kinds of instructions, registers, etc. I also don't know
: of it's reliability (since it is in version 1.0).
: [...]

CGEN is quite powerful, and is used almost universally for ports of
new embedded targets (some very complex) being developed by Red Hat.
Many of these ports have not yet been released, but the CGEN tool has
been.  (Don't worry about the version number.)


: 3. Use igen or sid
: I could not find any documentation on igen 

IGEN is an alternative to CGEN, if creating a CPU simulator is all you
want to do, and if you want to use the sim/common family.  Like other
tools with limited/no documentation, IGEN can be learned by studying
examples.


: and sid is not yet released.

Yes, it is: < http://sources.redhat.com/sid >.  It is an alternative to
sim/common, in that sid is more of a simulator framework rather than a
specific CPU simulator.  It includes CPU models whose kernels are
generated by CGEN, but can also host hand-made or other-tool-made CPU
simulation kernels.


: Reliability is still a concern as in cgen.

That's hard to compare & quantify.


So, your choice tree looks like:

* choose framework: sim/common or sid
* choose kernel: igen or cgen or hand-made

sim/common ==> igen or cgen or hand-made?
sid ==> cgen or hand-made?  (igen is not ported yet to generate
                             sid-compatible code)

- FChE