Expletives withheld
mirror
Posts: 322
Searching for a bug through 600 lines of assembly...
My project uses all 8 cogs, of which 7 are assembly.
Two of the assembly cogs are in the same spin file - they consist of a low level (high speed) scanning cog, and a higher level (lower speed) processing cog. The cogs share various resources, which is why they're grouped.
There was just simply some instability in the algorithm·that I could not make sense of, but I finally tracked down the cause. It is essentially as follows:
The location being written to by the reference to varA in the second cog·is the same offset into the second cog as varA is offset into the first cog.
So you think you're writing a variable ... BUT you're not ... you're modifying your own code.
No warnings from the compiler about the incestuous relationship between the two DAT sections. I know it's an error! It's obvious once you find such a thing that it's an error!
What a waste of a day.
·
My project uses all 8 cogs, of which 7 are assembly.
Two of the assembly cogs are in the same spin file - they consist of a low level (high speed) scanning cog, and a higher level (lower speed) processing cog. The cogs share various resources, which is why they're grouped.
There was just simply some instability in the algorithm·that I could not make sense of, but I finally tracked down the cause. It is essentially as follows:
DAT
'code for cog 1 - about 30 lines
'including references to varA
varA long 0
DAT
'code for cog 2 - about 600 lines
'including a reference to varA <- NOT GOOD.
The location being written to by the reference to varA in the second cog·is the same offset into the second cog as varA is offset into the first cog.
So you think you're writing a variable ... BUT you're not ... you're modifying your own code.
No warnings from the compiler about the incestuous relationship between the two DAT sections. I know it's an error! It's obvious once you find such a thing that it's an error!
What a waste of a day.
·
Comments
I guess you know now, but you have to have vars / dat in hubram and have pointers in cogram and wrlong/wrword/wrbyte rdlong/rdword/rdbyte them for you to have intercog communication.
Baggers.
Baggers, I'll bet it was just a standard working register name for Mirror, not meant for cog to cog use.
is another one. The reason is mainly a typo, rarely a misunderstanding: "Oh, I thought a byte could hold 500 values. Oh, I thought I could address into another COG."
It's a simple bug/typo as difficult to catch as any any other bug or typo in your program. So no need to get excited about
Wrong guess:
The smoketest was done. The original had a short fast assembly section (about 1_000_000 iterations per second), and I thought that the longer slower processing would be OK in spin. Unfortunately I missed by about a factor of 3. I used several FIFO's,·did a pile of clock counting and optimisation to get the spin faster, but just couldn't get it over the line. The "slow" process needs to execute about 15000 times a second (under maximum load), but may only need to execute 1000·times a second under light load. The quickest I got was about 6000 iterations.
Correct guess:
The fast assembly section had the following bit of code:
In the midst of the conversion process (spin to pasm), I realised again that I needed to clear and set the carry flag, so copied the code across from one DAT section to the other.
The rest, as they say, is history . . .
Now the reality of life is that the conversion of the code took a whole day - due to the quantity and complexity. Testing was started on day 2. The lines in question were copied across at some fuzzy point in the·middle of the day.
Without warnings, we often·fly blind.
I've seen the frustrations expressed as others on this forum debate whether to write their code as one large spin file - beware, that path also has traps!
·
Remember, you are a genius, so things can't be all bad.
At moments like these one is tempted to blame someone for not doing something that would make our lives easier.
Let's blame deSilva[noparse]:)[/noparse] He could easily write a parser that looks for stuff like this and spits out clean Spin/Assembly.
Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?