From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: Preliminary MIPS N32 port now available Date: Fri, 18 Oct 2013 18:37:46 +0200 Message-ID: <20131018163746.GA7139@debian.eduroam.u-bordeaux.fr> References: <871u3jmfkp.fsf@netris.org> <20131018082616.GA4815@debian.eduroam.u-bordeaux.fr> <87wqlalh7f.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXD3m-0004eU-7Z for guix-devel@gnu.org; Fri, 18 Oct 2013 12:38:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXD3e-0005gt-TT for guix-devel@gnu.org; Fri, 18 Oct 2013 12:37:58 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:55071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXD3e-0005gO-K6 for guix-devel@gnu.org; Fri, 18 Oct 2013 12:37:50 -0400 Content-Disposition: inline In-Reply-To: <87wqlalh7f.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org On Fri, Oct 18, 2013 at 11:41:24AM -0400, Mark H Weaver wrote: > More importantly, because there are so many patches for Loongson 2F that > are not yet ready to be applied upstream -- either because they are not > sufficiently clean, or because they choose a compile-time configuration > that uses Loongson-specific features or works around Loongson 2F bugs -- > I expect that we'll want to maintain a separate "loongson" branch for > the foreseeable future, even if some of the patches are applied to > core-updates. Personally, I think mips64el should be a fully qualified release architecture just as i686 and x86_64. So it would be better to have it in master and not in a separate branch. So far, the only machines of this architecture available (and of interest) to developers are loongson. So I would argue that for the time being, mips64el=loongson, and all patches necessary for loongson should be applied to master (assuming they do not interfere with i686 and x86_64, which I would not expect for decent patches that could be sent upstream). Maybe we might wish to keep a "loongson" in the name of the patches to make them easily identifiable. > For example, 'pixman', used by both the X server and Cairo for low-level > rendering operations, optionally includes code to use Loongson-specific > SIMD vector instructions, but the choice of whether to use this code > must be made at compile time. The Loongson-specific code makes a > dramatic improvement in rendering performance, but won't work at all on > other MIPS processors. Under the assumption mips64el=loongson, this would then not be a problem, and we would use the compiler flags needed to enable loongson optimisations on the mips64el architecture. If potentially in the future someone comes up who can contribute to a non-loongson mips64el port and has a corresponding machine, then we can revise our policy, maybe by creating a new branch, maybe by considering more fine-grained architectures (using the vendor field of the quadruple?). Andreas