Warning - BST don't warn if you use labels from another DAT section!!!
pik33
Posts: 2,397
... and I wasted some hours to find it...
It should generate a compile error - or warning - unresolved "linenum" symbol in second DAT section.
Instead it compiled it and then.... my program started to behave very strange... didn't know, why until I found this bug.
I don't know if Propeller Tool do the same, but warning: you have to check twice if you don't use symbols from one pasm section in another one...
dat
(some pasm code)
linenum long 0
dat
(some pasm code for another cog)
mov linenum, #0
(rest of code)
It should generate a compile error - or warning - unresolved "linenum" symbol in second DAT section.
Instead it compiled it and then.... my program started to behave very strange... didn't know, why until I found this bug.
I don't know if Propeller Tool do the same, but warning: you have to check twice if you don't use symbols from one pasm section in another one...
Comments
The compiler knows nothing of your intention that different DAT sections may be run in a different cogs.
Try compiling an object with multiple interspersed DAT and PUB sections with the listing option switched on. You will see in the listing that all the DAT code gets placed into a single DAT area for the object in RAM.
You can have multiple DAT sections in a Spin object source file. They will be assembled and concatenated into a single DAT area in RAM for that object. So the end result is the same as if you had put them in a single DAT section.
Let's take this as an example:
PUB junk moreJunk DAT label_1 long 1 label_2 long 2 label_3 long 3 PUB moreJunk evenMoreJunk repeat DAT mov label_1, label_2 PUB evenMoreJunk repeat DAT mov label_2, label_1 jmp #label_3Let's compile that and see what is in the listing file:
Here we see all DAT sections pulled together into a single area of RAM space, under "Object DAT Blocks". Everything is just fine.
As I said, the complier has no idea that you are going to launch different parts of that DAT blob into different COGs. It just compiles it into a single runnable thing.
Now, iy you are wanting multiple DAT blocks to be run in different cogs I would sugget:
1) Put them into different source files. You will have a lot less trouble with such label naming mix ups that way.
2) or besure to put "ORG 0" statements at the beginning of each DAT block that is to be run separately in different cogs. That way the linker can do it's thing properly. Each cogs section will be compiled to be run from offset zero in a cog rather than whatever would normally come next.
3) For completeness use FIT at the end of a cogs piece of code.
I discovered earlier that labels have to be unique in all piece of .spin file, but I thought it should generate an error, when it finds a label before this org 0 - in previous cog's code.
How did you generate this listing in second code block?
Thing is "org 0" does not say "this a new piece of PASM that will be run in a different cog" it only specifies the location in cog where this code will be loaded to and run from. It is required when for example you have multiple bits of code in a source file that will be loaded to different cogs. Or less obviously when you have code that may get moved around in COG or loaded into a specific address in COG.
For example in earlier versions of my Z80 emulator I used code overlays in order to be able to write everything in PASM and run it in a single COG. Those overlays were loaded by the emulator when required to a specific address in COG. So that address had to be specified at the start of each overlay section. (Later versions of the emulator use LMM instead).
-Phil
What? Most assemblers I have used took care of label scoping/name spaces by having you put code into different source files. As does the C language. Given that Spin is not designed for programming "in the large" I would not expect it to have such a feature.
.. but it was declared in another piece of PASM code.
This caused very strange program behaviour: in 99% cases it worked, because (maybe) this place in second cog's ram, at which this variable pointed, ( I have to recreate this error and make a listing to know, what the heck the compiler did with this label) was unused. Then, after adding some lines of code, it started to display garbage on the screen, or even it resets a Propeller. This was all random and very hard to find.
Compiler should warn, as it is doing when write djnz without a #.
"Warning - label xxx points to another dat block"
I had to make labels for second cog like "linenum2"... etc - it is very -- very --- easy to make a mistake.. Such warning wil be very useful if added to new version of compiler.
-Phil
"linenum" was at $9D in the first cog.
In the second cog, the same $D9 value was used as destination in MOV code.
-Phil