Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems

> Date: Thu, 2 Dec 2004 19:46:46 -0500
> From: "Frank Ch. Eigler" <[email protected]>

> 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