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

2003-09-06 Thread Alexander Leidinger
On Fri, 5 Sep 2003 09:55:57 -0700
Marcel Moolenaar [EMAIL PROTECTED] wrote:

 Interesting, What does icc do with:
 
 struct {
   int tag;
   char obj[];
 } foo;
 
 And what does the sizeof() operator give.

---snip---
% marcel.c 
#include stdio.h

struct {
int tag;
char obj[];
} foo;

int main(void) {
struct foo bar;

printf(%d\n, sizeof(struct foo));
printf(%d\n, sizeof(bar));
return 0;
}


% icc marcel.c
marcel.c(9): error: incomplete type is not allowed
struct foo bar;
   ^

marcel.c(11): warning #70: incomplete type is not allowed
printf(%d\n, sizeof(struct foo));
  ^

compilation aborted for marcel.c (code 2)

% marcel.c  
#include stdio.h

struct {
int tag;
char obj[];
} foo;

int main(void) {
printf(%d\n, sizeof(struct foo));
return 0;
}

% icc marcel.c
marcel.c(9): warning #70: incomplete type is not allowed
printf(%d\n, sizeof(struct foo));
  ^
% ./a.out 
0
---snip---

Bye,
Alexander.

-- 
  Loose bits sink chips.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-06 Thread John-Mark Gurney
Alexander Leidinger wrote this message on Sat, Sep 06, 2003 at 10:33 +0200:
 struct {
^ try moving foo to here.
 int tag;
 char obj[];
 } foo;
^^^ from here.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-06 Thread Alexander Leidinger
On Sat, 6 Sep 2003 01:42:59 -0700
John-Mark Gurney [EMAIL PROTECTED] wrote:

 Alexander Leidinger wrote this message on Sat, Sep 06, 2003 at 10:33 +0200:
  struct {
 ^ try moving foo to here.
  int tag;
  char obj[];
  } foo;
 ^^^ from here.
 

Uhm... yes, sorry.

---snip---
% marcel.c   
#include stdio.h

struct foo {
int tag;
char obj[];
};

int main(void) {
struct foo bar;

printf(%d\n, sizeof(struct foo));
printf(%d\n, sizeof(bar));

return 0;
}

% ./a.out 
4
4
---snip---

Bye,
Alexander.

-- 
Yes, I've heard of decaf. What's your point?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-06 Thread Marcel Moolenaar
On Sat, Sep 06, 2003 at 10:57:52AM +0200, Alexander Leidinger wrote:
 
 ---snip---
 % marcel.c   
 #include stdio.h
 
 struct foo {
 int tag;
 char obj[];
 };
 
 int main(void) {
 struct foo bar;
 
 printf(%d\n, sizeof(struct foo));
 printf(%d\n, sizeof(bar));
 
 return 0;
 }
 
 % ./a.out 
 4
 4
 ---snip---

The compiler seems to behave correctly WRT C99. However, when
presented with code that uses extensions the compiler behaves
inconsistently or erratically. If the compiler cannot do any-
thing useful with zero-sized arrays, it should reject them
completely. Only then can one reasonably fall back on C99 to
explain the behaviour of the compiler. However, since the
compiler accepts zero-sized arrays, it is already in violation
with C99 and one cannot use C99 as a basis to explain the
any behaviour of the compiler in the context of the non-compliant
construct. The creation of single-element array instead of
the declared zero-element array is downright broken.

My $0.02

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-05 Thread Alexander Leidinger
On Thu, 4 Sep 2003 15:57:31 -0700
Marcel Moolenaar [EMAIL PROTECTED] wrote:

 On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote:
  
  I guess the correct question to be asking is does the ELF format allow
  0-length symbols?
 
 Of course. What size do you think a label should have otherwise?

After mentioning the difference between gcc and icc I've got this
response:
---snip---
Regarding the zero size array issue:

