🚀 go-pugleaf

I am developing an application that demands large amounts of RAM for
processing. By large I mean the program will not run with less than 2Mb of
FAST ram, and it needs 4Mb to really go. The program is related to Satellite
Image Processing work, and loads parts of 250Mb data sets from WORM drives.

Anyway, the problem I have is this :

The program allocates a number of cache buffers (typically less than 8), which
are set up to take all of available FAST ram. The naive solution is to simply
do :

  available_ram = AvailRam(MEMF_FAST) - overhead_ram_needed;
  per_buffer_ram = available_ram / number_of_buffers;
  /* now allocate each buffer */

[no, I don't normally use variable names that long...]

There are two problems with this :

1. Memory Fragmentation. As FAST ram may be fragmented, the allocation may
   fail, even though there is actually ram present. I have considered a number
   of ways to solve this, none of which I like. One way is to go and examine
   the memory fragment list. This is unfriendly to multi-tasking, and very
   internal system dependant [if C=A changes things, it breaks].
   Currently, if the allocation fails then I deallocate the caches, and try
   again, this time with the known memory pool that I can allocate (e.g. that
   consists of large fragements). This method works, but I am unhappy with it.

2. FAST ram vs CHIP ram. As you can see, I only use FAST ram for the cache
   buffers. All of CHIP ram is taken up by other operations, such as high-res/
   high bitplane screens with superbitmaps. The problem is that the program
   is assuming that CHIP ram is always distinct from FAST ram. Is this a
   valid assumption? In other words, does [or will :-)] the mythical Amiga
   3000 combine CHIP and FAST ram? If so, then I would like to somehow
   consider this fact during cache allocation, as the current method will
   break on such a system.

Thanks in advance for you comments or suggestions,

sns	(Stuart Nixon)
 
   
sns      Stuart Nixon Software
Phone :  +61 9 322 6497
Uucp  :  ...{uunet,mcvax,ukc}!munnari!acp.oz!sns 
ACSnet:  sns@acp.oz