A technical question about RAM usage

SamMishal

If a top level object calls multiple instances of a sublevel object in separate cogs I understand that the
only penalty is stack space and a few management bytes. That is there is no multiple copies of the object’s code.
However, consider this scenario:
1-Top level starts a cog with the FullDuplexSerial object
2- Top level starts another cog with another object say AA
3- Object AA in the new cog starts another cog with the FullDuplexSerial
The question is….is the code of the second instance of the FullDuplexSerial going to be duplicated in RAM or
is the old instance’s code used again??
I know I can probably try this out and look at the memory map and try to figure out where
things are....but I am lazy and I am hoping someone can help me ...Please!
Sam

stevenmess2004

SamMishal said...
The question is….is the code of the second instance of the FullDuplexSerial going to be duplicated in RAM or
is the old instance’s code used again??

Removing duplicate objects is one of the very last steps in the compile stage so there will only be one copy of the object PUB, PRI and DAT sections. However, there will be separate copies of the VAR section for each instance of the object. For instance if I had something like this
Main
|--FullDuplexSerial
|--SomeObject
|-FullDuplexSerial

Then the PUB, PRI and DAT sections for FullDuplexSerial will get included once and the VAR section will get included twice.

Hope that helps.

evanh

My understanding is the code is processed inside of each cog. Each cog's management of the instance can be considered an internal, and temporary, code duplication for each instance. This is not using hub ram though.

So, the answer is no, there is no duplication of code for each instance, concurrent or not. As mentioned by Steven, only the dynamic data is duplicated.

MagIO2

I'm not sure, but maybe there is a chance of code duplication if your folder structure contains more than one version of the FullDuplexSerial (or whatever object). Maybe I'll check that this evening.

Folder Parallax
   File FullDuplexSerial
   File UserOf_FDS
   Folder Project 1
     File FullDuplexSerial
     File User2Of_FDS
     Folder Project 1 Main
       File User3Of_FDS
     

Say User3Of_FDS is the main program, which uses User2Of_FDS and UserOf_FDS. Eeach of those runs an instance of FullDuplexSerial, so we have 3 Serial interfaces running.

During compile the PropTool searches upward in the folder structure. So, for User2Of_FDS which uses FullDuplexSerial it immediately finds a version in the same folder. User3Of_FDS finds the same one, as it's the closest version it can find. UserOf_FDS·is in the top level folder and will find the FullDuplexSerial there. I don't think, that the compiler really checks whether the two FullDuplexSerial versions are the same or not.

Mike Green

The checking for duplication is done on the compiled code for the object. It has nothing (as far as I know) to do with the folder where the object is kept. You can even have two different source copies of an object. If they compile to the identical code, only one copy is put into the final binary program.

stevenmess2004

Mike Green said...
The checking for duplication is done on the compiled code for the object. It has nothing (as far as I know) to do with the folder where the object is kept. You can even have two different source copies of an object. If they compile to the identical code, only one copy is put into the final binary program.

That is correct. Even if they have the same name but generate the same compiled code there will only be one copy of the two objects. For example

'top object
OBJ
 obj1:"file1"
 obj2:"file2"
PUB start

'file1.spin
VAR
long var1
word var2

PUB methoda
 return var1
PUB methodb
 return var2
DAT
abc long 1

'file2.spin
VAR
long var3
word var4

PUB methodc
 return var3
PUB methodd
 return var4
DAT
abc long 1

Here file1.spin and file2.spin will generate the same spin bytecode and only one copy of the PUB, DAT and PRI sections will be included in the binary. Depending on what you are doing this may or may not be useful. Mostly it's useful because it stops you wasting space. However, occasionally you may actually want the DAT sections to be different. To do that all you need to do is change the value of the abc variable and then both copies will be included and you'll have two different DAT sections.

stevenmess2004

evanh said...
My understanding is the code is processed inside of each cog. Each cog's management of the instance can be considered an internal, and temporary, code duplication for each instance. This is not using hub ram though.

Yes and no. All processing happens in the cog memory. However, hub ram is used for the stack to store temporary variables and intermediate values of calculations. Also, there is only one copy of the DAT variables for each object even if there are multiple instances of it. So DAT variables are global to all instances of an object and VAR variables are local to a particular instance.

evanh

I was just answering the explicit question of runtime loading of code to each cog. I think Sam was concerned that this consumed extra hub space when running concurrent instances.