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]
Other format: [Raw text]

[RFA:] Fix lsb? bug with insn fields beyond base insn size.


This is a partial fix for what seems like a central problem:
bitfields are expressed as (start length) but whether "start" is
highest or lowest bit-number depends on "lsb0?".  It looks like
that's an ungood design choice and causes several bugs, two
fixed below, I hope.  (The "bitrange-overlap?" thingy looks
harmless though).  If anyone would ask, I'd say convert all
bit-field numbering to be as for the lsb0? #f case: a bitfield
specified as (dnf f-op "" () 0 3) always starts at 0 and is 3
bits long everywhere, regardless of lsb0?.

I've only tested these fixes on the CRIS target (wip) which has
a base-insn size of 16 bits, but can have a 16-bit (and 8-bit
within 16-bits) or a 32-bit constant as operand, similar to
m68k.  I though it'd work to express those fields in the same
way as in m68k.cpu, e.g.:

(d68f f-simm8  "signed 8 bit immediate"  () 16 16 7  8  INT #f #f)
(d68f f-simm16 "signed 16 bit immediate" () 16 16 15 16 INT #f #f)
(d68f f-simm32 "signed 32 bit immediate" () 16 32 31 32 INT #f #f)

However, I doubt that a m68k CGEN sim would work without the
patch below.

There's still a related bug somewhere: with an operand based on
f-simm8 (dnop sconst8 "" () h-sint f-simm8), the insn is
calculated as if sconst8 is an 8-bit constant field, so pc is
updated by one byte for the field, not two.  It should update by
two bytes since I say that f-simm8 is a 16-bit field, right?
Same thing again would happen for m68k methinks.

Another bug: I *have* to use the CISC model above for those
beyond-base-insn fields, since CGEN thinks the 32-bit field is a
16-bit field at insn word-offset 32 with the trivial (dnf
f-simm32 "" () 47 32).  Guesses: CGEN mixes it up with the insn
bitsize (16 as stated) or maybe it's another "lsb0?" bit-order
ungoodness.  Probably the "FIXME: word-offset/word-length
computation needs work" in ifield.scm:-ifield-parse needs fixing
too.  I'm too tired to see straight.

Ok to commit?

2002-06-19  Hans-Peter Nilsson  <hp@axis.com>

	* types.scm (bitrange-overlap?): Handle lsb0?.
	* utils-gen.scm (-gen-extract-word): Ditto.

Index: types.scm
===================================================================
RCS file: /cvs/src/src/cgen/types.scm,v
retrieving revision 1.1.1.1
diff -p -c -r1.1.1.1 types.scm
*** types.scm	28 Jul 2000 04:11:52 -0000	1.1.1.1
--- types.scm	19 Jun 2002 00:10:19 -0000
***************
*** 241,251 ****
  ; Return a boolean indicating if two bitranges overlap.
  
  (define (bitrange-overlap? start1 length1 start2 length2 lsb0?)
!   ; ??? lsb0?
!   (let ((end1 (+ start1 length1))
! 	(end2 (+ start2 length2)))
!     (not (or (<= end1 start2)
! 	     (>= start1 end2))))
  )
  
  ; Return a boolean indicating if BITPOS is beyond bitrange START,LEN.
--- 241,255 ----
  ; Return a boolean indicating if two bitranges overlap.
  
  (define (bitrange-overlap? start1 length1 start2 length2 lsb0?)
!   (if lsb0?
!       (let ((end1 (- start1 length1))
! 	    (end2 (- start2 length2)))
! 	(not (or (<= start1 end2)
! 		 (>= end1 start2))))
!       (let ((end1 (+ start1 length1))
! 	    (end2 (+ start2 length2)))
! 	(not (or (<= end1 start2)
! 		 (>= start1 end2)))))
  )
  
  ; Return a boolean indicating if BITPOS is beyond bitrange START,LEN.
Index: utils-gen.scm
===================================================================
RCS file: /cvs/src/src/cgen/utils-gen.scm,v
retrieving revision 1.6
diff -p -c -r1.6 utils-gen.scm
*** utils-gen.scm	14 Nov 2001 19:46:43 -0000	1.6
--- utils-gen.scm	19 Jun 2002 00:10:20 -0000
***************
*** 116,125 ****
  
  (define (-gen-extract-word word-name word-start word-length start length
  			   unsigned? lsb0?)
!   ; ??? lsb0?
!   (let ((word-end (+ word-start word-length))
! 	(end (+ start length))
! 	(base (if (< start word-start) word-start start)))
      (string-append "("
  		   "EXTRACT_"
  		   (if (current-arch-insn-lsb0?) "LSB0" "MSB0")
--- 116,131 ----
  
  (define (-gen-extract-word word-name word-start word-length start length
  			   unsigned? lsb0?)
!   ; Canonicalize on the low and high numbered ends of the field; use the
!   ; lsb?-adjusted numbering only when necessary.
!   (let* ((field-low (if lsb0? (- start length) start))
! 	 (field-high (if lsb0? start (+ start length)))
! 	 (word-low word-start)
! 	 (word-high (+ word-start word-length))
! 	 ; The field part within the extracted word.
! 	 (fieldpart-low (if (< field-low word-low) 0 (- field-low word-low)))
! 	 (fieldpart-high (if (> field-high word-high)
! 			     word-length (- field-high word-low))))
      (string-append "("
  		   "EXTRACT_"
  		   (if (current-arch-insn-lsb0?) "LSB0" "MSB0")
***************
*** 133,148 ****
  		   ", "
  		   (number->string word-length)
  		   ", "
! 		   (number->string (if (< start word-start)
! 				       0
! 				       (- start word-start)))
  		   ", "
! 		   (number->string (if (< end word-end)
! 				       (- end base)
! 				       (- word-end base)))
  		   ") << "
! 		   (number->string (if (> end word-end)
! 				       (- end word-end)
  				       0))
  		   ")"))
  )
--- 139,150 ----
  		   ", "
  		   (number->string word-length)
  		   ", "
! 		   (number->string (if lsb0? fieldpart-high fieldpart-low))
  		   ", "
! 		   (number->string (+ 1 (- fieldpart-high fieldpart-low)))
  		   ") << "
! 		   (number->string (if (> field-high word-high)
! 				       (- field-high word-high)
  				       0))
  		   ")"))
  )

brgds, H-P


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