🚀 go-pugleaf

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             /^,,)__/