Shop OBEX P1 Docs P2 Docs Learn Events
Instructions that inject results into the next instruction — Parallax Forums

Instructions that inject results into the next instruction

It occurs to me that SCA, SCAS, GETXACC, and XORO32 have an issue from a discovery perspective. All four instructions stuff a value into the next instructions S register, but the subsequent instruction doesn't look any different. In other words, it is not immediately obvious that "something else" is going on. I am not suggesting that the instructions should be changed, mind you. Instead, I'm thinking that there should be some means to easily indicate this in the code. But a particular recommendation escapes me. I know the old "0-0" trick for P1 might work, but it doesn't feel like a real solution. So, for now, I'm just putting it out there for discussion.

Comments

  • evanhevanh Posts: 15,126
    In addition, if things ever move on to data being inserted to D port instead of S port then a simple textual placeholder won't even show up any longer because the D field still has valid use specifying the result register/address. The magic won't even be hinted at any longer.
  • evanhevanh Posts: 15,126
    It's not just those four either. The multitude of ALTx instructions fall under this as well.
  • evanh wrote: »
    It's not just those four either. The multitude of ALTx instructions fall under this as well.

    True, but I left them out because they at least "ALT" something.
  • Cluso99Cluso99 Posts: 18,066
    And the AUG instructions which add insert the top 23 bits. Often used as a byproduct of XXXX D,##S
  • But ## syntax does look different, and the AUGS/AUGD instructions never need appear anyhow.
    I guess it would be nice to hide ALTS/D/R with similar syntactic sugar too.
        ALTS    index,#table    ‘set next S field to table+index
        MOV     OUTA,0        ‘output register[table+index] to OUTA
    coded by
        MOV    OUTA, table[index]
    
    
        ALTR    index,#table    ‘set next write to table+index
        XOR     INA,INB        ‘write INA^INB to register[table+index]
    coded by
        XOR    table[index], INA, INB
    
    
        ALTS    pointer        ‘set next S field to pointer
        MOV     OUTA,0        ‘output register[pointer] to OUTA
    coded by
        MOV    OUTA, [pointer]
    
  • Cluso99 wrote: »
    And the AUG instructions which add insert the top 23 bits. Often used as a byproduct of XXXX D,##S

    Except, in those cases, you still use all operands in the next instruction. The ALT instructions also do exactly what they say, though you still end up having to place a dummy/placeholder in the appropriate operand of the next instruction.
  • I think hiding the alt instructions is a bad idea, since one often needs to count instructions. to get the size in longs. To remember that xx nedas one more the x is easy to remember, but more cases get cumbersome.

    Enjoy!

    M ike
  • I think the hole instruction set is a nightmare. What a kludge.

    I can't image how a programming language could be developed to use it. I guess we will be stuck with assembler.

    Mike
  • iseries wrote: »
    I think the hole instruction set is a nightmare. What a kludge.

    I can't image how a programming language could be developed to use it. I guess we will be stuck with assembler.

    That's not really germane to this discussion, I think.
  • LMAO!

    Iseries, just you watch. :D

  • potatoheadpotatohead Posts: 10,253
    edited 2019-02-12 20:45
    Re: hidden actions

    I happen to be flipping through my Moto 6809 programmers reference.

    This book is beautiful. Each instruction has a page, and what you need to know is on that page. It is super easy to use.

    Seems to me we can do a similar thing here. Page for each instruction, code snippet, effects.

    As of right now, the syntax is lean and mean. Would hate to see it cluttered further over what is largely a documentation problem..
  • Sorrry, I thought we were talking about altered states or maybe Augmentation surgery.

    Mike
  • actually the PASM2 language is no nightmare at all, at least when you know p1 PASM a bit.

    and with fastspin yuou have Spin1/2, Basic and C already as HLLs available. There is also Prop2gcc(?) using the existing port of gcc for the P1 and reworks the generated P1 PASM into P2 PASM.

    The actual port from gcc for p2 is planned and some work is already done for P2 hot some intermediate P2.

    Enjoy!

    Mike
  • iseries wrote: »
    I think the hole instruction set is a nightmare. What a kludge.

    I can't image how a programming language could be developed to use it. I guess we will be stuck with assembler.

    Mike

    Have you written compiler backends and code generators? Take it from someone who has that the instruction
    set is a lot better than many - lots of registers that are completely orthogonal is a huge benefit, all these AUG and
    ALT instructions are just addressing modes in disguise, plenty of basic ALU operations. Compiling for the cordic
    pipeline is no more tricky than for any other pipelined processor, and it can be used naively easily with lower
    performance, and the block memory reads and writes enable efficient stack use.
  • I like the P1 instruction set. Clean and to the point. No Alter, Aug, or strange address areas. Read from this location and write to that location.

    This should be more like RISC instructions or ARM based. Less is more these days.

    Mike
  • jmgjmg Posts: 15,140
    Seairth wrote: »
    It occurs to me that SCA, SCAS, GETXACC, and XORO32 have an issue from a discovery perspective. All four instructions stuff a value into the next instructions S register, but the subsequent instruction doesn't look any different. In other words, it is not immediately obvious that "something else" is going on. I am not suggesting that the instructions should be changed, mind you. Instead, I'm thinking that there should be some means to easily indicate this in the code. But a particular recommendation escapes me. I know the old "0-0" trick for P1 might work, but it doesn't feel like a real solution. So, for now, I'm just putting it out there for discussion.

    Valid point.
    It has been suggested before that these unclear-patches of two lines, be presented to the user as a single, 3 operand opcodes, where that is clearer.
    They really are 64 bit opcodes, and the user should not be bothered by needing to know the two obtuse jig-saw pieces that make up the 64b opcode..
    Other MCUs have variable length opcodes, and anyone wanting to know exact sizes, and even exact break-downs, can always look at generated list files.
  • Mark_TMark_T Posts: 1,981
    edited 2019-02-12 23:44
    You could also use a marker (like wz, wc, perhaps 'ex' for extended) after the instuction to say you are allowing the
    instruction to be more than one long. A warning would be generated for any multi-long instruction not annotated this way?

    [ actually rather than 'ex', perhaps ##, since this already serves the purpose for AUGS/AUGD, or 'aug' ]
  • roglohrogloh Posts: 5,122
    edited 2019-02-13 00:58
    We used to see both 0-0 and #0-0 variants used on P1 to indicate a patched instruction argument for both D and/or S, so perhaps the same thing still works ok for P2 in many cases. For those that don't it can potentially be further extended to 00-00 or #00-00 forms to indicate this instruction's write address gets affected by some special prior instruction such as ALTR/ALTI etc.

    Also if we still need to keep some original argument name lying around for D instead of using 00-00 maybe we can just put in "d_value-00" for the D field assuming the assembler allows it and won't affect the generated code in any way. I agree it is not perfect but at least helps show something special happens there that is different from the 0-0 case.
    ' Example: sample input data from INA port and compare with a sample
    ' varying mask table in COG RAM and write result values to result table (100 longs).
    ' In this case alticonst would be setup for INC D, and patch and INC R.
    
    
    SETR  output_pos, #result_table ' initialize table result output position
    REP   #2, #100 ' sample 100 times
    ALTI  output_pos, alticonst   ' alter next instruction according to alticonst 
    XOR   mask_table-00, INA   ' the "-00" form indicates result gets patched here, and result is not written to mask_table
    
  • $-$

    -Phil
  • evanhevanh Posts: 15,126
    edited 2019-02-13 03:10
    Mark_T wrote: »
    You could also use a marker (like wz, wc, perhaps 'ex' for extended) after the instuction to say you are allowing the
    instruction to be more than one long. A warning would be generated for any multi-long instruction not annotated this way?

    This has future-proofing for Prop3, as the port injection will be an optional parameter there. Although it doesn't resolve the immediate concern over erratic looking sources.
  • I think I changed my mind about this, thinking about my setbyte x,y #n problem where I needed setbyte x,y,n and had a hard ttime ti figure it out.

    So maybe not a bad idea to add aliases to the existing instruction pairs.

    Enjoy!

    Mike
  • $-$

    -Phil

    How about an explicit placeholder symbol, such as $$, which lets the compiler know that you know what you're doing and lets it produce a warning when you don't use it?
  • evanhevanh Posts: 15,126
    msrobots wrote: »
    So maybe not a bad idea to add aliases to the existing instruction pairs.
    But part of that problem was the alias generated incorrect machine code. :P
  • yes and no, the compiler did produced incorrect code, but that has @ersmith fixed. But I still need to write two long instructions to archive getbyte a,a,n and setbyte a, c, n with n in a register not in a constant.
    setxxxx/getxxxx are all 3 op instructions, just the last op is a constant thus from the PASM syntax would if fit right in, just a macro in assembler...

    Enjoy!

    Mike
Sign In or Register to comment.