scot@rtmvax.UUCP (Scot Harris ) (07/11/88)
I was unable to help a friend on the local network with the following
problem. I only have the Lattice 4.0 compiler and was able to do
what the manx compiler apprently can not.
Anyway I thought some of the Manx experts on this net might have run
across this or have some ideas that we have not tried. Please email
your responses to me at:
--------_----------------------------------------------------------
/// /_\ Scot L. Harris !hoptoad!peora!rtmvax!scot
\XX/ / \ M I G A or rtmvax!amigash!scot
[of course I GNUUUCP from my AMIGA, doesn't everyone?] {thanks Mr. Loftus}
Following is the message that I was requested to pass on. If you have any
ideas for solving this problem please email me. Thanks.
------------------------------------------------------------------------
Aztec C68K Compiler Version 3.6a
Amiga A500 + stock Commodore internal 512K expansion memory
+ Micron 2 Meg expansion Ram in SubSystem 500
KickStart = 33.180 Boot with SYS1 disk from Aztec C68 developers compiler.
Chip memory available at program startup equal to 436 K with Fast memory
equal to 2491 K..
THE PROBLEM:
Guru visitations when I attempt to set up and use large arrays. Use of the
+D option when compiling does not help. Here is my sample code to
illustrate the problem:
/* try.c */
main() { static char Map [100000L]; long int i;
for (i=0; i<100000L; i++)
Map [i] = 'c';
puts ("We Did It"); }
The following compiler, assembler, and linker commands are used:
cd df1:code /* SYS1: in df0: try.c in df1:code */
cc -A +D try.c as -D try ln try.o -lc
I have also compiled using +C, +F, +L options , and also without any
options just for good measure. The assembler has also been used without
options.
All other applications work fine on my system. The above code runs fine
under 64K and the small data model. What's the problem?
--------------------------------------------------------------------------
--
--------_----------------------------------------------------------
/// /_\ Scot L. Harris !hoptoad!peora!rtmvax!scot
\XX/ / \ M I G A or rtmvax!amigash!scot
[of course I GNUUUCP from my AMIGA, doesn't everyone?] {thanks Mr. Loftus}trn@warper.jhuapl.edu (Tony Nardo) (07/11/88)
In article <1795@rtmvax.UUCP> scot@rtmvax.UUCP (Scot Harris ) writes: > >THE PROBLEM: > >Guru visitations when I attempt to set up and use large arrays. Use of the >+D option when compiling does not help. Here is my sample code to >illustrate the problem: > > >/* try.c */ > >main() { static char Map [100000L]; long int i; > >for (i=0; i<100000L; i++) > Map [i] = 'c'; > >puts ("We Did It"); } > >... > >All other applications work fine on my system. The above code runs fine >under 64K and the small data model. What's the problem? > That bug STILL hasn't been fixed?! I've noticed the same problem on 3.4. If you look at the code the assembler generates, you'll see that Aztec C is VERY unhappy about using array sizes larger than 64K. If you try to use more than 64K, it will use some other number (in my case, the low 16 bits of the intended array size) as the array size. However, the code that references the array will generate just fine. Thus, when you access memory beyond the generated boundary, all bets are off as far as where you're writing - other data, other processes, etc. I've had the Guru visit me via this manner. To work around the problem, I've been using a malloc() call to grab the memory I need at the start of the program. This is probably a cleaner use of large memory chunks anyway, since I can give them back to the system when I'm done with them. All the same, I don't like having a compiler FORCE me to be a better programmer... Tony P.S. MANX, if you're out there - I received V3.4 last winter, mailed in the registration card, but STILL haven't heard anything about upgrading to V3.6... ============================================================================== ARPA: trn@warper@aplvax.jhuapl.edu \ one of these should work, aplcen!isl!trn@aplvax.jhuapl.edu } but you may have to route nardo%str.decnet@capsrv.jhuapl.edu / thru ucbvax.berkeley.edu UUCP: aplcen!aplvax!trn@warper USnail: c/o Johns Hopkins University/APL, Room 7-53 Johns Hopkins Road Laurel, Md. 20707 "bug , n. ... 4. [Sl.] undocumented software feature" ==============================================================================
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (07/12/88)
In article <1795@rtmvax.UUCP> scot@rtmvax.UUCP (Scot Harris ) writes: > >I was unable to help a friend on the local network with the following >problem. I only have the Lattice 4.0 compiler and was able to do >what the manx compiler apprently can not. >[...] >THE PROBLEM: > >Guru visitations when I attempt to set up and use large arrays. Use of the >+D option when compiling does not help. Here is my sample code to >illustrate the problem: > > >/* try.c */ > >main() { static char Map [100000L]; long int i; I personally would just stop doing that, and instead: #include "exec/types.h" #include "libraries/dos.h" main() { UBYTE *Map = 0L; if(!(Map = (UBYTE *)AllocMem(100000L,MEMF_PUBLIC|MEMF_CLEAR))) cleanexit("Not enough mem",RETURN_FAIL); /* Then just reference Map as an array, as before */ if(Map) FreeMem(Map,100000L); cleanexit("",RETURN_OK); } cleanexit(s,n) UBYTE *s; int n; { /* if you wish, print error if you have somewhere to print it */ exit(n); } -- ========================================================================== Carolyn Scheppner -- CATS Commodore Amiga Technical Support PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn Pad with zeros for a light, airy program. ==========================================================================
scott@applix.UUCP (Scott Evernden) (07/12/88)
In article <1795@rtmvax.UUCP> scot@rtmvax.UUCP (Scot Harris ) writes: > >main() { static char Map [100000L]; long int i; > Manx has for a long time had a bug which prevents arrays larger than 65535 bytes; this (I would guess) is due to the compiler using 16 bit quantities when formatting the assembly output file. Sizes larger than 65535 are truncated to 16 bits. To get around this in the past I have done: a) malloc() the otherwise static array. b) generate an .asm file (cc -at), hand edit it, and then 'as' it. -scott