From: Geoff Keating <geoffk@geoffk.org>
To: cgen@sources.redhat.com
Subject: field-start and varying word sizes
Date: Tue, 03 Jul 2001 13:39:00 -0000 [thread overview]
Message-ID: <200107032054.NAA01495@geoffk.org> (raw)
In field-start in ifield.scm, there is this code:
; Note that this is only intended for situations like the m32r.
; If it doesn't work elsewhere, it may be that you need to
; do things different (use two fields instead of one).
(cond ((= wanted-word-len recorded-word-len)
(bitrange-start bitrange))
((< wanted-word-len recorded-word-len)
; smaller word wanted
(if lsb0?
(- (bitrange-start bitrange) (- recorded-word-len
wanted-word-len))
(bitrange-start bitrange)))
(else
; larger word wanted
(if lsb0?
(+ (bitrange-start bitrange) (- wanted-word-len
recorded-word-len))
(bitrange-start bitrange))))))
I can see why someone might try to write this, but it can't work. It
needs to know, as well as lsb0?, the endianess of the CPU.
In my case, I have:
lsb0? #t
wanted-word-len 32
recorded-word-len 16
endian little
In this case, the right thing to do is to just return
(bitrange-start bitrange)
because on a little-endian system, you can extend words all you like
but the bit numbers don't change; it is only on a big-endian system
that and adjustment for word size is necessary. Of course, this is
why I chose lsb0? to be true, so I can number opcode fields without
worrying about the word size.
Despite the comment, m32r has
(insn-lsb0? #f)
and so all this code comes down to the trivial case anyway.
In fact, I can't find any port with lsb0?, big-endian, and
variable-length instructions, which is the only time that this code
does anything other than (bitrange-start bitrange).
The code has been in since cgen was written, so I believe the code
is one of those bits of never-tested never-used-before code that makes
working with cgen so much fun.
OK to commit?
--
- Geoffrey Keating <geoffk@geoffk.org>
===File ~/patches/cygnus/cgen-fieldstart.patch==============
2001-07-03 Geoffrey Keating <geoffk@redhat.com>
* ifield.scm (<ifield> 'field-start): Don't look at word-len.
Index: cgen/ifield.scm
===================================================================
RCS file: /cvs/cvsfiles/devo/cgen/ifield.scm,v
retrieving revision 1.51
diff -p -u -p -r1.51 ifield.scm
--- ifield.scm 2000/09/15 07:54:35 1.51
+++ ifield.scm 2001/07/03 20:33:07
@@ -91,42 +91,11 @@
(define (ifld-decode-mode f) (ifld-mode f))
; Return start of ifield.
-; WORD-LEN is the length of the word in which to compute the value or
-; #f meaning to use the default length (recorded with the bitrange).
-; WORD-LEN is present for architectures like the m32r where there are insns
-; smaller than the base insn size (LIW).
-; ??? Not sure it'll be applicable to other LIW architectures. The m32r is
-; rather easy as the insns are 16 and 32 bits.
-; ??? Another way to do this would be to either set the base-insn-size for
-; the m32r to be 16 bits, or to add a new field to hold the insn-word-size
-; and set it to 16 for the m32r. The problem here is that there is no
-; canonicalization that works regardless of whether a "word" is shortened
-; or lengthened.
(method-make-virtual!
<ifield> 'field-start
(lambda (self word-len)
- (let* ((bitrange (-ifld-bitrange self))
- (lsb0? (bitrange-lsb0? bitrange))
- (recorded-word-len (bitrange-word-length bitrange))
- (wanted-word-len (or word-len recorded-word-len)))
- ; Note that this is only intended for situations like the m32r.
- ; If it doesn't work elsewhere, it may be that you need to
- ; do things different (use two fields instead of one).
- (cond ((= wanted-word-len recorded-word-len)
- (bitrange-start bitrange))
- ((< wanted-word-len recorded-word-len)
- ; smaller word wanted
- (if lsb0?
- (- (bitrange-start bitrange) (- recorded-word-len
- wanted-word-len))
- (bitrange-start bitrange)))
- (else
- ; larger word wanted
- (if lsb0?
- (+ (bitrange-start bitrange) (- wanted-word-len
- recorded-word-len))
- (bitrange-start bitrange))))))
+ (bitrange-start (-ifld-bitrange self)))
)
(define (ifld-start ifld word-len)
============================================================
next reply other threads:[~2001-07-03 13:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-03 13:39 Geoff Keating [this message]
2001-07-03 14:42 ` Doug Evans
[not found] ` <15170.15391.989073.581389.cygnus.local.cgen@casey.transmeta.com>
2001-07-03 15:32 ` Geoff Keating
[not found] <200107032054.NAA01495.cygnus.local.cgen@geoffk.org>
2001-07-03 14:24 ` Frank Ch. Eigler
[not found] ` <o5wv5pzoy1.fsf.cygnus.local.cgen@toenail.toronto.redhat.com>
2001-07-03 15:12 ` Geoff Keating
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=200107032054.NAA01495@geoffk.org \
--to=geoffk@geoffk.org \
--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).