xstormy16: more misalignment fixes.

Yet more fixes for the xstormy16 word-alignment rules.

[cgen]
2003-05-01  DJ Delorie  <dj <at> redhat.com>

	* cpu/xstormy16.cpu (alignfix-mem): Correct logic for unaligned
	word accesses.
	(set-alignfix-mem): Likewise.

[sid/component/cgen-cpu/xstormy16]
2003-05-01  DJ Delorie  <dj <at> redhat.com>

	* xstormy16-sem.cxx: Regenerate.
	* xstormy16-write.cxx: Regenerate.

Index: cgen/cpu/xstormy16.cpu
===================================================================
RCS file: /cvs/uberbaum/./cgen/cpu/xstormy16.cpu,v
retrieving revision 1.8
diff -p -2 -r1.8 xstormy16.cpu
*** cgen/cpu/xstormy16.cpu	21 Mar 2003 06:15:55 -0000	1.8
--- cgen/cpu/xstormy16.cpu	1 May 2003 23:55:04 -0000
***************
*** 493,513 ****

  (define-pmacro (alignfix-mem where)
!   (if HI (and where 1)
!     (or HI
!       (and (sll (mem QI (sub where 1)) 8) #xFF00)

[rfa] FRV input files

Andrew Cagney writes:
 > Please note that I didn't write this (but I also work for Red Hat .
 > 
 > Andrew
 > 2003-05-02  Andrew Cagney  <cagney <at> redhat.com>
 > 
 > 	* frv.cpu: New file.  Written by Dave Brolley, Catherine Moore,
 > 	and Eric Christopher.  All of Red Hat.
 > 	* frv.opc: New file.  Written by Catherine Moore, and Dave
 > 	Brolley.  All of Red Hat.
 > 	* simplify.inc: New file.  Written by Doug Evans.  All of Red Hat.

I'm confused.

Given that src/cgen/frv.cpu already exists,
I'm guessing the intent here is to move these files to src/cpu
(given the recent activity there).

Why don't we move all the .cpu files over en masse?
Or is there something else going on here?

[rfa] FRV input files

Doug Evans writes:
 > Given that src/cgen/frv.cpu already exists,

Obvious typo: s,cgen,cgen/cpu,

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20030503.tar.bz2

Re: [rfa] FRV input files

[note: I added cgen <at> sources.redhat.com back to the cc list.]

Andrew Cagney writes:
 > Doug, see
 > http://sources.redhat.com/ml/binutils/2002-09/msg00689.html

Righto (and my thanks to the powers that be for letting it be src/cpu!),
but I don't see how this clears up my confusion.
Why did you submit a patch for frv.cpu,et.al. to binutils?
[I'm not suggesting you shouldn't have.  I'm just asking why.]
frv.cpu already exists in src/cgen/cpu (as do other files of course).
What needs to happen is for most/all of the files in src/cgen/cpu to move
to src/cpu. [No?]

There's also the issue of copyright.
One might take it as a given, but for my own education:
When the files in src/cgen/cpu/* get moved to src/cpu will
Redhat assign copyright over to the FSF?
I see that src/cgen/cpu/frv.cpu has copyright Redhat
and the patch you've submitted to binutils has copyright FSF.
I think it's not strictly necessary, but I'd still like to
know where people stand on the issue.  Is that Redhat's plan of record?
[i.e. assign copyright of *.cpu,*.opc,simplify.inc over to the FSF]
What about cgen itself?

There's also the issue of the kind of copyright attached to these files
(which I think needs to be unambiguous).
Cgen files use the cgen copyright (aka autoconf copyright).
Yet the copyright notice at the top of the frv.cpu file you've
submitted is pure GPL.  Which is it?

Re: [rfa] FRV input files

[cgen re-added to cc list, what is it with this?]

Notes:
- It appears the current plan is to move src/cgen/cpu piecemeal to src/cpu.
  Perhaps obvious, but why do it this way?
  Seems a whole lot easier to just have a flag day and do it
  en-masse.  Procedure-wise, just have Redhat change the copyright
  in src/cgen/cpu/*.cpu to what folks want first.  Then get Nick
  (or whomever needs to approve additions to src/cpu) to sign off on
  moving all the .cpu files over.  Then after that it's just
  mechanical source movement and makefile changes, which, it seems to me,
  would be preferable to do all at once rather than having a mix that
  slowly gets cleaned up.
- I'm going to assume that Redhat will assign copyright ownership over
  to the FSF.  [That's A Good Thing.]
  What the copyright terms are is a subsequent issue.

Andrew Cagney writes:
 > Red Hat has given me the authority to contribute these FRV files to the 
 > FSF.  Since src/cpu/ is part of binutils, I applied the standard 
 > binutils licence (which turned out to be the GPL).  If you feel that the 
 > FSF should in some way vary the licencing terms then can I encourage you 
 > to take that matter up with the FSF executive.

Why the FSF executive?  [ok fine if appropriate, but first things first]
[N.B. Clearly I'm not asking any change to the libopcodes, libbfd,
gas, ld, objdump/etc. copyrights.  One would hope that is taken as a given.]
However, Binutils releases already contain files that are a mixture
of copyrights.  GDB too.
There's no a-priori reason to have to make .cpu files GPL.

Re: [rfa] FRV input files

cagney wrote:

> Red Hat has given me the authority to contribute these FRV files to
> the FSF.

Did you receive instructions to change the license too?

> Since src/cpu/ is part of binutils, I applied the standard binutils
> licence (which turned out to be the GPL).

That's not necessarily appropriate.  The original licenses were fine,
and more useful for some purposes, like dje outlined.

> This is part of the very slow and very long term goal of cleaning up
> GDB's src/sim directory.

Please publish your plans, so one can tell what possible relationship
this has to that.

(And BTW, until cgen is taught to scan src/cpu in addition to
src/cgen/cpu for input models, this rearrangement will make dual
maintenance necessary on the unused new and the used old variants of
these files.)

- FChE

Re: [rfa] FRV input files

>> This is part of the very slow and very long term goal of cleaning up
>> GDB's src/sim directory.
> 
> 
> Please publish your plans, so one can tell what possible relationship
> this has to that.

Plan?  Get stuff contributed to the FSF.

Andrew

Re: [rfa] FRV input files

cagney wrote:

> >> This is part of the very slow and very long term goal of cleaning up
> >> GDB's src/sim directory.
>
> > Please publish your plans, so one can tell what possible relationship
> > this has to that.
> 
> Plan?  Get stuff contributed to the FSF.

Which part of sim/foo (for any cgen-generated foo) is not already
(C)FSF?  And what does this have to do with your improvised license
change?

- FChE

[patch][rfa] Add ltu,leu,gtu,geu support for unsigned modes

Hi,

The attached patch adds support for the unsigned modes (UQI, UHI, USI, 
UDI, UINT) for the cgen rtl ops ltu, leu, gtu and geu. These calls can 
be generated by code like

(if (ltu (zext UDI op1) (zext UDI op2 ))(set op3 op1 ))

ok to commit?

Dave

Index: sid/component/cgen-cpu/cgen-ops.h
===================================================================
RCS file: /cvs/src/src/sid/component/cgen-cpu/cgen-ops.h,v
retrieving revision 1.9
diff -c -p -r1.9 cgen-ops.h
*** sid/component/cgen-cpu/cgen-ops.h	1 Feb 2002 01:19:43 -0000	1.9
--- sid/component/cgen-cpu/cgen-ops.h	6 May 2003 19:27:42 -0000
*************** namespace cgen {
*** 55,60 ****
--- 55,64 ----
  #define LEUQI(x, y) ((UQI) (x) <= (UQI) (y))
  #define GTUQI(x, y) ((UQI) (x) > (UQI) (y))
  #define GEUQI(x, y) ((UQI) (x) >= (UQI) (y))
+ #define LTUUQI(x, y) ((UQI) (x) < (UQI) (y))
+ #define LEUUQI(x, y) ((UQI) (x) <= (UQI) (y))
+ #define GTUUQI(x, y) ((UQI) (x) > (UQI) (y))