mjw@f.gp.cs.cmu.edu.UUCP (05/17/87)
Keywords:
I was using someone's Manx compiler to compile the fractal terraion
generator sc.c (which, incidentally just guru'd when I tried to run it..)
anyway, it has a line
short Cell[COUNT][COUNT];
in it (a global). This compiles, but is an undefined symbol at link time.
Changing the line to
static short Cell ....
fixed this.
Conclusion: this compiler (at least) does not understand C.
Now if Microsoft would write Intuition support and a MC680XX code generator
for MC4.0.... dream on :->.
michael.
--
====================================================================
Michael.Witbrock@f.gp.cs.cmu.edu
US Mail: Michael Witbrock
Dept of Computer Science
Carnegie Mellon University
Pittsburgh PA 15213-6890
USA
Telephone : (412) 268 3621 [Office]
(412) 681 3806 [Home]
========================================================
"Be good, be kind, in whatever you say and do, and remember: keep cool
till after school." (Ollie Olsen, Television New Zealand Kids Programme host
[Translated from sign language] ).farren@hoptoad.uucp (Mike Farren) (05/17/87)
In article <56@f.gp.cs.cmu.edu> mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes: >Now if Microsoft would write Intuition support and a MC680XX code generator >for MC4.0.... dream on :->. It is interesting to note that one of the include files for Microsoft C 3.0 contained the line #ifdef MC68000 Sorta makes you wonder, eh? -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Daysg
hull@hao.UCAR.EDU (Howard Hull) (05/17/87)
In article <56@f.gp.cs.cmu.edu>, mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes: > anyway, it has a line > > short Cell[COUNT][COUNT]; > > in it (a global). This compiles, but is an undefined symbol at link time. Ar haw! Thank you velly much. I could hardly believe my eyes when BOTH 3.20a and 3.40a urped the _Cell tag without producing an executable. I said to myself "self, does this compiler think that a declaration with two sets of square brackets following the variable name is a *function*? GOOD LORD! But then, I thought, "maybe it just croaks like this when it runs out of space for the variable..." So I reduced the array size to 128 by 128 and it took it. So then, I thought "ok, maybe it can hack it with large data." No dice. "Maybe large code?" No dice. "Maybe large code and large data?" No dice. I then decided "well, what if it gets it as a one dimensional array?" So I started hacking it up, hoping to gain the additional capacity to do [n x m], where n x m = 2^k. You wouldn't believe what happened then. It mirrored about the x/y diagonal. Probably something I did wrong in the code, but really, linearizing an array is a pretty simple affair, like (x * y) + x instead of x,y. Then I ran out of time, you know, 2am Monday last. Oh well... Best Regards, Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull for domain mailers: hull@hao.9 Fwit' b
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/17/87)
You just ran across the infamous "cannot make declaration larger than 32K problem. E.G., if COUNT was defined to be, say, 256, then the storage would be 131072 bytes. The Aztec (And this is *definately* a bug) compiler uses unsigned shorts to remember global sizes. I believe the assembler has the same problem. Worse, if you declare something that is larger than 32K, the compiler doesn't tell you that it isn't giving you the space you requested! E.G. char cell[65535] gives you an 'array size cannot be negative' error, but char cell[65537] doesn't give an error message and only allocates a single byte. In anycase, what happened was that the generated assembly became: global Cell,0 instead of global Cell,131072 Which caused the assembler to ignore the declaration. Apart from this size limitation, I have found the Aztec does just about everything right. I use strange and uncommon declarations all the time and there isn't a problem. In fact, both Lattice and Aztec are very good compilers. I tend to like Aztec better, however. With a 1.4 Meg ram disk and precompiled symbol tables, compiles only take a few seconds! Whereas with Lattice, I would be eating up another 100K and would have to wait while the thing compiled all the thousands of #include's over and over again. -Matt Your message: :I was using someone's Manx compiler to compile the fractal terraion :generator sc.c (which, incidentally just guru'd when I tried to run it..) :anyway, it has a line : :short Cell[COUNT][COUNT]; : :in it (a global). This compiles, but is an undefined symbol at link time. :Changing the line to : :static short Cell .... : :fixed this. :Conclusion: this compiler (at least) does not understand C. :ow if Microsoft would write Intuition support and a MC680XX code generator :or MC4.0.... dream on :->. : :michael. BTW Microsoft? There getting almost as bad as IBM. I wouldn't trust them to give us a well supported compiler any more than I would trust my dog with an unattended cookie plate. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/17/87)
>GOOD LORD! But then, I thought, "maybe it just croaks like this when it >runs out of space for the variable..." So I reduced the array size to >128 by 128 and it took it. So then, I thought "ok, maybe it can hack it 128 * 128 * 2 = 32768, which is -1 as far as the compiler is concerned P.S. the way to get around this bug is to allocate the memory dynamically. -Matt
phils@tekigm2.TEK.COM (Philip E Staub) (05/19/87)
In article <56@f.gp.cs.cmu.edu> mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes: >I was using someone's Manx compiler to compile the fractal terraion >generator sc.c (which, incidentally just guru'd when I tried to run it..) >anyway, it has a line > >short Cell[COUNT][COUNT]; > >in it (a global). This compiles, but is an undefined symbol at link time. >Changing the line to > >static short Cell .... > >fixed this. I found another "fix" for this. What appears to be happening is that since COUNT is defined as (1<<SIZE) and SIZE is defined as 8, this winds up being Cell[256][256], which results in a data structure size of 65536. (Interesting number, eh? Translation: 0 for 16 bit ints. Read on.) The resulting declaration in the assembly language file was: global _Cell,0 (Or something similar. I don't remember exactly). The important part is the length of the data area which is generated. When I changed SIZE to 7, (Cell[128][128] = 32768) I got global _Cell,32768 as expected. (Sorry, I didn't try going the other way) I suspect that there are two different grammar productions which result in the code generated by the "short Cell[][]" and "static short Cell[][]" declarations, with the former being broken, and the latter being functional. Any comments from someone closer to the compiler source? Phil -- ------------------------------------------------------------------------------- Phil Staub tektronix!tekigm!phils (206) 253-5634 Tektronix, Inc., ISI Engineering P.O.Box 3500, M/S C1-904, Vancouver, Washington 98668
higgin@cbmvax.cbm.UUCP (Paul Higginbottom SALES) (05/19/87)
In article <56@f.gp.cs.cmu.edu> mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes:
$I was using someone's Manx compiler to compile the fractal terraion
$generator sc.c (which, incidentally just guru'd when I tried to run it..)
$anyway, it has a line
$
$short Cell[COUNT][COUNT];
$
$in it (a global). This compiles, but is an undefined symbol at link time.
$Changing the line to
$
$static short Cell ....
$
$fixed this.
It fixes the undefined part, but will DEFINITELY cause a crash when running it.
$Conclusion: this compiler (at least) does not understand C.
That's too sweeping a statement. Like everything, there's a reason for this
obscure behavior.
If you look more closely at the code, you'll see that COUNT is equal to
1 << SIZE and SIZE is equal to 8. Therefore, COUNT is 256. A 256 x 256
array is 65536 elements (!), and the compiler generates a *16* bit
array size for the assembler, and therefore outputs:
global _Cell,0
instead of:
global _Cell,65536
The assembler, seeing a size of zero, says "hey, if you reserve no space
for a variable, that variable doesn't exist", so that's why when you link
you get an unresolved reference. My fix was to set SIZE to 7, remove one
of the 32's in the table (like it says in the comment), and recompile.
This WORKS.
Paul.
$michael.