* signed ifields
[not found] <15045.22228.305989.505250@scooby.apac.redhat.com>
@ 2001-04-02 0:09 ` Ben Elliston
0 siblings, 0 replies; only message in thread
From: Ben Elliston @ 2001-04-02 0:09 UTC (permalink / raw)
To: cgen
I'm struggling to understand some aspects of CGEN's design with
respect to {signed,unsigned} quantities for instruction fields. I'm
unsure about why it makes sense to attribute "signedness" to what is
effectively a sequence of bits. Shouldn't the signedness be
attributed to operands (which it already can be)? It seems redundant
that both objects can be attributed as such.
I bring this up because some internal users of CGEN have been caught
by unintuitive behavior when using (dnf ..) to define their ifields
and then flagging their operands as signed, only to find that the
extraction code treats the underlying ifield as unsigned.
Comments?
Ben
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2001-04-02 0:09 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <15045.22228.305989.505250@scooby.apac.redhat.com>
2001-04-02 0:09 ` signed ifields Ben Elliston
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).