Annoying PropTool 1.2 Bug/Feature

Comments

• Mike Green Posts: 23,101

  2008-09-01 18:20 edited 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) Posts: 23,514

  2008-09-01 18:29 edited 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 Posts: 1,981

  2008-09-01 20:32 edited 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) Posts: 23,514

  2008-09-01 22:16 edited 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 Posts: 1,981

  2008-09-01 23:21 edited 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