public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
Cc: cgen@sources.redhat.com, sid@sources.redhat.com
Subject: Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems
Date: Fri, 03 Dec 2004 00:46:00 -0000	[thread overview]
Message-ID: <20041203004646.GL15612@redhat.com> (raw)
In-Reply-To: <200411291202.iATC2QGJ011968@ignucius.se.axis.com>

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-12-03  0:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-29 12:03 Hans-Peter Nilsson
2004-12-03  0:46 ` Frank Ch. Eigler [this message]
2004-12-03  2:08   ` Hans-Peter Nilsson
2004-12-03  4:42     ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041203004646.GL15612@redhat.com \
    --to=fche@redhat.com \
    --cc=cgen@sources.redhat.com \
    --cc=hans-peter.nilsson@axis.com \
    --cc=sid@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).