[comp.os.msdos.programmer] Huge arrays in Turbo C++

ajai@sce.carleton.ca (Ajai Sehgal) (09/12/90)

OK, so I can't use faralloc() to allocate extended memory. I found a solution
to my problem of large arrays....with a MINOR (sarcasm) problem. I declared
my arrays as follows:
			float huge image[1024][1024]
			float huge psf[1024][1024]

The problem is when I write to any location in array image, the same location
in psf is written. This symptom is explained by looking at the addresses of 
the respective arrays, THEY'RE THE SAME!!! ie &image == &psf Why??? Is this
a compiler bug or am I doing something wrong? I'm new to object oriented 
programming. Can anyone help? Thanks in advance.

Regards, Ajai.

 

ajai@sce.carleton.ca (Ajai Sehgal) (09/13/90)

As a follow up to my last question, after further experimentation I discovered
that if two separate arrays are declared as huge with exactly the same number
of elements, they are assigned the same start address and become essentially
the same array with different names. If I alter the size of the second array
by even one element, the two arrays are completely different and held in
different memory locations. This seems to me to be a compiler bug, one that the
latest Borland patch doesn't take care of.

example:	float huge array[1024][1024];
		float huge array2[1025][1024];
                                  ^^^^^
		works just fine , array and array2 are refer to different
		memory locations.

example2:	float huge array[1024][1024];
		float huge array2[1024][1024];

		does not work , array2 is effectively a copy of array and any
		values written to array also appear in the same locations in
		array2.

Note: the above problem does not appear to happen if the array size is smaller
      than 512 x 512.

	The second discovery I made is that huge arrays work just fine when
declared within a function as a local. When I tried to declare them as Globals
outside of Main() the program compiled just fine but hung the system half way 
through the linking process. (work just fine not including the problem describedabove). Being new to C , and C++ the above strikes me as being odd. Has anyone
out there experienced similar problems, if not , what am I doing wrong? Borland's manuals are less than clear and the latest books on C++ don't help either.
Any help would be greatly appreciated.

Regards, Ajai. (ajai@sce.carleton.ca)

sigma@pawl.rpi.edu (Kevin J Martin) (09/14/90)

ajai@sce.carleton.ca (Ajai Sehgal) writes:
>OK, so I can't use faralloc() to allocate extended memory. I found a solution
>to my problem of large arrays....with a MINOR (sarcasm) problem. I declared
>my arrays as follows:
>			float huge image[1024][1024]
>			float huge psf[1024][1024]

I don't know what you're getting out of this (ie, why the addresses come out
the same), but I'm surprised it compiles.  You certainly won't get a 
1024x1024 array of floats out of it - 1024x1024 char array would take a
megabyte, and even farmalloc() only uses conventional memory!

Could we see the original code fragment?

-- 
Kevin Martin  |||  sigma@pawl.rpi.edu  |||  usergkj1@RPITSMTS.BITNET

malloy@nprdc.arpa (Sean Malloy) (09/14/90)

In article <VXC%X%#@rpi.edu> sigma@pawl.rpi.edu (Kevin J Martin) writes:
>ajai@sce.carleton.ca (Ajai Sehgal) writes:
>>			float huge image[1024][1024]
>>			float huge psf[1024][1024]

>I don't know what you're getting out of this (ie, why the addresses come out
>the same), but I'm surprised it compiles.  You certainly won't get a 
>1024x1024 array of floats out of it - 1024x1024 char array would take a
>megabyte, and even farmalloc() only uses conventional memory!

The reason that the variables point to the same address is simple --
regardless of the data type, a 1024x1024 array will wrap an integral
number of times around the complete address space on a PC-class
machine. For example, with a 32-bit data type, each array will wrap
the address space four times. Since the address space is wrapped
completely, the compiler will give the 'next' available address, which
is the same address as the previous array, to the second array
declaration.

More graphically:

	0K                                              1024K
	|----|----|----|----|----|----|----|----|----|----|
image:                                |---->---->---->---->
	>---->---->---->---->---->---->---->---->---->---->
	>---->---->---->---->---->---->---->---->---->---->
	>---->---->---->---->---->---->---->---->---->---->
	>---->---->---->---->---->----|
psf:                                  |---->---->---->---->
	>---->---->---->---->---->---->---->---->---->---->
	>---->---->---->---->---->---->---->---->---->---->
	>---->---->---->---->---->---->---->---->---->---->
	>---->---->---->---->---->----|

Realistically, the compiler should check for something like this, but
I'd be willing to bet that the Borland people didn't even consider the
idea that someone would be so unaware of hardware limitations to try
to declare two 4Mb arrays in a program for a machine with a 1Mb
address space.


                                               | "The three most dangerous
 Sean Malloy                                   | things in the world are a
 Navy Personnel Research & Development Center  | programmer with a soldering
 San Diego, CA 92152-6800                      | iron, a hardware type with a
 malloy@nprdc.navy.mil                         | program patch, and a user
                                               | with an idea."

bright@Data-IO.COM (Walter Bright) (09/15/90)

In article <ajai.653150092@talos.sce.carleton.ca> ajai@sce.carleton.ca (Ajai Sehgal) writes:
<I found a solution
<to my problem of large arrays....with a MINOR (sarcasm) problem. I declared
<my arrays as follows:
<			float huge image[1024][1024]
<			float huge psf[1024][1024]

I suspect that the problem you're having has something to do with:
	2 * sizeof(float) * 1024 * 1024 == 8 megabytes
Only about 512Kb is available...