Shop OBEX P1 Docs P2 Docs Learn Events
Should SETR/SETD/SETS be called MOVI/MOVD/MOVS ? — Parallax Forums

Should SETR/SETD/SETS be called MOVI/MOVD/MOVS ?

Cluso99Cluso99 Posts: 18,069
in Propeller 2
I have been coding for the P2 and I find in particular SETR seems wrong.

We have ALTR which means substitute the "R"esult address and ALTI which means substitute the "I"nstruction. Hence SETI or MOVI seems a better fit.

We have MOVBYTS, and so MOVI/MOVD/MOVS seems a better fit. There is also the benefit that the P1 uses MOVI/MOVD/MOVS.
And yes, we do have SET/GET/ROL triplets for BYTE and WORD. We don't have pairs/triplets for MOVI/MOVD/MOVS. May have been nice for I & D but not a great case for usage.

BTW this is only a compiler change, not a silicon change.

Comments

  • jmgjmg Posts: 15,173
    I agree, as MOV is closer to what it actually does, and SET sematics are often used for SETting a bit.
  • ozpropdevozpropdev Posts: 2,792
    edited 2018-12-23 06:47
    We have 
    SETWORD
SETBYTE
SETNIB
SETD
SETS
SETR (Agreed, should be SETI)

    All of these modify selected bit(s) of a register.
    Seems consistent to me.

  • Cluso99Cluso99 Posts: 18,069
    edited 2018-12-23 05:28
    Then should MOV be SETLONG or SETREG ???

    And MOVBYTS be SETBYTS ???

    No, I am not advocating this.

    But the MOVI/MOVD/MOVS seem more like modifying instructions whereas the GET/SET/ROL seem more like bit/nibble/byte/word manipulations.
  • ozpropdevozpropdev Posts: 2,792
    Actually SETR was changed from SETI in July 2016.
    It's seems more likely to be used to configure the ALTI instructions R-field than modifying opcode fields in instructions.

  • cgraceycgracey Posts: 14,152
    ozpropdev wrote: »
    Actually SETR was changed from SETI in July 2016.
    It's seems more likely to be used to configure the ALTI instructions R-field than modifying opcode fields in instructions.

    That's right.
  • marsman2020marsman2020 Posts: 71
    People have chips and will be writing assembly to whatever mnemonics are in the current assembler in the FPGA 32i package.

    So I think the time for lengthy debates over the mnemonics is rapidly closing.

    [Joking] Maybe we need two sets of mnemonics, like Intel vs Zilog [joking]
  • Cluso99Cluso99 Posts: 18,069
    ozpropdev wrote: »
    Actually SETR was changed from SETI in July 2016.
    I realise it was changed long ago. That doesn't necessarily mean that we chose it correctly, nor we cannot fix what is wrong.
    IIRC at the time there was no ALTR instruction.
    It's seems more likely to be used to configure the ALTI instructions R-field than modifying opcode fields in instructions.
    I don't understand??? The only "R-field" that I understand is within the pipeline, which is normally the "D-field" unless and ALTR preceded it.

    SETR should at least be SETI as it changes the "I"nstruction bits, not the "R"esult address.

    ALTR changes the "R"esult address within the pipeline.


  • ozpropdevozpropdev Posts: 2,792
    edited 2018-12-23 11:19
    Cluso99 wrote: »
    I don't understand??? The only "R-field" that I understand is within the pipeline, which is normally the "D-field" unless and ALTR preceded it.

    SETR should at least be SETI as it changes the "I"nstruction bits, not the "R"esult address.

    ALTR changes the "R"esult address within the pipeline.


    Sorry, I wasn't very clear there.
    It's not a pipeline thing, it modifies bits [27:19] in the D registers R field. 
    	ALTI	D,#/S

Where s = % rrr_ddd_sss_RRR_DDD_SSS for inc/dec/etc

and D = % xxxx_RRRRRRRRR_x_DDDDDDDDD_SSSSSSSSS for indexes
    chip wrote:
    The ALTx instructions pretty much antiquate the need for self-modifying code.
    The SETR/SETD/SETS instructions can be used for self-modifying code, but are really useful for setting up ALTI behavior.
  • Cluso99Cluso99 Posts: 18,069
    I don't know why we are now calling the I-field the R-field ???

    Aren't the RRRRRRRRR bits the IIIIIII_CZ bits of an instruction, and isn't the purpose of SETR (SETI) instruction to change the instruction on the fly ie self-modifying code ???

    I am converting some P1 code that does quite a bit of instruction modification (spin Interpreter). Some of these problems include changing return jump addresses, switching between SHR and SHL, changing RDBYTE/WORD/LONG and changing RDxxxx to WRxxxx. The RD & WR and BYTE/WORD/LONG are a real PITA because of the lack of symmetry between these instructions but it's now too late to fix the encodings :( Similarly, the lack of "NR" bit to disable instruction(s) and also not having an actual NOP instruction code or alternately a conditional "IF_NEVER" is another PITA. All these thing were done in order to compress the code to make it fit.
  • cgraceycgracey Posts: 14,152
    Cluso99, figure out what the code is trying to do and then recode it for Prop2. It should be a joy, not a pain. There are better ways to do many things with Prop2. You are spending a lot of time fighting it, when you could be developing new ways of doing things are that are more agreeable to the new architecture.
  • Roy ElthamRoy Eltham Posts: 3,000
    Code Compression is done even better with the skip feature combined with xbyte. Chip is using those features in the new Spin interpreter (he developed the features while attempting to write it), and packing in so much stuff into so little space. Go dig through the thread on xbyte.
  • jmgjmg Posts: 15,173
    ozpropdev wrote: »
    We have 
    SETWORD
SETBYTE
SETNIB
SETD
SETS
SETR (Agreed, should be SETI)

    All of these modify selected bit(s) of a register.
    Seems consistent to me.

    The companion opcodes are GETxxx, so an alternative that avoids the SET (as in make the bit one) semantic conflict, would be PUTxxx.
    GET & PUT more naturally pair, and that has to help non-english speakers.

    Looking in the opcodes DOCs at the pair of set/clear, set appears 138 times and clear appears 49 times. Mostly usages apply to 'make a bit one'.
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    Cluso99, figure out what the code is trying to do and then recode it for Prop2. It should be a joy, not a pain. There are better ways to do many things with Prop2. You are spending a lot of time fighting it, when you could be developing new ways of doing things are that are more agreeable to the new architecture.

    That's true, but both migration pathways are valid, and P2 ASM should assist anyone P1 porting, where that can be easily done.
  • potatoheadpotatohead Posts: 10,261
    edited 2018-12-23 19:18
    Actually the decision very early on was to optimize P2. Take good P1 ideas and then blow it all out for a performant chip with distinctive features.

    Having it make sense in terms of P1 is really of limited value. They are very different devices as designed and intended. Longer term, assis5s to P2 ways and means make far more sense. There will not be new P1 designs. There are very likely to be multiple new P2 designs.

    In many cases, new features really do make more sense. We did it this way to maximize the potential of the new design.

    Those choices are long past cooked in. Muddying things up now makes very little sense.

    Frankly, once SPIN 2 gets fleshed out, many things written in P1 PASM will do just fine written in P2 SPIN. This is a really big jump. Again as indended.

Sign In or Register to comment.