Placement of code and data in FastRam

[VladR]

While working on my RTG benchmark, I want to dedicate one of the tests to differences between ChipRam and FastRam.

I'm using vasm and hunkexe format, so it should be a relocatable format (no .ORG or absolute memory addresses anywhere).

When I printed the addresses of the first/last line of code and data at run-time, I noticed that they are all in FastRAM (unless I change the attribute in the SECTION to use chipram) - well based on the range that SysInfo gives me under WinUAE.

Is that guaranteed, though ? I am not using AllocMem and all my data is compile-time allocated (for now). It would be of great benefit if I didn't have to refactor the code to use AllocMem and both code/data would be guaranteed to be placed in FastRAM.

I do not intend to run it below 040 initially, and some time in the future, I might try to make it run on slowest RTG config (A1200, I suspect) - but for now, let's say 040.

[a/b]

Segment loader is allocating public memory (unless a hunk is tagged to use something else), so as long as fastmem has higher priority over chipmem you'll get fastmem if a hunk fits.

[VladR]

Originally Posted by a/b

Segment loader is allocating public memory (unless a hunk is tagged to use something else), so as long as fastmem has higher priority over chipmem you'll get fastmem if a hunk fits.

Does that mean, if I suddenly started using a single giant array which would then cause the segment to not fit into a single available block, then the OS would downgrade to non-fastmem (assuming lower-class RAM would fit it)?

And what exactly is that kind of RAM anyway ? If it's not chipset, what other is there ? The trapdoor local expansion one perhaps ?

Is there a difference between FastRAM on the expansion card (say, with 128 MB RAM) and FastRAM in the motherboard ?

[a/b]

Yeah, if you run out of fastmem while asking for public mem, you will get chipmem.
Each part of the memory pool has a priority, and allocation works down the list. So, fast with several priority levels (Z3, Z2, ..., that should answer your last question) > slow/ranger > chip.

[VladR]

Thanks, that's great to hear. I presume this order of allocation should be documented somewhere in the OS/library docs...

So, technically, looks like I can get away with not refactoring the code to use AllocMem, as static allocation will work just fine and get me a FastRAM for both code+data and FrameBuffer (which is what I need).

I guess I can always just print out the address range used for code+data/framebuffer and this way the user will know exactly (for his particular system), what kind of RAM has been given to the executable by the OS. This should take care of all the "why did it run slower this time?" questions - the answers will be given to the user on the first screen of the program.

[Thomas Richter]

Originally Posted by VladR

Thanks, that's great to hear. I presume this order of allocation should be documented somewhere in the OS/library docs...

How AllocMem works is documented in the RKRM libraries, how the dos.library scatter loader aka LoadSeg() works is documented in the RKRM DOS.

Originally Posted by VladR

I guess I can always just print out the address range used for code+data/framebuffer and this way the user will know exactly (for his particular system), what kind of RAM has been given to the executable by the OS.

The type of memory you get with TypeOfMem(), which is a function of exec. That provides you the memory attributes (or 0) a specific memory location has. Thus, if you requested MEMF_PUBLIC, but the system run out of fast memory, TypeOfMem() will give you MEMF_PUBLIC|MEMF_CHIP as result.

[paraj]

Yes, it is documented (http://amigadev.elowar.com/read/ADCD.../node02A6.html). Static allocation will work just fine, and in practice you don't have to worry about fast buffers being demoted to chip ram. That will really only happen on very low spec systems, and the user will be used to it.
You can also force your segments to be in fast ram, but there are only downsides to this. Just use TypeOfMem and print a warning if you really need to.

Most accelerator cards will just have a comparatively large amount of fast ram where you program will always fit. The priority case only comes up in niche situations (like this awesome thing: https://eab.abime.net/showthread.php?t=115241&nojs=1)

[VladR]

Originally Posted by Thomas Richter

How AllocMem works is documented in the RKRM libraries, how the dos.library scatter loader aka LoadSeg() works is documented in the RKRM DOS.



The type of memory you get with TypeOfMem(), which is a function of exec. That provides you the memory attributes (or 0) a specific memory location has. Thus, if you requested MEMF_PUBLIC, but the system run out of fast memory, TypeOfMem() will give you MEMF_PUBLIC|MEMF_CHIP as result.

Thanks, I just checked out TypeOfMem, and it's exactly what I was looking for!

I also need to redownload the Amiga docs, as I couldn't find them in my Amiga Dev directory (it probably didn't make it to the new computer - I hate this part - you always forget some directories from old HDD).

[VladR]

Originally Posted by paraj

Yes, it is documented (http://amigadev.elowar.com/read/ADCD.../node02A6.html). Static allocation will work just fine, and in practice you don't have to worry about fast buffers being demoted to chip ram. That will really only happen on very low spec systems, and the user will be used to it.

Right, since I require RTG, I kinda bypassed all the low-spec systems anyway. For once there is some advantage to not dealing with OCS/ECS

Originally Posted by paraj

You can also force your segments to be in fast ram, but there are only downsides to this. Just use TypeOfMem and print a warning if you really need to.

What exactly do you mean by forcing ? At compile-time via SECTION directive ? Because that's what I use for data now.

Originally Posted by paraj

Most accelerator cards will just have a comparatively large amount of fast ram where you program will always fit. The priority case only comes up in niche situations (like this awesome thing: https://eab.abime.net/showthread.php?t=115241&nojs=1)

My current code size is 60 KB. Data is around 250 KB. Framebuffers, though, take a lot.

But still, comfortably, under 4 MB total - which shouldn't be a big deal for any low-spec RTG system, right ?.

[Thomas Richter]

Originally Posted by VladR

But still, comfortably, under 4 MB total - which shouldn't be a big deal for any low-spec RTG system, right ?.

No, that shouldn't be a big deal.

[paraj]

Originally Posted by VladR

Right, since I require RTG, I kinda bypassed all the low-spec systems anyway. For once there is some advantage to not dealing with OCS/ECS

If you run out of fast mem your normal buffers will still be demoted to chipmem, but no big deal.

Originally Posted by VladR

What exactly do you mean by forcing ? At compile-time via SECTION directive ? Because that's what I use for data now.

Yes, exactly, like having "data_f" sections. I.e. sections where you require fast ram. IMO there is not reason to do that. You will just be preventing potentially useful benchmarking/marginal systems from running for no good reason.

Originally Posted by VladR

My current code size is 60 KB. Data is around 250 KB. Framebuffers, though, take a lot.

But still, comfortably, under 4 MB total - which shouldn't be a big deal for any low-spec RTG system, right ?.

Totally fine, and on RTG systems I guess framebuffers will mostly(?) always not take up any fast ram (i.e. be buffers allocated on the graphics device).