This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: tabling constant-field-beyond-base patch
- From: "Adrian Ashley" <adrian dot ashley at broadcom dot com>
- To: cgen at sources dot redhat dot com
- Cc: "Doug Evans" <dje at sebabeach dot org>
- Date: Thu, 13 May 2004 20:23:17 +0100
- Subject: Re: tabling constant-field-beyond-base patch
- References: <20030806175257.64167B53E@mail.sebabeach.org>
Way back in Aug-2003, Doug Evans wrote:
Finishing up the remaining bits of this patch are proving difficult.
[N.B. The issues aren't of a technical nature.] So I'm tabling the
current state of the patch here.
I hope to have the difficulties resolved RSN. Sigh.
I'm working on a port to a (little-endian) machine which has some 64-bit
instructions which are extended versions of 32-bit ones - i.e. ambiguous
in the lower 32-bits but distinguishable by looking at some of the upper
32-bits. CGEN currently goes bong in -build-decode-table-entry when it
detects the ambiguity.
In my search through the archives it looks like this work might be a
good starting point. Other postings referred to the possibility of
making CGEN_INSN_INT a long long and removing all the assumptions that
it is actually 32 bits - though replacing them with only slightly less
rigid assumptions that it's "32 or 64".
Has this problem been solved already? If not, can the sages offer
advice as to the most fruitful way to proceed? I'm currently trying the
"CGEN_INSN_INT is long long" approach, in the absence of fully
understanding the bigger picture.
Thanks,
A Ashley