This is the mail archive of the cgen@sourceware.org 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]

Re: copyright issues for cgen-generated tools


> > 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))))
                )
)


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