copyright issues for cgen-generated tools

copyright issues for cgen-generated tools

[Joern Rennecke]

We (ARC International) are currently evaluating the feasibility of using
cgen to generate simulators and binutils for the ARCompact family of cores.
The desired outcome is that the gdb sim simulator and binutils will be
integrated into the FSF mainline tree.
I understand that the FSF will requires copyright assignments for the
contributed code before such a contribution is considered for integration.
Obviously, we have the right to assign the code that we have written
ourselves. However, the cgen framework and cpu files that are recommended as
templates to writing your own cpu file (m32r is directly recommended,
and I've also found relevant bits for features not covered in m32r.cpu in
arc*.cpu, sh*.cpu sparc*.cpu and xstormy.cpu) are copyright Red Hat.
I'm not sure to what extend the generated files are then copyright Red Hat.
The Cgen license gives permission to use cgen output beyond the permissions
of  the GPL, but copyright assignment to the FSF certainly does go beyond
that.
Also, I'm not sure if the FSF requires the cgen source code to be
assigned to them.  It is the preferred source code to modify, but OTOH
the requirements of the GPL are fulfilled by the cgen source code being
available under a matching GPL license.

Have the necessary assignments already been made when previous cgen-generated
ports have been contributed to gdb / binutils?  There are copies of some old
cgen cpu files in the sourceware.org main tree which purport to be copyright
FSF, but at the same time the master copies in the cgen repository don't
carry any FSF copyright notices - I don't think any one is a clean-room
reimplementation, so one of the Copyright lists must be wrong (either the
FSF copyright notices in the main tree are plain wrong, or the copyright
notices in the cgen tree are incomplete at best).

Assuming the necessary copyright assignments have been made for previous
ports, will I need to use a vintage cgen version - presumably the one used
for the latest contributed port - in order to take advantage of these
assignments so that the ARC port can be contributed to the FSF?

Or can the necessary assignments for the newer code be made by Red Hat?

Re: copyright issues for cgen-generated tools

[Frank Ch. Eigler]

Hi, Joern -

Long time no see.

On Mon, Jan 15, 2007 at 11:37:49AM +0000, Joern Rennecke wrote:
> We (ARC International) are currently evaluating the feasibility of using
> cgen to generate simulators and binutils for the ARCompact family of cores.
> The desired outcome is that the gdb sim simulator and binutils will be
> integrated into the FSF mainline tree.

OK.

> [...] However, the cgen framework and cpu files that are recommended
> as templates to writing your own cpu file (m32r is directly
> recommended, and I've also found relevant bits for features not
> covered in m32r.cpu in arc*.cpu, sh*.cpu sparc*.cpu and xstormy.cpu)
> are copyright Red Hat.

Of course you're not obligated to use these templates.  Plus a bunch of
these cpu/opc files have been donated to the FSF copyright pile; see the
src/cpu directory for those.

> I'm not sure to what extend the generated files are then copyright
> Red Hat.  [...]

They aren't really; cgen is just too naive to properly mark up its
generated code.  IMO, if it can't propagate a copyright-holder tag
from the input files into the outputs, it should not emit copyright
notices at all.

> Also, I'm not sure if the FSF requires the cgen source code to be
> assigned to them.  [...]

Apparently not, but I wasn't privy to those early discussions when the
first cgen-based binutils/gdb ports appeared.

> There are copies of some old cgen cpu files in the sourceware.org
> main tree which purport to be copyright FSF, but at the same time
> the master copies in the cgen repository don't carry any FSF
> copyright notices [...]

That does not pose a problem.  The copyright holder for the old .cpu
files (Red Hat) has signed over many of those files, and happened to
keep around some of the older versions.  There is too little
development going on to be too worried about master copy-ness or
whatnot.

I believe the gist of the situation is this.  Write your model within
the cpu/ directory.  Use cgen to generate your
binutils/simulator/whatnot into opcodes/ etc.  If the copyright
messages cgen emits are not correct ((C) FSF presumably), then edit
them before submitting the inputs and outputs.  Don't worry about the
cgen program proper.  Or something like that.

- FChE

Re: copyright issues for cgen-generated tools

[Joern Rennecke]

> > There are copies of some old cgen cpu files in the sourceware.org
> > main tree which purport to be copyright FSF, but at the same time
> > the master copies in the cgen repository don't carry any FSF
> > copyright notices [...]
> 
> That does not pose a problem.  The copyright holder for the old .cpu
> files (Red Hat) has signed over many of those files, and happened to
> keep around some of the older versions.  There is too little
> development going on to be too worried about master copy-ness or
> whatnot.

