Shop OBEX P1 Docs P2 Docs Learn Events
CMP redefined. A Parallax first! — Parallax Forums

CMP redefined. A Parallax first!

User NameUser Name Posts: 1,451
edited 2011-06-02 17:31 in Propeller 1
On the long list of potential gotchas for veteran asm programmers migrating to the Prop, surely one of the first items would be the fact that CMP doesn't affect the Z bit unless you tell it to.

I'm sure this will feel normal some day, but right now it's maddening. I want an hour of my life back!
«1

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-01 19:47
    Trust me: you will eventually come to love the selective flag-setting and wonder how other micros can survive without it.

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-01 20:07
    Yes, the CMP instruction got me the first time I tried to use it. One would assume that CMP and TEST would set the zero and carry flags by default. However, the Prop manual does a good job of documenting the instructions, and it clearly shows that the Z and C bits default to zero in the instruction. It's almost as if Parallax actually expected us to read the manual. :)
  • Mike GreenMike Green Posts: 23,101
    edited 2011-06-01 20:17
    One of the reasons the CMP and TEST instructions don't set the zero and carry flags by default is that you usually don't want both of them and often you're carrying some past value in the other flag. The compiler doesn't know which one you will want, so it's better to make you specify the right one like all of the other instructions where the WC and WZ are optional.
  • User NameUser Name Posts: 1,451
    edited 2011-06-01 20:25
    Yes, I'm pretty familiar with the RTFM syndrome. I've never had the patience for long FM's, but it is inexcusable for me to use an instruction that I never looked up. I got away with it in SPIN, but PASM has too many surprises.

    There certainly are many things to love about assembly on the Propeller. ANDN and MUXC come to mind immediately.

    I knew of the existence of effects, and have used them a time or two, but somehow I was under the impression that they were more for special cases - variations from normal functionality.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-06-01 20:26
    It is a huge advantage that the flags are not automatically set!

    Every instruction can optionally check the flags (execute the instruction or not) and every instruction can optionally set them.

    Just takes a little getting used to, just like learning to drive an automatic car after a manual. Foot goes to the floor to change gear for a short time. Then, like most drivers, you'll love the auto. Same with the Prop :)
  • User NameUser Name Posts: 1,451
    edited 2011-06-01 21:47
    I've been looking at the glass half empty. Looking at it half full, I see that one hour of frustrating debugging is insignificant compared to the the weeks of spare-time it would take to work through a 385 page manual. And at the end of such a marathon, most of the details would not have stuck anyway. Learning by doing isn't so bad, even if a little hair gets pulled out along the way. More than likely someone has already compiled a list of the main gotchas in PASM. Devoting a few minutes to looking for such a list would probably be time well-spent.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-06-01 22:01
    There is a Tricks and Traps doc somewhere on this forum. Perhaps OBC will chime in with a link for you.

    meanwhile, if something does not seem to be working the right way, it is easy to go to the pdf manual in PropTool (in the help menu) and just check the bit you are looking for. It will have been downloaded with PropTool.

    Also, don't forget, you can always ask here. There are plenty eager to help.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-01 22:31
    Tricks 'n' Traps:

    The PDF is far from up-to-date, but there's plenty of more recent stuff to glean from contributors to the thread.

    -Phil
  • Heater.Heater. Posts: 21,230
    edited 2011-06-02 04:22
    User Name,
    ...but PASM has too many surprises

    Odd that. Having used a lot of different assemblers over the years I would have said that PASM has the least number of surprises. No special registers, they are all the same.No operations that work on some registers and not others etc etc.

    It is extremely regular and self consistent. One hardly has to read the huge FM to get things working once you are aware of the operations available and the simple ideas about conditional execution and writing out the flag bits.

    I do sympathise that if one has missed those simple core ideas then a world of surprises awaits:)
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 06:34
    Well, like I said, I knew there were effects, but I thought they represented the exceptions and not the rule...a profound rule.

    "Trap: The Propeller has a TEST instruction that lets you set flags based on
    the outcome of ANDing the instruction’s source and destination arguments.
    But be sure to tell it which flags to set using WZ and/or WC. This doesn’t
    happen automatically, just because it’s a test instruction."

    I'm loving Tricks 'n' Traps already. Thanks!
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 06:48
    I'm going to take Cluso's advice and ask: Is there a general rule involving C and Z? Is the rule that C and Z are never changed by an instruction unless the relevant effect is included? Or is it more complicated, requiring actual memorization of arbitrary details?
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-02 07:20
    The following sentence appears at the bottom of page 251 in the Prop Manual v1.1:
    The Z and C bits of the ZCRI field are clear (0) by default and are set (1) if the instruction was specified with a WZ and/or WC effect.
    So it clearly states that the Z and C bits are zero by default. You just have to read through a 399-page document to find it. :)

    I realize that in other assemblers the Z and C flags are written by almost every instruction, and quite often there is no way to disable that. However, this feature of the prop makes LMM PASM possible. The instructions in the LMM PASM interpreter loop don't affect the the Z and C flags, which allows it to fetch an instruction from HUB memory and execute it as if the LMM PASM code resided in cog memory.
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 07:46
    Thanks, Dave, for pulling this up! Thank goodness (or Chip) it is an easy rule.

    FWIW, 60 seconds ago I read this tidbit in Tricks 'n' Traps:

    "Trap: In working with the Propeller, the biggest trap of all is the set of
    preconceived notions brought to bear from work with other microcontrollers."

    Amen, bruddah.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-02 07:52
    The Z and C bits of the ZCRI field are clear (0) by default and are set (1) if the instruction was specified with a WZ and/or WC effect.
    That refers, or course, to the instruction fields and not to the flags themselves. Just to clarify: the Z and C flags are unchanged by default and set or cleared (depending on the instruction outcome) only when explicitly specified by using the WZ and/or WC effects. This applies to all instructions.

    -Phil
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 08:23
    As King Arthur is reputed to have said, "This new learning amazes me!" Thanks, Phil. Effects henceforth shall pepper my code.

    In the search for answers, I just came across this file from Drone. How is it that the ASM cog doesn't look at the first four bytes of the sine table as its first instruction? Is the PropTool smart enough to detect a table and relocate it below the code? What page (of the 399-page manual) is this on? It seems remarkably odd.
    spin
    spin
    DDS_PASM_Sin_V1.02.spin
    31K
  • AleAle Posts: 2,363
    edited 2011-06-02 08:36
    And be aware of how the shifts affect the C flag (if you tell them to do so) :)!.

    When I started with the prop I decided that to learn the assembler I'd write a simulator... many months later, some omissions in the manual, unclear details and preconceptions made this a very interesting trip full of discoveries (read my sig). And I haven't been so wild like others at programming. If I keept it simple I'd understand it later, perhaps :)
  • Mike GreenMike Green Posts: 23,101
    edited 2011-06-02 08:48
    In the DDS program, the sine table looks like all NOPs to the Propeller. All of the entries have the upper 24 bits as zeros and, since the condition bits are zero, the instructions are not executed.
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2011-06-02 08:58
    As Mike says, the upper 24 bits are all Zeros, so the 'would be instruction' falls through as a NOP... I'm not sure if this was by design from the author or not. ... probably not. :-) ... what it does is create an initial delay before the DDS starts.

    However you are absolutely correct to notice this as a potential code problem. ... you can however test your finding by placing a ... jmp #$ just before the sine table. Alternatively you can place a ... long $577C0000 for the same result. This basically creates an endless loop or a jump to itself.

    Edit: long $577C0000 should be long $5C7C0000
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 08:59
    This is absolutely fascinating to me, Mike. Thanks for the answer. I'm guessing that Drone actually wanted the attendant delay.

    I'm pleased to hear that execution begins where you tell it to begin. It seems consistent with the general philosophy of the Propeller - complete flexibility.

    I may not want the processor to begin execution in a table of preassembled instructions, but someone like kuroneko might. It might allow an inquisitive person to experiment with instructions that the assembler couldn't be made to assemble.

    Also, I apologize for an OT question. Possibly I should have started a new thread. But thanks for answering it anyway, Mike! It gives me much to think about.
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 09:07
    Beau Schwabe (Parallax) wrote: »
    Alternatively you can place a ... long $577C0000 for the same result. This basically creates an endless loop or a jump to itself.

    Thanks Beau. What a great idea!
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 09:33
    Now I'm officially puzzled. Execution passed right through (or over, rather) LONG $577C0000. It almost looks as though the initial conjecture is correct - PropTool relocates tables. I'm going to go through the assembly listing (F8 thingy) and see if I can verify this.
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2011-06-02 09:34
    User Name,

    There can be a benefit for this .... as long as the CON bits (18..21) in the long are Zero, a NOP instruction is evaluated. This means that you can use all of the other bits for storing data... MOVs, MOVd, MOVi makes this convenient. So if you wanted to be tricky with your code, you could store valid data under the disguise of a NOP instruction.
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 09:50
    Most puzzling. The LONG in question certainly has not been relocated according to the EEPROM file. However I can't tell what the PropTool has done in the way of adjusting the first COGNEW parameter (AsmAddress) to some start location other than the one specified. This puzzle would appear to exceed my pay grade.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-02 09:51
    I think a jmp #$ is $5c7c0000. At least that's what a BST listing shows.
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2011-06-02 10:00
    User Name,

    "Now I'm officially puzzled. Execution passed right through" - location in the program is critical and can change as the program changes ... use F8 to see what it is first with a ... jmp #$ instruction, then replace it with the equivalent long instruction (remember the byte order is reversed)

    Dave,

    your right, it should have been $5c7c where I transposed it as $577c ... still it is $5c7c0000 if you are jumping to the org 0 entry point but if you are jumping to the 4th long in your PASM program it would be $5c7c0003
  • jazzedjazzed Posts: 11,803
    edited 2011-06-02 10:11
    Dave Hein wrote: »
    I think a jmp #$ is $5c7c0000. At least that's what a BST listing shows.
    My experience is jmp #$ is an infinite loop to its own address. $5c7c0000 is definitely a jump to cog location 0 though.

    @User Name, Dave points out that BST creates a listing file. I highly recommend using that. The listing is probably one of the most powerful tools available for understanding code once you know PASM ... other than a good debugger :)

    For my own PASM coding, I use the Propeller DataSheet PASM instruction listing since it is a good summary in all in one place. If I have to dig further down, I'll use the Propeller Manual. Starting with the Propeller Manual is very frustrating though.
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2011-06-02 10:23
    Sorry for the confusion.... here is an example of where a program will jump based on changing the long value. A long value of $5c7c0002 in this example will cause an endless loop.

    Example program to Toggle P0 
    CON
  _CLKMODE = XTAL1 + PLL16X
  _CLKFREQ = 80_000_000

