Memory theoretics

Erik Friesen

I have had something circling around in my thoughts.

Once an assembly program is loaded from ram is there a way to use the hub memory in that location?

Or do I misunderstand something here?· Or is it still used somehow?

Cluso99

As long as you don't want to load the same object(s) later, there is no reason why you cannot use that space. In fact, it is an excellent idea

Be careful not to corrupt the chain of addresses of variables and objects. i.e. Just use the actual code space, not the pointers. (Hope you understand what I mean here as it isn't very clear, but not sure how to express it better.)

BradC

Yeah, once a cog is running you can do what you like with the underlying ram.

My bootloader loads 2 cogs which use $7FE0 to $7FFF to communicate. It then completely zeros ram from $0000 to $7FD9 and everything keeps on chugging along perfectly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

Mike Green

Basically, if you leave any cogs running the Spin interpreter, you have to be careful because there are tables and pieces of code scattered around in memory, not to mention the stack ... whatever space is needed for that. If all of the active cogs are running your own assembly code, you can do whatever you want with memory. That's what FemtoBasic does when it executes the SPIN statement. The Spin code locates the new program to be executed, whether in EEPROM or on an SD card, then the loader, which is in assembly and running in its own cog, stops all other cogs including the FemtoBasic interpreter, loads the new program into hub ram, and starts up a new Spin interpreter in an available cog.

RossH

Hi,

If you want another example, see the source code of SpaceWar! (VGA Version 3.2) in the Hydra forum. I re-use the RAM used to hold all the drivers (keyboard, VGA, sound etc) once they have been loaded into the cogs. It's easy to do with any existing driver and gives you a huge boost in the RAM available to your program at run time.

Ross.

Phil Pilgrim (PhiPi)

Just be careful how much of that space you use! Even though a COGNEW loads 2K bytes, that doesn't mean 2K bytes are then available for you to trample at will. That 2K bytes will likely include chunks of the following code as well, loaded into cog memory as unused, trailing garbage, but needed when that code is used elsewhere. It's generally safe to use the space occupied by the opcodes, BYTEs, WORDs, and LONGs of a cog routine, but not RESes (since they don't occupy any hub memory). And even this is true only so long as that data is not referenced elsewhere.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Erik Friesen

Ok but my understanding would be that if the program assembles at lets say 250 longs of assembly you would be safe to use 225? I am not sure how One goes about dviding between the spin and assembly portion though.

Does an @entry properly pass the beginning address?

BradC

If a DAT section is 250 longs and you go over that you will start to overwrite the first spin method of the object. A Bad idea..

@entry (provided that is the first symbol of the dat area) provides the starting address for that dat area in that object, yes..

You could define
datstart ' at the start of the area
datend' ' at the end of the area and
datsize = @datend - @datstart ' to get the overall length you have to play with.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!