[RFA:] Fix for lsb0? in -gen-extract-word, take 2.

[RFA:] Fix for lsb0? in -gen-extract-word, take 2.

[Hans-Peter Nilsson]

Here's a less intrusive fix since I couldn't wrap my head around
what adjustment there should be for the "<<" expression.  I
can't figure out whether it actually has lsb0?-issues at all, so
I'll not touch it.  Again, only tested on the CRIS (wip) target.

Ok to commit?

	* utils-gen.scm (-gen-extract-word): Handle lsb0?.

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	25 Jun 2002 01:20:12 -0000
***************
*** 114,146 ****
  ; Subroutine of -gen-ifld-extract-beyond to extract the relevant value
  ; from WORD-NAME and move it into place.

! (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")
  		   (if (and (not unsigned?)
  			    ; Only want sign extension for word with sign bit.
! 			    (bitrange-overlap? start 1 word-start word-length
  					       lsb0?))
  		       "_INT ("
  		       "_UINT (")
  		   word-name
  		   ", "
  		   (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))
--- 114,158 ----
  ; Subroutine of -gen-ifld-extract-beyond to extract the relevant value
  ; from WORD-NAME and move it into place.

! (define (-gen-extract-word word-name word-start word-length
! 			   field-start field-length
  			   unsigned? lsb0?)
!   (let* ((word-end (+ word-start word-length))
! 	 (start (if lsb0? (+ 1 (- field-start field-length)) field-start))
! 	 (end (+ start field-length))
! 	 (base (if (< start word-start) word-start start)))
      (string-append "("
  		   "EXTRACT_"
  		   (if (current-arch-insn-lsb0?) "LSB0" "MSB0")
  		   (if (and (not unsigned?)
  			    ; Only want sign extension for word with sign bit.
! 			    (bitrange-overlap? field-start 1
! 					       word-start word-length
  					       lsb0?))
  		       "_INT ("
  		       "_UINT (")
+ 		   ; What to extract from.
  		   word-name
  		   ", "
+ 		   ; Size of this chunk.
  		   (number->string word-length)
  		   ", "
! 		   ; MSB of this piece.
! 		   (number->string
! 		    (if lsb0?
! 			(if (> end word-end)
! 			    (- word-end 1)
! 			    (- end word-start 1))
! 			(if (< start word-start)
! 			    0
! 			    (- start word-start))))
  		   ", "
+ 		   ; Length of field within this chunk.
  		   (number->string (if (< end word-end)
  				       (- end base)
  				       (- word-end base)))
  		   ") << "
+ 		   ; Adjustment for this piece within a full field.
  		   (number->string (if (> end word-end)
  				       (- end word-end)
  				       0))

brgds, H-P

Re: [RFA:] Fix for lsb0? in -gen-extract-word, take 2.

[Frank Ch. Eigler]

Hi -

On Mon, Jun 24, 2002 at 09:50:00PM -0400, Hans-Peter Nilsson wrote:
> Here's a less intrusive fix since I couldn't wrap my head around
> what adjustment there should be for the "<<" expression.  I
> can't figure out whether it actually has lsb0?-issues at all, so
> I'll not touch it.  Again, only tested on the CRIS (wip) target.
> [...]

Let me voice one note of caution regarding this area.  cgen is
not fully developed with respect to variable-length instruction
sets, and some other odd cgen-isa parametrizations.  This has
been making it necessary to use lsb0=#f for several cpu ports.
I'm worried that modification of something as low-level as
gen-extract-* can easily break these unusual ports. 
Unfortunately, only "medium-weird" ports are on the sourceware
cgen repository, so it's possible that a change will break only
a port you don't (yet) have access to.

Anyway, please keep in mind that you're treading on fragile
territory.


- FChE

Re: [RFA:] Fix for lsb0? in -gen-extract-word, take 2.

[Doug Evans]

Frank Ch. Eigler writes:
 > Unfortunately, only "medium-weird" ports are on the sourceware
 > cgen repository, so it's possible that a change will break only
 > a port you don't (yet) have access to.

cgen shouldn't be held ransom be Redhat.
By that I mean if Redhat has proprietary ports it hasn't released yet
that's its problem, not the net's.

If a change doesn't break any existing net port (and diff'ing
the generated files before/after goes a long way to doing that (*)),
and the change is desirable, then the change should go in.
Let Redhat have "REDHAT LOCAL" mods if it needs.

Yes I know Redhat still has the copyright, but does it want to
play nice with the net and encourage progress and net contributions
or restrict it by saying "no you can't do that because it will break
one of our internal ports".

If the change is TRTTD, Redhat should welcome it and adapt.
If it can't right away, deal with it.  It's not like the folks
at Redhat don't have any experience dealing with local mods. :-)

(*) A script to do this would be a very useful addition.
[insert various caveats]   Someone want to write it?

Re: [RFA:] Fix for lsb0? in -gen-extract-word, take 2.

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Hi -

dje wrote:
> Frank Ch. Eigler writes:
>  > Unfortunately, only "medium-weird" ports are on the sourceware
>  > cgen repository, so it's possible that a change will break only
>  > a port you don't (yet) have access to.
> 
> cgen shouldn't be held ransom be Redhat.
> By that I mean if Redhat has proprietary ports it hasn't released yet
> that's its problem, not the net's.  [...]

Dude, you are reading way more into my message than you should.

My point was simply that the existing ports do not make a
very good test suite for changes in this area, since they
tend not to exercise this part of cgen particularly hard.
A change may look sensible for simple ports, but be actually
be incorrect, when considering cgen's behavior in complex
cases.  This is not to hold anyone back, just to make them
aware that "doing the right thing" is not that well-defined
in cgen land.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]