TOP and HIMEM in C

Let’s say I write a program. I give it a 20MB slot. It is only using 200K all in. How can I know this?

I have not seen anything “obvious” in the C runtime description (PRMv4) for describing how much memory is actively used by an application.

Looking at the library source, it looks as if O_heapTop points to the end of the currently used space (=TOP? (sort of)), and subtracting O_imageBase should say how much memory is being consumed, with O_initSlotSize looking like it provides the current amount of memory available (=HIMEM?).

Question is – are there “legal” ways to access this information? Primarily I would like to know how much memory is being used in total by a program, without doing dumb stuff like reducing WimpSlot until it crashes…

Question is – are there “legal” ways to access this information? Primarily I would like to know how much memory is being used in total by a program, without doing dumb stuff like reducing WimpSlot until it crashes…

Well the C library will prevent you from shrinking the wimpslot below the heap used limit, so if reducing the wimpslot causes your program to crash then I think you have a bug somewhere!

(Apart from the case where programs will crash on startup if there isn’t enough memory to initialise the C library, in which case it’s Acorn’s bug, not yours)

But to answer your question: No, to my knowledge there aren’t any legal ways of finding out the amount of free space in the C runtime heap.

Does a Wimp application compiled using Norcroft and linked against the Shared C Library module use OS_Heap for the malloc/free operations, or its own internal implementation? I’ve been wondering what to do to enable software which uses large amounts of memory to release it again: having a Wimp slot which can only grow is frustrating. Flex is not an option as there are too many linked data structures to use that option and stay sane!

Depends upon the Wimp library.

Sounds like you might want to roll your own, perhaps using a dynamic area?

The shared C library uses its own heap manager for managing the application workspace. It is possible to replace the heap manager by calling _kernel_register_allocs and providing your own alloc & free functions, but I’m not sure on the specifics of how to correctly take over application space. Specifically, I’m not sure how you’d get the ‘TOP’ value of what’s been used so far, so that you know where to place the base of your heap.

Maybe you could start by replacing the slot extend function, then shrink the wimpslot to minimum (getting the current size on exit), and then register the alloc functions? The slot extend function should allow you to catch any slot extensions which happen between shrinking/reading the slot size and calling _kernel_register_allocs (e.g. if it suddenly decides a new stack frame is needed). Or maybe you can defer the initialisation until you receive your first alloc request and do the shrink+read there.

perhaps using a dynamic area?

Remember that we should be discouraging people from using dynamic areas for data which is private to an application. Stomping out “large amounts” of logical address space for each instance of the app is going to be pretty harmful.

Remember that we should be discouraging people from using dynamic areas for data which is private to an application. Stomping out “large amounts” of logical address space for each instance of the app is going to be pretty harmful.

There is an OS_DynamicArea flag intended for precisely this purpose. Perhaps it might be a good idea to start making it do something.