From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geoff Keating To: cgen@sources.redhat.com Subject: field-start and varying word sizes Date: Tue, 03 Jul 2001 13:39:00 -0000 Message-id: <200107032054.NAA01495@geoffk.org> X-SW-Source: 2001-q3/msg00001.html 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 ===File ~/patches/cygnus/cgen-fieldstart.patch============== 2001-07-03 Geoffrey Keating * ifield.scm ( '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! '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) ============================================================