Conference turris::decc

   Arrays?  Why bother?  Just use pointers...  (It's often easier, too...)

> Why bother?

Array index syntax can give the optimizer more of a chance.
For multidimentional arrays this can be important.

When the user writes the array syntax, they assert that
they are not going to reference outside of the storage
of the element.  This is important for the j index of a[i][j].

Also, the point is moot if you cannot allocate an object
larger than 4GB.  A conforming program does not access beyond
a single object (and does not compare pointers beyond a single
object).

   Aren't there some restrictions on the size of static objects under
   Digital Unix? (I won't even think about putting an 8Gb array on the stack ;-)
   At least I think there used to be.

   Of course, what's to stop you from dynamically allocating your large
   array?

   char *a;
   a = (char *) malloc(8*1024*1024*1024);
   if( a == NULL ) { ...error condition... }
   a[0]='a';  /* Use a as an array */

   -- John Faricelli

What operating system did .0 want to use?

	If it's OpenVMS Alpha V7.1, you can create and share
memory-resident global sections, mapping each within its own
process address space region, and using shared page tables.
Using 64-bit pointers, you can access an array of any size,
up to the amount of available physical memory on the system.
That's right!  The limit is not 1GB, not 2GB, not even 4GB.
Today's limit is tens of Gigabytes; tomorrow's?  Who knows?

> up to the amount of available physical memory on the system.

I didn't think this was even a limit (assuming you mean main memory).
Of course, the total amount of disk for paging still limits you...

    Not for memory resident sections.... they are limited by the amount of
    physical memory in the box and there is no pagefile backing for them.
    
    d.

I wasn't asking for a work around. I can dream up a number quit 
easily myself.
  The real question was is this a deliberate compiler limitation
imposed by standards or neglect or is this a mistake/bug in the
compiler?  

BTW the OS is Digital UNIX 4.0B and the C compiler is 
DEC C V5.2-035 on Digital UNIX V4.0 (Rev. 564)

     Cheers
           Mark :)
[Posted by WWW Notes gateway]

Here's an example on Digital UNIX V4.0:

% cat t.c
#include <stdio.h>
#include <limits.h>

main() {
  char huge_array[SIZE];
  strcpy(huge_array, "Hello world!");
  puts(huge_array);
  return 0;
}

% cc t.c -DSIZE=20; a.out  
Hello world!

% cc t.c -DSIZE=INT_MAX+1 -w
cc: Error: t.c, line 5: In the declaration of "huge_array", the array bound
"2147483647+1" is not a positive integer.
  char huge_array[SIZE];

% cc t.c -DSIZE=INT_MAX; a.out   
Segmentation fault


Note that you would probably need to increase the shell's stacksize in order to
even run the executable produced in the INT_MAX case.

Note also that there is a compiler bug that will occur if you use -trapuv (see
man cc(1)) when trying to compile large arrays:

% cc t.c -DSIZE=INT_MAX -trapuv
cc: Fatal: A memory access violation (bus error or segmentation fault)
has occurred.  Please submit a problem report.

We hope to fix that for the next major release after Digital UNIX V4.0.

-Jeff

> The real question was is this a deliberate compiler limitation
> imposed by standards or neglect or is this a mistake/bug in the
> compiler?  

> BTW the OS is Digital UNIX 4.0B and the C compiler is 
> DEC C V5.2-035 on Digital UNIX V4.0 (Rev. 564)

This is a feature in the compiler.  On Digital UNIX releases prior to
UNIX 4.0D the DEC C compiler will prohibit you from declaring a stack
frame larger than 2^31 bytes in size.  

As of UNIX 4.0D, which is scheduled to ship to customers in Nov 1997,
the compiler will let you create stack frames larger than 2^31 bytes.
However you'll need to edit your sysconfigtab file and bump your settings
for max-per-proc-address-space, max-per-proc-stack-size, per-proc-address-space
and per-proc-stack-size.  

If you ever plan to execute any of these programs, you better have a physical
memory size greater than or equal to your array size.   If you don't it will
take forever to probe the stack in the routine's prologue.  This is because 
the required stack probing code causes the vm system to do a soft pagefault
for every page it reads in your stack.  That page is now part of your process
and will need to be swapped out.  

From personal experience, on systems where the physical memory was smaller
than the stacksize, I have never seen the stack probing complete.  I usually
rebooted the system after several hours or the next morning.

Joe

  Will the limitation on static objects (put in the bss section)
  be also lifted?

  -- John Faricelli

> Will the limitation on static objects (put in the bss section)
> be also lifted?
 
Yes, as of UNIX V4.0D the DECC compiler no longer puts any restrictions
on the size of objects (stack or static) that you can create.

If you need a copy of a DECC compiler from a V4.0D system, you can get 
one from the labrea::/usr/misc/pub/C/aosf/ptmin directory.

Joe

> If you need a copy of a DECC compiler from a V4.0D system, you can get 
> one from the labrea::/usr/misc/pub/C/aosf/ptmin directory.

The Platinum.minor compiler is available via the Digital Intranet at
  http://www.zk3.dec.com/decc/decc-kitinfo.html

-Jeff