Loading several cogs from one SPIN file
FMMT666
Posts: 14
It has been quite a while since I used the Propeller and I am pretty sure
this question has already been answered a thousand times, but I did not
manage to find a clear answer for that one:
What exactly happens if I load more than one cog from only one SPIN file?
Like this:
Are all of the "variables" appended to the second DAT section?
If yes, at what address do they go, are they appended to the end of the
section or do they use absolute addresses (which would result in overwriting code)?
From and to what address is "BLABLA" written to?
What happens if I use the "FIT" directive between these DAT secions?
Is it able to detect an overflow?
Are there any other pitfalls related to this structure?
Anything else I should know or should take care of?
D*mn, and I thought I already mastered the Propeller ;-)
Axel
this question has already been answered a thousand times, but I did not
manage to find a clear answer for that one:
What exactly happens if I load more than one cog from only one SPIN file?
Like this:
PUB Start cognew( @one, 0 ) cognew( @two, 0 ) DAT org 0 one jmp #one BLABLA long $12345678 var1 long 1 var2 long 2 var3 long 3 var4 res 1 DAT org 0 two mov var4, BLABLA three jmp #three
Are all of the "variables" appended to the second DAT section?
If yes, at what address do they go, are they appended to the end of the
section or do they use absolute addresses (which would result in overwriting code)?
From and to what address is "BLABLA" written to?
What happens if I use the "FIT" directive between these DAT secions?
Is it able to detect an overflow?
Are there any other pitfalls related to this structure?
Anything else I should know or should take care of?
D*mn, and I thought I already mastered the Propeller ;-)
Axel
Comments
First, yes you can launch two cogs this way from one spin file.
The cognew command just copies 512 longs from RAM to the cog without looking at what's there, so yes your "two" data will be in your "one" cog.
Exception is that "res" doesn't actually have a HUB spot, it's just a reserved placeholder.
not completely sure about BLABLA. I think the assembler will just try tu use that long value there, which should give a compile error, I think...
Two Fit commands should work fine. I think it's all relative to the previous org 0.
The tricky part is to understand what the compiler is doing!
DAT, RES, ORG and FIT are compiler-statements which for example effect the compiler-internal label & address handling (RES & ORG).
You have to understand that there are 2 address-counters, one for the HUB-RAM addresses and one for the COG-RAM addresses and each label inside of a DAT-section has 2 addresses: 1. the HUB-RAM address and 2. the COG-RAM address!
HUB-RAM addresses are used in SPIN-instructions, COG-RAM addresses are used in PASM code.
Per Default, when starting a DAT section with the ORG 0 Statement, you tell the compiler that all labels used int the following code are relative to this ORG in terms of COG-RAM addresses . So, in your example one has whatever address in HUB-RAM, but it has address 0 in COG-RAM. BLABLA has address 1 in COG-RAM ...
The idea behind RES is to allow having labels without occupying memory in HUB-RAM. So, these labels are local for the COG which also includes that you have to initialize these variables before using. After the first RES statement you loose sync with the HUB-RAM (COG address-counter is increased, but HUB-address Counter is NOT increased), that's why RES have to be at the end of your PASM code.
In function two you have a problem, because cognew will start copying exactly starting from two, so there is NO BLABLA in this COG-RAM.
Normally with FIT you specify the COG-RAM size. FIT is a check that the PASM / data between an ORG and that FIT do not exceed the given COG-RAM address-space. So, it's only purpose is to give you a warning in case your PASM/data-section grows too big.