Why is using ina as a destination register not flagged as a compiler error?

epmoyer · 2007-08-24 19:52

If you read the Propeller manual carefully (and it's easy to miss) you'll find that ina cannot be used as a destination register in assembly language. That sounds kind of obvious, but consider the instruction:

test ina, MY_BITMASK wc

(which I'm guessing the assembler actually turns into the synonymous "and ina, MY_BITMASK wc,nr")

even though ina is used as a destination register neither of those instructions actually attempt to write ina, and both appear to be perfectly plausible. I haven't tested the "and", but I found that the "test" instruction compiles fine, but does not execute as desired. I beat my head against the wall for almost an hour on this one before I realized my mistake. Once you understand the restriction on ina you can just use "test MY_BITMASK, ina wc" instead (which is equivalent), but I can't help but feel the compiler should have warned me about this one.

deSilva · 2007-08-24 20:10

Yes, that would have been nice

I must remember to include it in the tutorial. It will affect
ina
inb
cnt
phsa
phsb

The matter is not so much that it is "read-only" (which is not the case with PHSx) but that it is: "someone else writes to it, too"

Paul Baker · 2007-08-24 20:11

Using ina as a destination register is perfectly valid if you are using the shadow register (every special purpose register has an actual location in cog memory, when read only or write only SPRs are accessed in the manner they are not designed, this shadow register is what is actually accessed). You may ask "why on earth would I ever want to access the shadow register when I can only write to it?", well for one loop variables are initialized (a write) and djnz accesses them in the destination field as well. So by diligent use of the shadow registers you can squeeze some "magic" use out of them for those times when you need just a few more locations in a cog to make a program fit. Chip's high resolution video drivers are a good example where shadow registers are employed as loop variables.

The Tricks and Traps covers this gotcha in situations it's not fully apparent such as test and wr(long/word/byte) (which is a little more of a gotcha since you cant just flip the registers, to write the contents of ina to hub memory you must first copy it's value)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 8/24/2007 8:24:53 PM GMT

epmoyer · 2007-08-24 20:28

I was unaware of the shadow register trick; I'll go do some digging on that. Thanks for the insight Paul.

Paul Baker · 2007-08-24 20:36

No problem, if you end up using them you may want to designate a constant such as INA_SHADOW = $F2 and use that when accessing the shadow register. That way it shows you are deliberately using the shadow register to anyone reading your code.

<Edit> correction it should be INA_SHADOW = $1F2 </Edit>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 8/24/2007 9:28:01 PM GMT

deSilva · 2007-08-24 21:09

Just for the records: It's $1F2

Paul Baker · 2007-08-24 21:25

You are correct, thanks deSilva.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

deSilva · 2007-08-24 23:29

Maybe someone might find this instructive..
I also learnt by this program that it is not allowed to use NR with RDLONG; what a shame! I just needed WZ

{
 Exploring the shadow registers  v02
 2007 deSilva 
}
CON

  _clkmode = xtal1 + pll8x
  _xinfreq = 10_000_000
     
OBJ
  pc   :       "PC_Interface"  ' Ariba's PropTerminal
  
PUB main 
  pc.start(31,30)

  cntcell := @cntcell
  shadow :=  @shadow
  opflag := @opflag
  cognew(@asm,0)

  
  repeat
    setpos(0,0) 
    pc.str(string("Values from shadow cells.. press any key"))
    pc.str(string(13, "the CNT     "))
    pc.hex(cnt,8)
    pc.str(string(13, "from COG    "))
    pc.hex(cntcell,8)
    pc.str(string(13,"the shadow  "))
    pc.hex(shadow,8)

    if pc.gotKey   ' press a key to add to CNT shadow
      pc.clearKeys
      opflag := 0  
    waitcnt(clkfreq/20+cnt)

    
DAT
    org    0
asm
    mov    RA, CNT
    wrlong RA, cntcell            ' show the real thing
    wrlong CNT, shadow            ' show the shadow

    rdlong RA, opflag  WZ
    if_Z   add     CNT,  #1       'use shadow
                                  'acknowledge command:
    if_Z   wrlong  opflag, opflag 'write any value as long as it's not 0  
    jmp    #asm

  shadow   long 0
  cntcell  long 0
  opflag   long 0
  RA        res  1

PRI setpos(px, py)
  pc.out(10)
  pc.out(px)
  pc.out(11)
  pc.out(py)

Post Edited (deSilva) : 8/24/2007 11:54:31 PM GMT

Mike Green · 2007-08-24 23:48

Yes.· It's interesting (at least a little bit) that the difference between RDLONG and WRLONG is whether NR or WR is true.· For RDLONG, you have to have WR.· For WRLONG, it's NR.· The instruction code is the same.· The same thing is true for RDWORD/WRWORD and RDBYTE/WRBYTE.

deSilva · 2007-08-24 23:55

I am already happy that compiler did not change my RDLONG into a WRLONG on the fly

milesF · 2012-12-03 21:56

Sorry about bumping this five-year-old thread, but I just wanted to contribute some feedback from a new-user prospective.

I spent many hours trying to debug an issue caused by using ina as the destination register for the test instruction. Since I am a new Propeller user, I assumed that my problem was the result of any number of other possible novice mistakes, and so troubleshooting was very difficult. This has really soured my initial impression of the chip, and I am somewhat paranoid that I'll need to read the full 399-page manual in its entirety to avoid stumbling on other unknown caveats. This frustration could be easily prevented for future users by either having the compiler generate a warning, or by adding a note in the manual for the test instruction.

kuroneko · 2012-12-03 22:07

milesF wrote: »

... I am somewhat paranoid that I'll need to read the full 399-page manual in its entirety to avoid stumbling on other unknown caveats.

Read the datasheet instead, specifically section 5.2 Cog RAM. As for wasting hours, you can always ask questions here, it's more or less covered 24h.

Heater. · 2012-12-04 00:42

milesF,

Welcome to the forum.

I do feel you pain. Such little "gotchas" can waste a lot of time. Still all devices have them in my experience. Eventually you find the reason buried in a foot note on page 700 of a two thousand page manual:)

Also my experience is that the Prop instruction set and assembly language are about the simplest, most regular and easy to use of any device I have come across. There are few "gotchas"

Anyway, if you get stuck again, just ask here. There is always someone about to help.

Mark_T · 2012-12-04 03:05

I feel that use of the shadow registers is at least worthy of a compiler warning, since the symptoms are so counter-intuitive (was that meant as a pun?).
The single most common gotcha I've hit is forgetting # for small integer constants in the source field, especially when using $ hex notation (the lack
is less visible then). In BST at least there's no warning for that, and the symptoms are again weird and wonderful.

Why is using ina as a destination register not flagged as a compiler error?

Comments