PropTool Compiler Bugs
hippy
Posts: 1,981
Propeller Tool 1.05.08
Works fine for any FINAL < $1F0, fails for FINAL == $1F0. Mouse click on REGISTERS_END shows Cog Address as expected when < $1F0, at $1F0 it shows N/A, and trying to use "FIT REGISTERS_END" gives an "Address out of range" error.
===========
ORG $1F0 is accepted but ORG $1F1 isn't. Either both should be accepted or both rejected.
===========
I personally cannot see any reason why a Cog Address Label shouldn't be allowed a value greater than $1EF.
CON FINAL = $1E0 DAT REGISTERS long 0[noparse][[/noparse] FINAL-$ ] REGISTERS_END
Works fine for any FINAL < $1F0, fails for FINAL == $1F0. Mouse click on REGISTERS_END shows Cog Address as expected when < $1F0, at $1F0 it shows N/A, and trying to use "FIT REGISTERS_END" gives an "Address out of range" error.
===========
ORG $1F0 is accepted but ORG $1F1 isn't. Either both should be accepted or both rejected.
===========
I personally cannot see any reason why a Cog Address Label shouldn't be allowed a value greater than $1EF.
Comments
This is over my head! What in the world are you trying to do?
In fact both are useless. But is does no harm...
You cannot allocate ANYTHING at or above $1F0 in the COG; if you need reference to an address >= $1F0 you can use the CON section. I agree it could be nice to say:
Post Edited (deSilva) : 12/26/2007 2:27:25 AM GMT
CON FINAL = $1F0 PUB Main DAT REGISTERS long 0[noparse][[/noparse] FINAL-$ ] REGISTERS_END fit REGISTERS_ENDTake the 'fit' out to see the N/A Cog Address for REGISTERS_END.
It's fair enough to not be able to allocate above $1EF, but I don't see why a label can't have any value. This bit me because the code was working, then I decided to relocate it to the end of Cog and the compiler objected. I can change it, but if I move it again I need to change it again.
DAT REGISTERS long 0[noparse][[/noparse] $1f00 ] REGISTERS_END fit REGISTERS_ENDI think this a good error message...
(b) what do you mean by "relocate to the end of COG"? So you want to have something as I gave in my example above?
I think this will be not a good idea...
Yes, that's the problem
If I replace "fit REGISTERS_END" with "fit $1F0" it works, and "org REGISTERS_END-1" is in range, if the compiler had assigned $1F0 to the label. The root issue is the compiler marking the label at $1F0 as invalid rather than checking for the validity of org/fit addresses when evaluated.
Yes, but the resultant org would be in range, below $1F0.
An similar situation as with ...
ADDRESS EQU $+$12345678 ORG ADDRESS-$12345678 myVar long 0Post Edited (hippy) : 12/26/2007 11:00:41 AM GMT
DAT org $000 :Loop call #MySub1 call #MySub2 jmp #:Loop ' =================================== REGISTERS long 0[noparse][[/noparse] 16 ] REGISTERS_END ' =================================== MySub1 mov :a,:count jmp #:Return :org org REGISTERS :a res 1 :count res 1 fit REGISTERS_END org :org :Return MySub1_Ret ret ' =================================== MySub2 mov :a,:increment jmp #:Return :org org REGISTERS :a res 1 :increment res 1 fit REGISTERS_END org :org :Return MySub2_Ret retNow if I make MySub1 and MySub2 overlays it also works, but if the Overlay or other routines grows such that RESISTERS_END falls on $1F0, although the program is still valid, it cannot get through compilation ...
DAT org $000 :Loop call #Overlay long MySub1 call #Overlay long MySub2 jmp #:Loop ' =================================== Overlay mov ovlPtr,Overlay_Ret ' : long 0[noparse][[/noparse] 215 ] ' : Overlay_Ret ret ovlPtr long 0 ' =================================== OVERLAY_START long 0[noparse][[/noparse] 256 ] OVERLAY_END ' =================================== REGISTERS long 0[noparse][[/noparse] 16 ] REGISTERS_END ' =================================== org OVERLAY_START MySub1 mov :a,:count jmp #:Return :org org REGISTERS :a res 1 :count res 1 fit REGISTERS_END org :org :Return MySub1_Ret ret fit OVERLAY_END ' =================================== org OVERLAY_START MySub2 mov :a,:increment jmp #:Return :org org REGISTERS :a res 1 :increment res 1 fit REGISTERS_END org :org :Return MySub2_Ret ret fit OVERLAY_ENDThe 'long 0[noparse][[/noparse] 215 ]' would in reality be executable instructions. Note REGISTER_ENDS is at $1EF. Change that to 'long 0[noparse][[/noparse] 216 ]' and the compiler errors.
To my understanding the PropellerTools tries to help you as much as it can to not overcrowd the COG.
It has not so many clues for that as it will rarely know if it's a HUB data allocation or a COG allocation you are designing.
The tool takes three chances:
(1) When asked to check the actual COG address counter against a specific value using FIT
What you encountered was the situation
FIT N/A
leading to the error message.
The label REGISTERS_END is outside the allowed region of COG memory allocation, and is thus assigned N/A rather than $1f1. It is of little concern that you do not allocate things to it... It has be be $1f1 ... and that would be not good...
This makes terribly much sense to me.
(2) When allocating memory by RES n. It is hard checked that the last reserved word fits into $1f0
(3) When a label is used within an instruction which is N/A, i.e. COG address =>$1f0. I can imaging that this check was the main rational for introducing N/A in the first place
I always wondered why it does not check the allocation of instructions above $1ef as such; e.g. is is perfectly valid to write
Edit: A work around?
What about
rather than
Post Edited (deSilva) : 12/26/2007 12:27:25 PM GMT
On one hand, perhaps, but then on the other it is often entirely lax and allows the programmer to do what they want without care as to right and wrong. I suppose I'm in the minority here, complaining about the PropTool not allowing me to do something given the number of 'mistake's people have complained of which the PropTool lets through without flagging an error.
MANY THANKS : "fit LAST_REGISTER+1" works in all cases.