This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

signed ifields


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]