Objects with zero size are incomplete objects and cannot be used in any
meaningful way.  Zero length arrays are explicitly prohibited by the
Standard.  We allowed zero length arrays as a feature request.  We set
their size to one so operations involving them can make some kind of
sense.
---snip---

Can you please give me something a compiler developer should
understand (an URL, a reference into some standard, a description, ...)?
As long as we can provide strong evidence that gcc doesn't do the wrong
thing Intel will change icc to be compatible with gcc.

Bye,
Alexander.

-- 
Give a man a fish and you feed him for a day;
 teach him to use the Net and he won't bother you for weeks.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-05 Thread Bruce Evans
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
 0006 C FOOBARw0
  C FOOBARw1
  C FOOBARw2
  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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-05 Thread Stefan Farfeleder
On Thu, Sep 04, 2003 at 11:28:58AM -0500, Dan Nelson wrote:
 In the last episode (Sep 04), Alexander Leidinger said:

   - If we depend on it: how hard would it be to rewrite it to not depend
 on 0-sized arrays (and does someone volunteer to rewrite it)? It
 would be nice if someone could point me to the source if it isn't
 an easy task, my contact @Intel is willing to convince the
 developers to change icc, but he has to present a persuasive
 argument to development to pursue a solution.
 
 If you're talking FreeBSD 5, you should be able to simply subsitute a
 C99 flexible array member (basically replace [0] with []) and get
 the same effect.  0-length arrays are a gcc extension:

But even with flexible array members you cannot create an object with
size 0.  The struct must have at least one additional member and you
cannot use sizeof on the flexible array member itself as its type is
incomplete.

Cheers,
Stefan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-05 Thread Marius Strobl
On Fri, Sep 05, 2003 at 07:34:39PM +1000, Bruce Evans wrote:
 On Fri, 5 Sep 2003, I wrote:
 
  ...
  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
chain  insists
  for alignment like a broken aout version used to do.  16-bit values
  would need 17 bits to represent after adding 1.
 
 Better, add 0x1 to avoid 0.  awk has no support for parsing hex numbers
 so subtracting the bias of 1 would take a lot more code, but ignoring
 leading hexdigits requires no changes in genassym.sh -- it already ignores
 everything except the last 4 hexdigits.
 

This works, too. Thanks for the detailed explanation Bruce!

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-05 Thread Marcel Moolenaar
On Fri, Sep 05, 2003 at 10:55:07AM +0200, Alexander Leidinger wrote:
  
  It does, according to my reading of it.  They may have an issue with
  dead code removal or element aliasing.  The way to find out would be
  to see what they emit for []... 0 lenth, or 1?
 
 % icc.c 
 char array[];
 
 % nm icc.o
 0001 C array

Interesting, What does icc do with:

struct {
int tag;
char obj[];
} foo;

And what does the sizeof() operator give.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Alexander Leidinger
Hi,

I'm in the process of building our kernel with Intels C Compiler (icc).
So far we are able to build a working UP and SMP kernel (not completely
automated). Most of it works just fine (NFS-client is known to not
work).

At the moment I discussing an issue with Intel regarding 0-sized arrays.
gcc seems to be violating the standard and produces code with an array
size of 0, whereas icc produces code where an 0-sized array has the
size 1. This results in different nm output of genassym.o:

gcc generated:
---snip---
 C BC32SELsign
0050 C BC32SELw0
 C BC32SELw1
 C BC32SELw2
 C BC32SELw3
---snip---

icc generated:
---snip---
0001 C BC32SELsign
0050 C BC32SELw0
0001 C BC32SELw1
0001 C BC32SELw2
0001 C BC32SELw3
---snip---

Thus the output of genassym.sh with a icc generated genassym.o is wrong:
---snip---
#define BC32SEL -0x1000100010050
#define BI_ENDCOMMON-0x100010001000c
#define BI_ESYMTAB  -0x1000100010044
#define BI_KERNELNAME   -0x1000100010004
#define BI_KERNEND  -0x1000100010048
#define BI_NFS_DISKLESS -0x1000100010008
#define BI_SIZE -0x1000100010030
---snip---

