🚀 go-pugleaf

You are obviously not a computer scientist, because if you were you'd be 
so genned up on multiply-linked lists etc. that you would probably not 
hit this problem :-)

TS3 has got a limit of 64K (approx) data per module IIRC, or 64K (approx) 
per data structure on the heap (RTFM). What _exactly_ are you trying to 
do?

If the problem is not so much that you need large data elements but 
simply a lot of storage space, your choices are (i) run a decent OS (OS/2 
or possibly Windows) that will support larger programs (ii) use expanded 
memory (iii) use the TopSpeed DOS extender. Note that the above would be 
my order of preference.

I _may_ have some EMS demo code that would be of use to you, but this 
obviously limits a data structure to 16K.

Mark Morgan Lloyd
mark_tbu@cix.compulink.co.uk

[Opinions above are the author's, not those of his employers or 
colleagues]

Ross & Mandy (Ross&Mandy@sinex.demon.co.uk) wrote:

>For various reasons, I need to extend my data area beyond 64K 
>in Topspeed Modula-2 V3. Does anyone know how to do this? I 
>have tried near and far allocations with no joy. 

If you're talking about the total data area then this is
easy - just use the XLarge memory model - but I guess you've
already tried this.  If you're talking about the total
static data space used by one module, then the solution is
to break the module into smaller modules.

But if you're talking about the size of a single array,
you're most likely in trouble.  Even if you could allocate
the space, how could you fit an array subscript into a
16-bit CARDINAL?  From memory, I don't think TopSpeed allows
LONGCARD subscripts, and even the OS/2 version of TopSpeed
still uses 16-bit arithmetic.  (This might have changed in
the Clarion version, I don't know.)  If you absolutely must
use 32-bit subscripts, you probably need another compiler.

The real question to ask, I think, is: do you really need to
organise your data into a huge array?  Once you start using
huge static data structures you tend to run into other problems,
for example efficiency-related problems.  Most problems of this
kind can be solved by better design of the data structures.

--
Peter Moylan                           peter@ee.newcastle.edu.au
                  http://www.eng.newcastle.edu.au/ee/Moylan.html
OS/2 freeware list at 
      http://www.eng.newcastle.edu.au/ee/Moylan/os2/os2info.html

In article <4i2bia$f9e@seagoon.newcastle.edu.au>
           peter@tesla.newcastle.edu.au "Peter Moylan" writes:

> Ross & Mandy (Ross&Mandy@sinex.demon.co.uk) wrote:
> 
> >For various reasons, I need to extend my data area beyond 64K 
> >in Topspeed Modula-2 V3. Does anyone know how to do this? I 
> >have tried near and far allocations with no joy. 
> 
> If you're talking about the total data area then this is
> easy - just use the XLarge memory model - but I guess you've
> already tried this.  If you're talking about the total
> static data space used by one module, then the solution is
> to break the module into smaller modules.

Or allocate an array of pointers to blocks of data which you
allocate dynamically and then do your own indexing arithmetic.
Don't you just love segmented architectures ;-)
 
> But if you're talking about the size of a single array,
> you're most likely in trouble.  Even if you could allocate
> the space, how could you fit an array subscript into a
> 16-bit CARDINAL?  From memory, I don't think TopSpeed allows
> LONGCARD subscripts, and even the OS/2 version of TopSpeed
> still uses 16-bit arithmetic.  (This might have changed in
> the Clarion version, I don't know.)  If you absolutely must
> use 32-bit subscripts, you probably need another compiler.

The 32 bit pointer isn't such a problem you can use masking or
MOD & DIV to convert a linear 32 bit index into the block number 
and index inside block. Some compilers can be persuaded to do
this as inline code (since it's a very small size overhead).

> The real question to ask, I think, is: do you really need to
> organise your data into a huge array?  Once you start using
> huge static data structures you tend to run into other problems,
> for example efficiency-related problems.  Most problems of this
> kind can be solved by better design of the data structures.

There are a few cases where if you have enough physical memory it  
is worthwhile reading the whole lot in and working on it in core.
N-d FFTs spring to mind as a good example of this.

OTOH it can be really *bad* on a demand paged virtual memory machine where 
repeated access with large strides forces a page fault for every instruction!

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

What I do for really big arrays is create a opaque type or class
VIZ:

TYPE
   BIG = ARRAY[0..MAX(CARDINAL)-1] OF BYTE;
   DYNCOL = POINTER TO DYNDATA;
   DYNDATA= RECORD
      currentSize:CARDINAL;
      data : POINTER TO BIG;
   END; 
   DYNARRAY= ARRAY[0..LASTROW] OF DYNCOL;

In use you use ALLOCATE not NEW to set the actual size of the 
data part in DYNADATA and make sure to save the currentSize to be 
able to DEALLOCATE, Rows not used are NIL. You can of course use 
any types suitable for BIG as long as:
1) it is no more than 64K
2) you supply all the procedures and functions in the MODULE too, 
the implementation of DYNA0RRAY (the opaque type ) must be 
private as this is dangerous. Be carefull writing rountines to 
read or write DYNARRAY.