That might be descriptive of m32r.cpu, but when you look at sh64-compact.cpu,
the difference between the cpu/ and the cgen/cpu/ versions is larger than
the cpu/ version.  Also, the cgen/cpu/ version has only Red Hat copyright
notices, for 2000 and 2006; the cpu/ version has only a 2000 copyright
notice.
The old/new code ratio is even worse for sh.cpu

There are also significantly more files in cgen/cpu than in cpu/ ;
the difference are new additions, leading strength to the impression
that cgen/cpu/ is the master copy.

The features I hoped to re-use from the sh port cpu are variable length
instruction parsing for a bi-endian cpu that is actually (insn-lsb0? #t),
and delay slot handling for the simulators.

Will I have to write a different workaround for these problems to avoid
copyright problems?

Also, worrying about m32r.cpu is that it has ChangeLog entries that
are newer than the Copyright notices.
Will I need to check out version 1.1 as the template for my development?
Or have copyright assignments to the FSF for the later patches actually been
made, thus that the Copyright notices are merely out of date?

Originally, I though the sparc64 port might also be useful as a template
for split-instruction pc-relative bit fields, but it does not seem
that the stuff there would work, I have to roll my own anyway.
I'm thinking of using something like the code below; does that make sense?

(dnf  f-d21l       "21 bit disp low part"  () 5 10)
(df   f-d21h       "21 bit disp high part" () 16 10 INT #f #f)
(dnmf f-rel21      "21 bit pc relative signed offset" (PCREL-ADDR) INT
      (f-d21l f-d21h)
      (sequence () ; insert
                (set (ifield f-d21l)
                     (and (srl (sub (ifield f-rel21) (and pc (const -4)))
                               (const 1))
                          (const #x3ff)))
                (set (ifield f-d21h)
                     (sra (sub (ifield f-rel21) (and pc (const -4)))
                          (const 11)))
                )
      (sequence () ; extract
                (set (ifield f-rel21)
                     (add (or (sll (ifield f-d21l) (const 1))
                              (sll (ifield f-d21h) (const 11)))
                          (and pc (const -4))))
                )
)

Re: copyright issues for cgen-generated tools

[Dave Brolley]

Joern Rennecke wrote:

>That might be descriptive of m32r.cpu, but when you look at sh64-compact.cpu,
>the difference between the cpu/ and the cgen/cpu/ versions is larger than
>the cpu/ version.  Also, the cgen/cpu/ version has only Red Hat copyright
>notices, for 2000 and 2006; the cpu/ version has only a 2000 copyright
>notice.
>The old/new code ratio is even worse for sh.cpu
>
>There are also significantly more files in cgen/cpu than in cpu/ ;
>the difference are new additions, leading strength to the impression
>that cgen/cpu/ is the master copy.
>  
>
We recently completed work to implement the entire sh architecture in 
SID starting with the existing sh64 implementation which already existed 
in cpu/ and cgen/cpu and which were nearly identical at the time. No one 
could tell me which one was the master and it appeared that some work 
was in cgen/cpu/ but not in cpu/, so I arbitrarily chose to work in 
cgen/cpu/.

It doesn't matter to us (Red Hat) where the copyright lies for this 
port, so feel free to bring cpu/ up to date and make it the master if 
you please.

Dave

Re: copyright issues for cgen-generated tools

[Frank Ch. Eigler]

Hi -

On Tue, Jan 16, 2007 at 01:28:56PM +0000, Joern Rennecke wrote:
> [...]
> The features I hoped to re-use from the sh port cpu are variable length
> instruction parsing for a bi-endian cpu that is actually (insn-lsb0? #t),
> and delay slot handling for the simulators. [...]

Go ahead.

> Also, worrying about m32r.cpu is that it has ChangeLog entries that
> are newer than the Copyright notices. [...]

I'm sure that's just sloppy copyright date updating.

> [...]
> I'm thinking of using something like the code below; does that make sense?
> [...]
> (dnmf f-rel21      "21 bit pc relative signed offset" (PCREL-ADDR) INT
>       (f-d21l f-d21h)
>       (sequence () ; insert
>                 (set (ifield f-d21l)
>                      (and (srl (sub (ifield f-rel21) (and pc (const -4)))
>                                (const 1))
>                           (const #x3ff)))
>                 (set (ifield f-d21h)
>                      (sra (sub (ifield f-rel21) (and pc (const -4)))
>                           (const 11)))
>                 )
> [...]

Yes, if the "current pc" were thusly available.  I believe however
that it is not, and that this will likely require hand-crafted
assembler operand parsers / relocations, and all that good stuff.

For an older Cygnus-authored target port, we built something called
"complex relocations", which can be used to automatically encode
complex link-time expressions into assembly operands.  IIRC this part
is being prepared for contribution to the FSF code base, but this is
bound to be a controversial addition.

- FChE