public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: fche@redhat.com
Cc: hans-peter.nilsson@axis.com, 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 02:08:00 -0000	[thread overview]
Message-ID: <200412030208.iB328DUr015412@ignucius.se.axis.com> (raw)
In-Reply-To: <20041203004646.GL15612@redhat.com> (fche@redhat.com)

> Date: Thu, 2 Dec 2004 19:46:46 -0500
> From: "Frank Ch. Eigler" <fche@redhat.com>

> 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.

BTW, we'll have to resolve the copyright issue for the CRISv32
sid port and assorted components to be merged.  For all I know
(and I should know) Axis is happy with the current license terms
(GPL but allowing binary distributions IIRC), but we do not want
to assign copyright for them to Red Hat.  (To FSF is ok).  Is
there a defined path for contributing to SID without copyright
assignment to Red Hat?  Can this be solved?  (I thought such a
path was in progress of being defined a year ago or so, or sid
copyright assigned to the FSF or suchlike.)

> 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.

Cool.  Want that!  Will put on my TODO list to investigate.
Hints welcome.

> > [...]
> > 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.

Thanks for looking into it.

> (And "debugging cgen" to me has
> simply meant the scheme equivalent of inserting printfs.)

Bummer.

>  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.)

I *have* had problems with ifields and its setters/getters, but
not recently IIRC.  The more recent problem was that they don't
like ISA attributes, or something to that effect.  (I had
problems with mostly-same define-hardware variants for different
MACH until I realized the totally orthogonal requirement for
that case of having different names but same semantic-name!
Nothing like fading memories of horrible debug sessions and wild
goose chases! :-)

Still, I see similar output happening for sim; (cgen-decode.c),
but of course there everything works, so I have reasons to
believe cris.cpu is at least *mostly* correct. ;-)

Anyway, I tried deleting everything except the first
register-register move insn (after "nop" ;-) (i.e. from line
1955 and below) and still get the same error with
cgen-decode.cxx.  Neither that insn nor nop use any strange
(multi-)ifields AFAICT.

brgds, H-P

  reply	other threads:[~2004-12-03  2:08 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
2004-12-03  2:08   ` Hans-Peter Nilsson [this message]
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=200412030208.iB328DUr015412@ignucius.se.axis.com \
    --to=hans-peter.nilsson@axis.com \
    --cc=cgen@sources.redhat.com \
    --cc=fche@redhat.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).