From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1933 invoked by alias); 16 Jan 2007 13:31:18 -0000 Received: (qmail 1925 invoked by uid 22791); 16 Jan 2007 13:31:17 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO elsdt-razorfish.arc.com) (194.202.198.226) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Jan 2007 13:29:10 +0000 Received: from elsdt-razorfish.arc.com (localhost.localdomain [127.0.0.1]) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11) with ESMTP id l0GDT1uk001507; Tue, 16 Jan 2007 13:29:01 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l0GDSucd001505; Tue, 16 Jan 2007 13:28:56 GMT Date: Tue, 16 Jan 2007 13:31:00 -0000 From: Joern Rennecke To: "Frank Ch. Eigler" Cc: cgen@sources.redhat.com Subject: Re: copyright issues for cgen-generated tools Message-ID: <20070116132856.GA27599@elsdt-razorfish.arc.com> References: <20070115113749.GA27642@elsdt-razorfish.arc.com> <20070115193844.GA22188@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070115193844.GA22188@redhat.com> User-Agent: Mutt/1.4.1i Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00006.txt.bz2 > > 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)))) ) )