Annoying PropTool 1.2 Bug/Feature

hippy · 2008-09-01 17:50

This fails to compile ...

PUB GetVar1Address | a1, a2
  a1 := @var1
  a2 := @var2

DAT   org  $000
var1  res  1
var2  res  1

This works ...

PUB GetVar1Address
  a1 := @var1
  a2 := @var2

DAT   org  $000
var1  
      res  1
var2
      res  1

Obviously there is a workround but it's not aesthetically pleasing.

Added : Dang ! @var1 and @var2 are given the same value

Post Edited (hippy) : 9/1/2008 8:25:34 PM GMT

Mike Green · 2008-09-01 18:20

Both forms really don't mean anything because RES is an assembly-only construct. It doesn't really occupy any hub memory as far as the compiler is concerned, but does occupy a location in cog memory. Nonetheless, it makes sense to have it treated as you expected because there are some situations where (like in an LMM context) you might want to use such addresses in Spin or other assembly. The "@" in Spin code is supposed to produce a hub address (which doesn't exist in this case). There ought to be a second mechanism to produce a cog relative address since the assembler does have that.

Post Edited (Mike Green) : 9/1/2008 6:25:28 PM GMT

Phil Pilgrim (PhiPi) · 2008-09-01 18:29

Your first one doesn't compile because test is a reserved word. Also, since res reserves addresses only in the cog, not the hub, you have to use long to reserve hub space for var1 and var2.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

hippy · 2008-09-01 20:32

@ Phil : Sorry that was a transcription error - corrected in first post. The thing is though that 'var1' has a value in both cases ( as a hub address and as a cog address ) so there's no logical reason why putting it on the same line as 'res' should cause a problem. That @var1==@var2 is a separate issue.

The behaviour makes some sense in so far that @var1 and @var2 will be correct hub addresses for something like this ...


var1  long 123
      res   10
var2  long 456

IMO, @label should give the hub address the cog location was loaded from, or would have been loaded from.

It would also be useful to have @$label to get the cog location ( "$" being the 'current cog location counter ) which as Mike notes is missing.

Phil Pilgrim (PhiPi) · 2008-09-01 22:16

Hippy,

Your first example would make sense, assuming @var1 == @var2 == 0. I can see the logic of flagging it as an error, though, since a beginner might erroneously expect the RES to reserve space in cog memory. I like the @$label idea and can see where it would come in handy. Not even the following would give the desired result in the present framework (the error notwithstanding):

   ...
   x := @label1 - @origin
   ...

DAT

origin  ORG     0
        ...
label0  RES     1
label1  RES     1

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

hippy · 2008-09-01 23:21

I tried everything but got nowhere so took a different tack. This is for using variables overlaid onto initialisation code to save cog space. No problems with the overlaying, but when it came to using the debugging code to peek named variables it all fell to pieces.

The code I now have is ..

OVERLAY         

GetArg          mov     $1F7,GetArg_Ret
                sub     $1F7,#1
                movd    :PtrGet,$1F7
                mov     $1F7,PAR
:PtrInc         add     $1F7,#0
:PtrGet         rdlong  0-0,$1F7
                add     :PtrInc,#4
GetArg_Ret      ret

OVERLAY_END

                org     OVERLAY

opc             res     1
lhs             res     1
rhs             res     1

OVERLAY_opc     word    opc
OVERLAY_lhs     word    lhs
OVERLAY_rhs     word    rhs

Whereas I was using "cogAddress = ( @label - @PASM_BASE ) >> 2" I'm now using "@OVERLAY_label" when needed and -

PRI GetCogAddress( atCogLabel )
  if atCogLabel => @OVERLAY_END
    return word[noparse][[/noparse] atCogLabel ]
  else
    return ( atCogLabel - @PASM_BASE) >> 2

Annoying PropTool 1.2 Bug/Feature

Comments