From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27223 invoked by alias); 16 Sep 2013 23:28:36 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 27206 invoked by uid 89); 16 Sep 2013 23:28:35 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Sep 2013 23:28:35 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VLiDW-0002Bv-FV from joseph_myers@mentor.com ; Mon, 16 Sep 2013 16:28:30 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Sep 2013 16:28:29 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.2.247.3; Tue, 17 Sep 2013 00:28:27 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VLiDS-0008Jz-Mp; Mon, 16 Sep 2013 23:28:26 +0000 Date: Mon, 16 Sep 2013 23:28:00 -0000 From: "Joseph S. Myers" To: , Subject: e500 port plans Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-09/txt/msg00097.txt.bz2 I intend to contribute support for the e500 variant of Power Architecture processors to glibc. A previous version of this was posted in 2007 . I intend to do various things differently from that version of the port: * This time I intend the ABI to be exactly that of the existing soft-float Power glibc port, rather than the previous state of two ABI variants for e500v1 and e500v2, slightly different from each other and from soft-float. See for details of the exact differences from the previous e500 port. Thus, this will effectively be an optimized variant of the soft-float port. * As a consequence, the port will not include the SPE PIM string to fixed-point symbols atosfix16 atosfix32 atosfix64 atoufix16 atoufix32 atoufix64 strtosfix16 strtosfix32 strtosfix64 strtoufix16 strtoufix32 strtoufix64. They could go in a separate library, maybe built as a glibc add-on (as they did in Aldy's original SPE add-on); they do use the GMP code in libc the same way as strtod does, so would either need to use those objects from the glibc build, or would need glibc to export those symbols at GLIBC_PRIVATE (which could be of use anyway in libm, given the GMP code is generally faster than the existing multiple-precision code in libm). But I suspect those functions were never really being used anyway. * Where it seems most appropriate, conditionals in common powerpc sysdeps files will be used instead of artificially separating things to keep as much as possible in ports. (Where new files in new sysdeps directories seem to make the most sense, those will still go in ports while the existing soft-float port is there.) * Patches will be submitted incrementally when ready rather than one big submission of everything. (Some patches adding or adjusting conditionals in installed headers went in some time ago.) Note that the Power Architecture documents include a lot more possible variations than I actually intend to cover in this port, and GCC's command-line options in principle provide their own set of variations. In particular: * The Power Architecture defines both SPE and three separate embedded floating-point categories, Embedded vector single-precision floating-point [SP.FV], Embedded scalar single-precision floating-point [SP.FS] and Embedded scalar double-precision floating-point [SP.FD], each of which requires SPE but is independent of the other. The presumption of the port is that SP.FS is present, possibly together with SP.FD. The case of SP.FD without SP.FS is not considered (and not supported by GCC). If neither is supported, all that's relevant is the register high parts that can be used by SPE instructions; I expect that case would work (through appropriate conditionals in functions such as setjmp/longjmp along the lines of defined __SPE__ || (defined __NO_FPRS__ && !defined _SOFT_FLOAT)), though it isn't tested. * The combination of e500 features with classic floating-point is not considered (and not supported by GCC). The combination with classic 64-bit is not considered (and not supported by GCC). Both of those are in principle supported by the Power Architecture (there are even some instructions that are only defined for the combination, to convert between floating-point and 64-bit integers), though I'm not aware of any implementations. * I don't really expect the combination of e500 features with little-endian to work in either glibc or GCC (although again it's defined in the architecture). * Various instruction patterns in GCC require that non-e500 instructions only affect the low 32 bits of registers and not the high parts, and it's quite likely some code in glibc may end up implicitly requiring the same; this accords with e500 documentation, but the Power Architecture documents leave the high parts undefined after such instructions. In principle, some things such as setjmp/longjmp support for register high parts could be runtime-conditional based on HWCAP bits, but I don't think that's particularly useful for the users of these processors and don't plan to implement it. -- Joseph S. Myers joseph@codesourcery.com