XBYTE question

12346»

Comments

  • cgracey wrote: »
    There is also a 'reverse' operator in the assembler: "><".

    SKIPF #%011010110 >< 9

    I just realized in that example it wouldn't matter.

    Oh yes. Forgot about the "><" operator. I've never used it.

    So for the above example
    bytetable	long	r4 | 011_01_0% << 10	'forward byte branch
    becomes
    bytetable	long	r4 | (%011_01_0_0000000000000000 >< 22) << 10	'forward byte branch
    

    Melbourne, Australia
  • jmgjmg Posts: 10,345
    cgracey wrote: »
    There is also a 'reverse' operator in the assembler: "><".

    Cool - so this is already in the assembler, problem solved.

  • TonyB_TonyB_ Posts: 44
    edited August 31 Vote Up0Vote Down
    cgracey wrote: »
    TonyB_ wrote: »
    TonyB_ wrote: »
    Using SETQ or SETQ2 with Q[9]=1 would seem to be the sensible way to enable CZ writing in XBYTE. This is a bit of a dummy's question: if the D in SETQ/SETQ2 is 9-bit immediate, are the top 23 bits written to Q all zero, ensuring that XBYTE will not modify CZ?

    Is CZ writing in XBYTE optional now, or is this yet to be done?

    I've been thinking, too, that SETQ D[9] could convey whether or not the C/Z bits are written with the two LSBs of the index. That's the last thing I need to implement before I can make another release.

    Just checking that CZ writing in XBYTE really is optional now. It is referred to briefly in v20 documentation but some catching up needed here as no mention of CALLs and interrupts working during skipping.

    Related to my dummy's question quoted above, is a 9-bit immediate source in a NOT instruction first zero-extended to 32 bits then the whole long inverted, so that negative values from -1 to -256 can be moved?
    Formerly known as TonyB
  • TonyB_ wrote: »
    cgracey wrote: »
    TonyB_ wrote: »
    TonyB_ wrote: »
    Using SETQ or SETQ2 with Q[9]=1 would seem to be the sensible way to enable CZ writing in XBYTE. This is a bit of a dummy's question: if the D in SETQ/SETQ2 is 9-bit immediate, are the top 23 bits written to Q all zero, ensuring that XBYTE will not modify CZ?

    Is CZ writing in XBYTE optional now, or is this yet to be done?

    I've been thinking, too, that SETQ D[9] could convey whether or not the C/Z bits are written with the two LSBs of the index. That's the last thing I need to implement before I can make another release.

    Just checking that CZ writing in XBYTE really is optional now. It is referred to briefly in v20 documentation but some catching up needed here as no mention of CALLs and interrupts working during skipping.

    Related to my dummy's question quoted above, is a 9-bit immediate source in a NOT instruction first zero-extended to 32 bits then the whole long inverted, so that negative values from -1 to -256 can be moved?

    I have SETQ D[9] working here on my current version. Not sure about v20, though I did just update the documentation to say it is in there. You just reminded me of what I need to catch up with in the doc's - these issues of CALLs and interrupts during skipping.

    Yes, a NOT instruction will zero-extend a 9-bit immediate value before doing a one's-complement and writing the result.
  • If you are updating the docs could you fix the descriptions of SCLU and SCL? I had posted the following comment a few weeks ago in another thread.
    Dave Hein wrote: »
    I was looking at the SCLU and SCL instructions, and there appears to be errors in their descriptions in the Propeller 2 Instruction document. The description for SCLU is "Next instruction's S value = unsigned (D[15:0] * S[15:0])." It appears that the product is also shifted to the right by 16 bits.

    The description for SCL is "Next instruction's S value = signed (D[15:0] * S[15:0]) / $4000." However, rather than dividing by $4000 it would be more accurate to say that it is shifted right by 14 bits with sign extension. If I multiply 1 * (-1) the result is -1. A division by $4000 would have produced a value of zero instead.
  • Dave Hein wrote: »
    If you are updating the docs could you fix the descriptions of SCLU and SCL? I had posted the following comment a few weeks ago in another thread.
    Dave Hein wrote: »
    I was looking at the SCLU and SCL instructions, and there appears to be errors in their descriptions in the Propeller 2 Instruction document. The description for SCLU is "Next instruction's S value = unsigned (D[15:0] * S[15:0])." It appears that the product is also shifted to the right by 16 bits.

    The description for SCL is "Next instruction's S value = signed (D[15:0] * S[15:0]) / $4000." However, rather than dividing by $4000 it would be more accurate to say that it is shifted right by 14 bits with sign extension. If I multiply 1 * (-1) the result is -1. A division by $4000 would have produced a value of zero instead.

    Dave, thanks for reminding me. I just fixed the spreadsheet.
Sign In or Register to comment.