Module Storage (2)

[gray]

The Astrobe docs say about module Storage:

However, you must not change the interface definition of the module as the compiler expects it to be as shown above.

I am a bit confused here. As per the documentation about module MAU, each 'NEW' call is converted into a call to MUA.New, and for 'DISPOSE' a call to MUA.Dispose. Inspecting module MUA, these procedures simply call the procedures assigned to the variables 'allocate' and 'deallocate', respectively. So if I assign my own heap memory allocators, using MUA.SetNew and MUA.SetDispose, why is the interface definition of module Storage relevant? Module MUA does not "know" anything about module Storage and its interface.

Actually, I would want to implement my allocator and deallocator in a different module than Storage, since I need to combine it in a module with my allocator for procedure stacks (in module Kernel.mod), so that the heap and stack allocators can easily share each other's data about the top of the heap, and the bottom of all the stacks, respectively, for overflow checking. Hence, my code will not even use/import module storage, or so is the plan.

I have implemented a first proof of concept, and my implementation with combining both allocators in module Kernel appears to work, without ever referring to module Storage, which is not linked. But the above cited statement about Storage makes me wonder if there are any dependencies and issues due to how the compiler works, so I'd run into problems down the road.

[cfbsoftware]

That is a documentation error that we will fix - thank you for pointing it out. The restriction only applies to the MAU module (as documented there) not the Storage module.