Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

From: Marcel Moolenaar <marcel_at_xcllnt.net>
Date: Thu, 4 Sep 2003 18:19:02 -0700
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:
1.  64-bit constants given the limitations of the object format,
    which included widths of 32-bit and a.out.
2.  Sign extension or datatype limitations in awk(1)? I'm not
    sure about this point. Bruce?

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

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net
Received on Thu Sep 04 2003 - 16:20:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC