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,622
    cgracey wrote: »
    There is also a 'reverse' operator in the assembler: "><".

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

  • TonyB_TonyB_ Posts: 246
    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.
  • TonyB_TonyB_ Posts: 246
    edited October 11 Vote Up0Vote Down
    cgracey wrote: »
    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.

    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.

    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.

    A final "just checking" message (I hope).

    In order to enable CZ writing in XBYTE, i.e. copying bytecode[1:0] to [C,Z], am I right in saying that SETQ[9] must be 1?

    Going back a bit, I think the CALL skip freeze counter (call+/ret-) is 3-bit. This means CALLs could be nested to a level of 7, but the maximum CALL nesting is not mentioned in the docs. In fact, I'm not sure CALLs during skipping are mentioned yet in the docs (last one I have is v20 and they are not).

    P.S.
    Many thanks, Chip, for adopting 'correct sign' !

    Formerly known as TonyB
  • cgraceycgracey Posts: 8,321
    edited October 12 Vote Up0Vote Down
    TonyB_,

    Right, bit 9 of the SETQ value is 1 to enable C,Z being set to the two LSBs of the bytecode-lookup address in LUT.

    A four-bit counter tracks CALL/CALLPA/CALLPB depth, so the full 8 levels of the hardware stack can be used.

    This stuff is in the documentation now.
Sign In or Register to comment.