Hi, HP -

On Mon, Nov 29, 2004 at 01:02:26PM +0100, Hans-Peter Nilsson wrote:
> [...]
> With SID, a complete system boots and runs Linux on CRISv32.  

Wow.

> Considering that both SID and sim work as dejagnu baseboards (at
> least by brief inspection of dejagnu), why have both?  Well, sim
> is the snap-in-simulator of choice for GCC testing (my main
> purpose for it) and asking people to build SID instead is a
> obstacle.  

Plus sid is not as well known, and some people have expressed
reservations about Red Hat retaining its copyright over the
core of the software.

> Also, at the time I wrote it (perhaps still the case), I couldn't
> find a way to model cycle-correctness for the SID simulator.

We have a really wild sid port (MeP) that does model the pipeline
in much the same way that the sim/common/cgen* stuff does (and goes
way beyond in some other ways), and I believe this does not rely on
any sid/cgen infrastructure not already public.
 
> [...]
> Processing extractor fn bodies ...
> Processing extractor for "#f" ...
> Processing extractor for "(#f 16  (f-operand2 #) (f-operand1 #)  (-nosan- Rs SI) (-nosan- f-operand2 UINT) (-nosan- h-raw-gr-SI-index-of--DFLT-Rd SI) (-nosan- xbit BI) (-nosan- zbit BI cond)  (-nosan- cbit-move BI) (-nosan- h-gr-SI-index-of--DFLT-Rd SI) (-nosan- nbit BI) (-nosan- prefix-set BI) (-nosan- vbit-move BI) (-nosan- xbit BI) (-nosan- zbit BI) )" ...
> [...]

This doesn't ring a big bell, so I'd have to sit down and debug cgen
for real to see what's happening.  (And "debugging cgen" to me has
simply meant the scheme equivalent of inserting printfs.)  One oddity
to keep in mind though: ifield extractors are very limited in terms
of what sorts of RTL constructs they can safely contain, but this
limitation is not enforced properly.  (It comes from a poor definition
of execution context for these bad boys, in that they have to expand
somehow both within bfd and within sim/sid.)


- FChE