With a gcc generated genassym.o it looks like:
---snip---
#define BC32SEL 0x50
#define BI_ENDCOMMON0xc
#define BI_ESYMTAB  0x44
#define BI_KERNELNAME   0x4
#define BI_KERNEND  0x48
#define BI_NFS_DISKLESS 0x8
#define BI_SIZE 0x30
---snip---

At least the generated defines are used in locore.s, but is this the
only consumer of this feature? What I need to know is:
 - Do we really depend on 0-sized arrays in the code or is it just a
   genassym.sh issue?
 - If we depend on it: how hard would it be to rewrite it to not depend
   on 0-sized arrays (and does someone volunteer to rewrite it)? It
   would be nice if someone could point me to the source if it isn't
   an easy task, my contact @Intel is willing to convince the
   developers to change icc, but he has to present a persuasive argument
   to development to pursue a solution.
 - If it is a genassym.sh issue: would someone with enough glue please
   provide me with a patch for genassym.sh which either uses a switch
   to understand the icc generated file or is able to detect it on it's
   own (I'm able to provide the output of nm and/or the object file)?
   Or at least describes what needs to be done, so I can try do do it
   myself after refreshing my awk knowledge?

Bye,
Alexander.

-- 
Failure is not an option. It comes bundled with your Microsoft product.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Dan Nelson
In the last episode (Sep 04), Alexander Leidinger said:
 At the moment I discussing an issue with Intel regarding 0-sized
 arrays. gcc seems to be violating the standard and produces code with
 an array size of 0, whereas icc produces code where an 0-sized
 array has the size 1. This results in different nm output of
 genassym.o:
[snip] 
  - If we depend on it: how hard would it be to rewrite it to not depend
on 0-sized arrays (and does someone volunteer to rewrite it)? It
would be nice if someone could point me to the source if it isn't
an easy task, my contact @Intel is willing to convince the
developers to change icc, but he has to present a persuasive
argument to development to pursue a solution.

If you're talking FreeBSD 5, you should be able to simply subsitute a
C99 flexible array member (basically replace [0] with []) and get
the same effect.  0-length arrays are a gcc extension:

http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
the gcc extension.  Intel has added support for a lot of gcc extensions
recently; they may be willing to add this to the list.

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Alexander Leidinger
On Thu, 4 Sep 2003 11:28:58 -0500
Dan Nelson [EMAIL PROTECTED] wrote:

 If you're talking FreeBSD 5, you should be able to simply subsitute a
 C99 flexible array member (basically replace [0] with []) and get
 the same effect.  0-length arrays are a gcc extension:
 
 http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
 
 Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
 the gcc extension.  Intel has added support for a lot of gcc extensions
 recently; they may be willing to add this to the list.

Please read my mail again, icc already supports my_array[0], but the
resulting array in the binary has size '1'. The actual showstopper is
the output of genassym.sh. To me it seems it's just a genassym.sh issue,
but I don't really know what's going on in the kernel, so I ask here.

Bye,
Alexander.

-- 
  Weird enough for government work.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Marcel Moolenaar
On Fri, Sep 05, 2003 at 12:14:11AM +0200, Alexander Leidinger wrote:
 On Thu, 4 Sep 2003 11:28:58 -0500
 Dan Nelson [EMAIL PROTECTED] wrote:
 
  If you're talking FreeBSD 5, you should be able to simply subsitute a
  C99 flexible array member (basically replace [0] with []) and get
  the same effect.  0-length arrays are a gcc extension:
  
  http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
  
  Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
  the gcc extension.  Intel has added support for a lot of gcc extensions
  recently; they may be willing to add this to the list.
 
 Please read my mail again, icc already supports my_array[0], but the
 resulting array in the binary has size '1'. The actual showstopper is
 the output of genassym.sh. To me it seems it's just a genassym.sh issue,
 but I don't really know what's going on in the kernel, so I ask here.

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
0006 C FOOBARw0
 C FOOBARw1
 C FOOBARw2
 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.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Dan Nelson
In the last episode (Sep 05), Alexander Leidinger said:
 On Thu, 4 Sep 2003 11:28:58 -0500
 Dan Nelson [EMAIL PROTECTED] wrote:
  If you're talking FreeBSD 5, you should be able to simply subsitute
  a C99 flexible array member (basically replace [0] with [])
  and get the same effect.  0-length arrays are a gcc extension:
  
  http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
  
  Under FreeBSD 4.x, you can't use them because gcc 2.95 only
  supports the gcc extension.  Intel has added support for a lot of
  gcc extensions recently; they may be willing to add this to the
  list.
 
 Please read my mail again, icc already supports my_array[0], but the
 resulting array in the binary has size '1'. The actual showstopper is
 the output of genassym.sh. To me it seems it's just a genassym.sh
 issue, but I don't really know what's going on in the kernel, so I
 ask here.

Ok, I reread the original message, and it's still a zero-length array
problem, but in a different place.

What it looks like to me is that icc silently converts zero-length
arrays to 1 element when creating the assembly output.  While it's
processing C source, sizeof(my_array) returns 0, but the emitted
assembly says otherwise:

$ cat  test.c
int test0[0];
int test1[1];
int test2[2];
^D
$ gcc -c test.c -S -o test.gcc
$ icc -c test.c -S -o test.icc
$ grep comm test.?cc
test.gcc:   .comm   test0,0,4
test.gcc:   .comm   test1,4,4
test.gcc:   .comm   test2,8,4
test.icc:   .comm test2,8,4
test.icc:   .comm test1,4,4
test.icc:   .comm test0,4,4

So gcc emitted symbols with the same size as in the source file, with
an alignment of 4 bytes (since I'm using ints in this example), but icc
adjusted the test0 symbol to be one int long.  I used ints to make it
more obvious what icc is doing; the effect is the same if you use
chars.

I guess the correct question to be asking is does the ELF format allow
0-length symbols?  If not, then gcc is generating invalid objects, and
genassym will have to be rewritten to not use them (maybe add one to
the array size, and have genassym.sh subtract it).  If it does, then
genassym.c (sys/assym.h actually) is legal code.  If Intel doesn't want
to change icc, we can still work around it, but there may be other code
that will break on icc just like assym.h.

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Marcel Moolenaar
On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote:
 
 I guess the correct question to be asking is does the ELF format allow
 0-length symbols?

Of course. What size do you think a label should have otherwise?

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Marius Strobl
On Thu, Sep 04, 2003 at 03:47:09PM -0700, Marcel Moolenaar 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
   0006 C FOOBARw0
    C FOOBARw1
    C FOOBARw2
    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? I have successfully
generated assyms.s' using genassym.sh(8) from NetBSD and both ICC and
GCC on i386 which have exactly the same values as one generated with
sys/kern/genassym.sh from FreeBSD. 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.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Marcel Moolenaar
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
  0006 C FOOBARw0
   C FOOBARw1
   C FOOBARw2
   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  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


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

2003-09-04 Thread Garrett Wollman
On Thu, 4 Sep 2003 18:19:02 -0700, Marcel Moolenaar [EMAIL PROTECTED] said:

 In theory, yes. In practice, maybe not. If I remember correctly,
 the problem we're trying to solve is twofold:

Actually, the problem we were trying to solve is simpler than that.

genassym needs to be able to compute the values of certain constants
from header files which are only accessible to kernel code.  At the
same time, it needs to be able to run as a user process.  One
compilation unit cannot include both Standard headers like stdio.h
and kernel-specific headers like sys/systm.h.  In fact, we muck with
the include path to ensure that Standard headers cannot be included
while compiling kernel source.

Cross-compilation does engender other issues, but that wasn't the
original motivation.

-GAWollman

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]