PUB start
    cognew(@PASM, 0)
    
DAT
PASM    org

        mov   dira,     #%00000001              '' 1st long - 0000 
Loop
        xor   outa,     #%00000001              '' 2nd long - 0001

        long $5c7c0002 '' ───────────┐          '' 3rd long - 0002
                       ''            │
        jmp   #Loop    ''            │          '' 4th long - 0003
                       ''            │
                       ''            └────────────────────────┴┴┴┘
  • AribaAriba Posts: 2,690
    edited 2011-06-02 10:28
    User Name

    PASD may help you discovering the wonderful world of PASM:
    http://forums.parallax.com/showthread.php?121946

    Andy
  • tonyp12tonyp12 Posts: 1,951
    edited 2011-06-02 10:46
    Placing the sine table at org 0 is a trick to get the fastest possible read rate.
    This will only work if the data is only using the lower 8 bits (a byte) of each long.
    The prop will think it's just NOP as the it's i-field is all zeros.

    By making the table the power of 2 long (128 longs etc), you can increment the counter fast
    and it will always stay between 0 and 127 by doing this below.

    ADD Counter, #1
    AND Counter, #%1111111 ' make sure it never rolls past 127

    Can also use ANDN Counter, #%1<<8 ' remove bit 8 (turn 128 in to 0)
  • User NameUser Name Posts: 1,451
    edited 2011-06-02 11:01
    This is fantastic. Thanks for all the answers, clarifications, tools, and recommendations! I'm checking out BST and PASD as I write this.

    The body of knowledge contained within this forum is simply amazing. :)
Sign In or Register to comment.