This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
re: cgen bug with larger-than-normal instructions?
- To: Doug Evans <dje at transmeta dot com>
- subject: re: cgen bug with larger-than-normal instructions?
- From: matthew green <mrg at cygnus dot com>
- Date: Fri, 15 Sep 2000 13:19:04 +1100
- Cc: cgen at sources dot redhat dot com
- organisation: Red Hat, Inc.
matthew green writes:
> i am doing a sim port for an architecture that has 16 bit insns for
> all but the 16-bit & 32-bit immediately load insns, which are 32-bits
> & 48-bits long each, with the immediate value placed after the insn.
>
> currently, cgen produces code that fails to compile:
>
> decode.cxx:1457: implicit declaration of function `int GETIMEMUHI(...)'
>
> this function is currently missing from cgen-cpu.h, but even after i
> add it there, the problem persists. i believe the generate code is
> wrong, and (with an insight from bje) i have developed the following
> patch. it makes two changes to cgen itself:
>
> - call GETIMEM* as "current_cpu->GETIMEM*"
This is a sid-ism and as such doesn't belong in utils-cgen.scm.
yes, now you point that out i agree.
How do the other sid ports invoke GETIMEM?
i can't find anything else that actually uses this in generated code, only
in hand written code....
> - first argument of GETIMEM*() is "pc"
>
> this allows my decoder to build, but i haven't tested that it works
> yet (i have now pages of errors for sem.cxx to deal with).
I don't quite follow why adding "pc" is necessary.
well, the function is defined as:
inline UHI GETIMEMUHI(PCADDR pc, IADDR addr) const
so replacing `current_cpu' with `pc' seemed the right thing to do.
i don't know what the right way to do this is.