From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 01:40:46 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7EC216A4C0 for ; Fri, 5 Sep 2003 01:40:46 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE88B43FBF for ; Fri, 5 Sep 2003 01:40:44 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id SAA16012; Fri, 5 Sep 2003 18:39:41 +1000 Date: Fri, 5 Sep 2003 18:39:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar In-Reply-To: <20030905011902.GA955@athlon.pn.xcllnt.net> Message-ID: <20030905180200.D9084@gamplex.bde.org> References: <20030904180448.021a1b6b.Alexander@Leidinger.net> <20030905001411.3a9030b3.Alexander@Leidinger.net> <20030905025922.A68885@newtrinity.zeist.de> <20030905011902.GA955@athlon.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexander Leidinger cc: current@freebsd.org cc: Marius Strobl Subject: Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2003 08:40:47 -0000 On Thu, 4 Sep 2003, Marcel Moolenaar wrote: > On Fri, Sep 05, 2003 at 02:59:22AM +0200, Marius Strobl wrote: > > > > > > We use the size of the symbol (ie the size of the object identified > > > by the symbol) to pass around values. This we do by creating arrays. > > > If we want to export a C constant 'FOOBAR' to assembly and the constant > > > is defined to be 6, then we create an array for the sign, of which the > > > size is 1 for negative numbers and 0 otherwise. In this case the array > > > will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0, > > > *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the > > > 4 16-bit words that constitutes a single 64-bit entity. > > > In this case > > > 00000006 C FOOBARw0 > > > 00000000 C FOOBARw1 > > > 00000000 C FOOBARw2 > > > 00000000 C FOOBARw3 > > > > > > If the compiler creates arrays of size 1 for arrays we define as a > > > zero-sized array, you get exactly what you've observed. > > > > Is this rather complex approach really necessary? > > In theory, yes. In practice, maybe not. If I remember correctly, > the problem we're trying to solve is twofold: More like fourfold: -1: A cross-compiler must be used for the first stage. The old method of printf()'ing the results of sizeof(), etc., only works if the host machine is the same as the target machine, since sizeof() must be evaluated by a compiler for target machine and printf() can only be run on host machines. 0: Compiler output is to unportable to parse easily, so arrange to use a small portable subset of it after passing it through some standard filters. nm output was the most portable binutils-related output that I could think of. > 1. 64-bit constants given the limitations of the object format, > which included widths of 32-bit and a.out. After choosing to use nm output, there are some minor problems representing all relevant numbers using it. Numbers larger than 2^32 need to be represented but cannot be represented directly as symbol values or sizes in nm output on 32-bit machines. Numbers nearly as large as 2^32 can be represented as absolute symbols, but there is no way to generate absolute symbols in semi-portable C AFAIK. asm() statements might work but would be very unportable (apart from not being standard C, different ones might be needed for the aout and elf cases). The technique of using array sizes for all numbers works for most sizes, but the compiler might object to creating arrays almost as large as the address space, and as we have just found, to creating arrays of size 0. > 2. Sign extension or datatype limitations in awk(1)? I'm not > sure about this point. Bruce? Yes: one-true-awk uses "typedef double Awkfloat;", and gawk uses something similar by default IIRC, so awk can't hanele numbers larger than 2^53 without losing precision. "typedef long double Awkfloat;", would be no better because of my restriction of the precision of long doubles on i386's and (when genassym.sh was written) the incomplete library support for long doubles, and the nonexisted support for more than 53 bits of precision on some supported (?) hardware. Long doubles with 64 bits of precision wouldn't work for representing 128-bit integers anyway. > > ... The genassym.sh(8) of NetBSD kind > > of directly exports the C-constants so it just needs one symbol per > > constant and doesn't require zero sized arrays. Given that it's from > > NetBSD their approach also should be very MI. > > I wouldn't have a problem using NetBSD's genassym implementation, > provided we understand completely how it differs from ours and to > what extend and how it affects us and provided of course we can > live with whatever it is that's worse of just different from what > we have now. The main differences seem to be that it parses the assembler output. This is less portable and not as easy -- it takes about 5 times as much code. If some values are unrepresentable then they need to be represtended using other values. E.g., add 1 to avoid 0, or multiply by the alignment size if some element of the tool chanin instsists on rounding up things for alignment like a broken aout version used to do. 16-bit values would need 17 bits to represent after adding 1. Bruce