Bug in Spin compiler
MagIO2
Posts: 2,243
Maybe it's already reported, but it's worth to be mentioned again and again for all the newbies:
The datatype of a label is not set to the datatype that comes after the label, but to the one before the label. As the label itself points to the data after the label, I'd consider this as being a BUG.
Example:
This currently works fine and as I'd expect it to work. But only because the workaround is already in place:
Remove the first word of the dat section and it will no longer do what's expected.
Reason:
Default type of a dat section seems to be byte. Now all accesses to initSeq are treated like a byte-array access.
Post Edited (MagIO2) : 11/29/2009 7:22:12 PM GMT
The datatype of a label is not set to the datatype that comes after the label, but to the one before the label. As the label itself points to the data after the label, I'd consider this as being a BUG.
Example:
dat
word $0000
initSeq
word $000c, $0005, $0005, $0005, $0002, $0001, $0028, $0000
initData
word $0000, $0100
word $0100, $0000
word $0200, $0107
word $0300, $20C0
word $0400, $0000
word $0800, $0702
word $0900, $0000
word $0a00, $0000
word $0c00, $0000
word $0d00, $0000
word $0f00, $0000
word $0700, $0101
word $1000, $B010
word $1100, $0700
word $0700, $0100
word $1200, $3B01
word $1300, $000B
word $2900, $1200
word $2A00, $9500
word $3000, $0a00
word $3100, $2613
word $3200, $290A
word $3300, $0A29
word $3400, $1326
word $3500, $0A0A
word $3600, $031E
word $3700, $1E03
word $3800, $0607
word $3900, $0303
word $3A00, $040E
word $3B00, $010E
word $3C00, $0E01
word $3D00, $0E04
word $3E00, $0303
word $3F00, $0706
word $5000, $0000
word $5100, $EF00
word $5200, $0000
word $5300, $3F01
word $6000, $0027
word $6100, $0300
word $6A00, $0000
word $8000, $0000
word $8100, $0000
word $8200, $0000
word $8300, $0000
word $8400, $0000
word $8500, $0000
word $9000, $1300
word $9200, $0000
word $9300, $0301
word $9500, $1001
word $9700, $0000
word $9800, $0000
word $f000, $0854
word $f300, $1000
word $f400, $1100
word $f000, $0000
word $0700, $7301
pub Init | ptr1, ptr2, cont
ptr1:=0
ptr2:=0
cont:=1
repeat while cont==1
tv.str( string("SeqNum: ") )
tv.dec( initSeq[noparse][[/noparse] ptr1 ] )
tv.out( $0d )
repeat initSeq[noparse][[/noparse] ptr1 ]
tv.str( string( "CMD: " ))
tv.hex( initData[noparse][[/noparse] ptr2 ], 4)
' cmd( initData[noparse][[/noparse] ptr2++ ] )
tv.str( string( " DATA: "))
tv.hex( initData[noparse][[/noparse] ptr2 ], 4)
tv.out( $0d )
' data( initData[noparse][[/noparse] ptr2++ ] )
ptr1++
if initSeq[noparse][[/noparse] ptr1 ] == 0
tv.str( string("End",$0d ))
cont:=0
else
tv.str( string("SeqWait: ") )
tv.dec( initSeq[noparse][[/noparse] ptr1 ] )
tv.out( $0d )
tv.str( string( "Waiting",$0d ))
waitcnt(clkfreq/initSeq[noparse][[/noparse] ptr1 ] + cnt)
ptr1++
This currently works fine and as I'd expect it to work. But only because the workaround is already in place:
Remove the first word of the dat section and it will no longer do what's expected.
Reason:
Default type of a dat section seems to be byte. Now all accesses to initSeq are treated like a byte-array access.
Post Edited (MagIO2) : 11/29/2009 7:22:12 PM GMT
Comments
or
If the declaration is on the same line as the symbol, it's all good. If not then the symbol gets the last alignment (which defaults to byte in a DAT section)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
If you want to specify the alignment, just do like BradC suggests, and put it on the same line, right beside your label...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
With a label you reference the data comeing after the label, so the type should match that datatype of exactly this data and not the datatype that was valid before the label. But as I learned it is a minor bug with an easy workaround. But you have to be aware that it exists.
I had to add debug-code to my module to find it because I was not aware of the problem - which cost some minutes. I guess some newbies will have a big headache when running in such a bug ;o)