Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!ulowell!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: Problems with trying to grab all FAST ram Message-ID: <5351@cbmvax.UUCP> Date: 29 Nov 88 22:45:31 GMT References: <528@acp.OZ> Organization: Commodore Technology, West Chester, PA Lines: 47 in article <528@acp.OZ>, sns@acp.OZ (Stuart Nixon) says: > Keywords: memory fragmentation, CHIP vs FAST ram on a3000? > 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. Who's fragging the memory. Certainly if there are other programs running who intermix small allocations with your big allocations, this can happen. However, if YOU are the one mixing in small allocations with the big ones, it's a real easy fix. Write a friendly allocation function to handle all of the details. This function would allocate system memory in medium sized chunks, unless otherwise instructed. When you ask for a small chunk of memory, your allocator would take that from a moderate memory chunk. When you ask for a large chunk, your allocator would get that from the system instead. If your moderate chunk size is chosen correctly, none of your small allocations will cause any frags. The OS provides the Allocate() function for allocations from a memory chunk that you own. > 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 they were combined (seems pretty unlikely), you shouldn't have any problems. The MEMF_CHIP and MEMF_FAST bits in the attribute word aren't mutually exclusive, so at least in theory, you could have memory that's both CHIP and FAST using the current OS definitions. Don't wait up for it... > If so, then I would like to somehow consider this fact during cache > allocation, as the current method will break on such a system. Then you must be doing something wrong. With the simple allocator that's available in the OS now, you have no choice but to ask for MEMF_CHIP when you need CHIP memory for graphics, and MEMF_FAST (and perhaps 0 if that fails) for that buffering. You have to assume that the system memory lists have been set up to give you the best MEMF_FAST for your particular application, but that's about all you really can do. > sns (Stuart Nixon) -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession