From: Doug Evans <dje@sebabeach.org>
To: adrian.ashley@broadcom.com
Cc: cgen@sources.redhat.com
Subject: Re: tabling constant-field-beyond-base patch
Date: Mon, 17 May 2004 16:43:00 -0000 [thread overview]
Message-ID: <20040517164338.16F1BB525@sebabeach.org> (raw)
In-Reply-To: <40A3CB25.9090305@broadcom.com> (adrian.ashley@broadcom.com)
Date: Thu, 13 May 2004 20:23:17 +0100
From: "Adrian Ashley" <adrian.ashley@broadcom.com>
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.
Update: The issues still aren't resolved and the ball isn't in my court
to resolve them. 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.
IMO, without actually sitting down and studying the ISA in question,
extending CGEN_INSN_INT isn't the way to go. CGEN_INSN_INT is a
special case of the general solution, created to simplify handling of
several popular architectures (32-bit riscs).
Trying to generalize it has and will lead to issues, further complicating
things.
Have you looked at not using CGEN_INSN_INT and treating instructions as
just a set of bytes (i.e. "cisc-like") ?
prev parent reply other threads:[~2004-05-17 16:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-06 18:13 Doug Evans
2004-05-13 19:24 ` Adrian Ashley
2004-05-17 16:43 ` Doug Evans [this message]
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=20040517164338.16F1BB525@sebabeach.org \
--to=dje@sebabeach.org \
--cc=adrian.ashley@broadcom.com \
--cc=cgen@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).