Question about ALTDS implementation in new chip

2»

Comments

  • Gee ... pointers are always such a brain twister. We'll be wanting some macros me thinks.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • evanhevanh Posts: 8,033
    edited 2015-09-13 - 12:02:08
    Ah, but I think an inverse example can skip the intermediate storing:
                    setd  ptr2ptr, #raceptrtable
                    rep  #(:loopend-:loop), #(racetablend-raceptrtable)
    :loop
                    mov  score, #{random number}   ' acquire a score  - just a filler
    ptr2ptr         altds  ptr2ptr, #000_001_000   ' apply ptr2ptr to next instruction then increment
                    altds  0-0, #000_100_000       ' apply the table entry to next instruction without even storing it!  This works only because we are working on the D operand
                    mov  0-0, score                ' enter a score into the list  - ie: use the applied pointer
    :loopend
    
    
    score           res  1
    raceptrtable    long  $100,$10A,$11A,$12C,$138,$144   ' table of pointers to list of scores
    racetablend
    
    Assuming I've got this right, then maybe there can be an improvement to the ALTDS instruction that allows applying of a D data field to a S operand in particular ... or have a second instruction, say ALTSD, that has the meaning of S and D operands within the ALTDS instruction itself exchanged.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Or not. After all, it's only a difference of one added instruction the way it is. I guess we should be happy that double indirection is a goer.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Oops, another mistake above. Trying to optimise as well :D. ptr2ptr can't be located in the first ALTDS like that. That D operand has to reference an incrementing pointer.

    It could be located in the second ALTDS since that one has an unused/empty D operand. Or the following MOV would do as well. Neither use their respective D operand.
                    setd  ptr2ptr, #raceptrtable
                    rep  #(:loopend-:loop), #(racetablend-raceptrtable)
    :loop
                    mov  score, #{random number}   ' acquire a score  - just a filler
                    altds  ptr2ptr, #000_001_000   ' apply ptr2ptr to next instruction then increment
    ptr2ptr         altds  0-0, #000_100_000       ' apply the table entry to next instruction without even storing it!  This works only because we are working on the D operand
                    mov  0-0, score                ' enter a score into the list  - ie: use the applied pointer
    :loopend
    
    
    score           res  1
    raceptrtable    long  $100,$10A,$11A,$12C,$138,$144   ' table of pointers to list of scores
    racetablend
    
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • SeairthSeairth Posts: 2,387
    edited 2015-09-14 - 11:52:00
    evanh wrote: »
    A tidy up would be:
                    SETD reg1, #reg2            ' Cog pointer to Cog pointer preassigned, $FF placed in D operand of the ALTDS below.  If traversing a table of Cog/LUT pointers then #reg2 wouldn't be an immediate operand.
                    NOP                         ' Dummy for SETD to write back before ALTDS is fetched.
    reg1            ALTDS 0-0, #000_000_100     ' replaces next instruction's S from the assigned, in this case with $100
                    MOV dest, 0-0               ' becomes MOV dest, $100
    
    reg2            LONG #$100
    

    But if you are modifying the ALTDS instruction, why not simply:
                    ' single indirection
                    SETS reg1, #reg2
                    NOP                         
    reg1            MOV dest, 0-0               
    
    
                    ' double indirection
                    SETS reg1, reg2
                    NOP                         
    reg1            MOV dest, 0-0               
    

    Of course, the answer is that it's not this simple when you are including increments/decrements and both D and S fields. But I'm not sure that the "traditional" way is any more complicated.

    Here's incrementing/decrementing:
                    'single indirection
                    SETS reg1, #reg2
                    ADD reg2, #1
    reg1            MOV dest, 0-0        
    
                    ' double indirection
                    SETD ind2, reg2
                    SETS reg1, ind2
    ind2            ADD 0-0, #1
    reg1            MOV dest, 0-0
           
    

    Here's d-field and s-field:
                    ' single indirection
    :loop           SETS reg1, #reg2
                    ADD reg2, #1
                    SETD reg1, #reg3
                    ADD reg3, #1
    reg1            MOV 0-0, 0-0
                    DJNZ count, #:loop
    
                    ' double indirection
    :loop           SETS reg1, reg2
                    ADD reg2, #1
                    SETD reg1, reg3
                    ADD reg3, #1
    reg1            MOV 0-0, 0-0
                    DJNZ count, #:loop
    
    

    And here is the same with ALTDS:
                    ' single indirection
                    SETS reg1, #reg2
                    SETD reg1, #reg3
    :loop           ALTDS reg1, #000_001_001
                    MOV 0-0, 0-0
                    DJNZ count, #:loop
                    GETS reg2, reg1
                    GETD reg3, reg1
    
                    ' double indirection
                    SETS reg1, reg2
                    SETD reg1, reg3
    :loop           ALTDS reg1, #000_001_001
                    MOV 0-0, 0-0
                    DJNZ count, #:loop
                    SETD copys, reg2
                    SETD copyd, reg3
    copys           GETS 0-0, reg1
    copyd           GETD 0-0, reg1
    
    

    note that it is more instructions, but a tighter/faster loop.

    And, just for the fun of it, here is the code if we were to use the "simplified" ALTDS I recommend above:
                    ' single indirection
    :loop           ALTDS reg3, reg2
                    MOV 0-0, 0-0
                    ADD reg2, #1
                    ADD reg3, #1
                    DJNZ count, #:loop
    
                    ' double-indirection
    :loop           ALTDS reg3, reg2
                    ALTDS 0-0, 0-0
                    MOV 0-0, 0-0
                    ADD reg2, #1
                    ADD reg3, #1
                    DJNZ count, #:loop
    
    

    This falls somewhere between the two approaches above. It's the least amount of code, has a slightly faster loop than the first approach. But I contend that it is the easiest version of ALTDS to understand.

    Of course, this is a very simple example (move "count" longs). If that loop were working on a complex structure that required multiple ALTDS with increment/decrement, then the current ALTDS would likely be more compact and efficient. On the other hand, I think the current ALTDS (at least in the example above) is more error-prone, since one could potentially forget to "write back" the s-field and d-field registers to reg2 and reg3.

    Anyhow... more to think about.
  • cgraceycgracey Posts: 11,735
    edited 2015-09-15 - 09:45:52
    Sorry I haven't been on this discussion, yet. I've been working away on the Verilog.

    I will read what everyone wrote here, but first I explain how it works, currently (open to improvement, of couse).

    The other day I revisited ALTDS because we had moved the CCCC bits to the front of the opcode.

    The old SETI instruction now writes S[8:0] into D[27:19] (the OOOOOOOCZ bits), instead of into the top bits

    opcode: CCCC OOOOOOO CZI DDDDDDDDD SSSSSSSSS

    The OOOOOOOCZ bits in a variable (not an instruction) can be used to redirect result writing, while the DDDDDDDDD and SSSSSSSSS fields can redirect D and S.

    It works like this:

    ALTDS D,S/# 'modify D according to bits in S and possibly replace next instruction's CCCCOOOOOOOCZI / DDDDDDDDD / SSSSSSSSS fields.

    In ALTDS, S provides the following pattern: %RRR_DDD_SSS

    %RRR: (101 allows instruction substitution)
    000 = don't affect D's CCCCOOOOOOOOOCZI field
    001 = don't affect D's CCCCOOOOOOOOOCZI field, cancel write for next instruction
    010 = decrement D's OOOOOOOCZ field
    011 = increment D's OOOOOOOCZ field
    100 = use D's OOOOOOOCZ field as the result register for the next instruction (separate from D)
    101 = use D's CCCCOOOOOOOCZI field as next instruction's CCCCOOOOOOOCZI field
    110 = use D's OOOOOOOCZ field as the result register for the next instruction, decrement D's OOOOOOOCZ field
    111 = use D's OOOOOOOCZ field as the result register for the next instruction, increment D's OOOOOOOCZ field

    %DDD
    000 = don't affect D's DDDDDDDDD field
    001 = copy D's SSSSSSSSS field into its DDDDDDDDD field
    010 = decrement D's DDDDDDDDD field
    011 = increment D's DDDDDDDDD field
    100 = use D's DDDDDDDDD field as the DDDDDDDDD field for the next instruction
    101 = use D's DDDDDDDDD field as the DDDDDDDDD field for the next instruction, copy D's SSSSSSSSS field into its DDDDDDDDD field
    110 = use D's DDDDDDDDD field as the DDDDDDDDD field for the next instruction, decrement D's DDDDDDDDD field
    111 = use D's DDDDDDDDD field as the DDDDDDDDD field for the next instruction, increment D's DDDDDDDDD field

    %SSS
    000 = don't affect D's SSSSSSSSS field
    001 = copy D's DDDDDDDDD field into its SSSSSSSSS field
    010 = decrement D's SSSSSSSSS field
    011 = increment D's SSSSSSSSS field
    100 = use D's SSSSSSSSS field as the SSSSSSSSS field for the next instruction
    101 = use D's SSSSSSSSS field as the SSSSSSSSS field for the next instruction, copy D's DDDDDDDDD field into its SSSSSSSSS field
    110 = use D's SSSSSSSSS field as the SSSSSSSSS field for the next instruction, decrement D's SSSSSSSSS field
    111 = use D's SSSSSSSSS field as the SSSSSSSSS field for the next instruction, increment D's SSSSSSSSS field

    You can see that when those three-bit RRR/DDD/SSS fields have their MSB's clear, they are only affecting D. When their MSB's are set, though, they additionally affect the next instruction in some way.

    When RRR is 101, it actually uses D's upper bits to replace the functionality of the next instruction, which might as well be a NOP, unless its DDDDDDDDD and SSSSSSSSS fields are meaningful.

    It hurts to think about, but I think, as someone proposed above, compounded indirection can be achieved. Also, some crazy instruction substitution possibilities exist. And, not being self-modifying code, this can all work from hub-exec.

  • Chip,
    I need to get my head around this again.

    However, I see that RRR=000/001 are the same.
    Perhaps, RRR=001 could be used as setting NR for the next instruction, rather than S=0.
    This way, D & S can still be substituted if required, and we now have the option to not write the result.
    I don't think it matters that this (NR) is mutually exclusive to changing the following instruction's CCCCOOOOOOOCZ, or an alternate result D address with/without increment.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgraceycgracey Posts: 11,735
    edited 2015-09-15 - 09:47:30
    Cluso99 wrote: »
    Chip,
    I need to get my head around this again.

    However, I see that RRR=000/001 are the same.
    Perhaps, RRR=001 could be used as setting NR for the next instruction, rather than S=0.
    This way, D & S can still be substituted if required, and we now have the option to not write the result.
    I don't think it matters that this (NR) is mutually exclusive to changing the following instruction's CCCCOOOOOOOCZ, or an alternate result D address with/without increment.

    Yes, I removed that functionality, but your proposal would be the perfect way to reintroduce it.

    I got rid of it because I was thinking about why one would spend an instruction avoiding a write, when that instruction takes the same amount of RAM as a dummy register that could have been written. But, now I'm thinking that maybe there's more value in the idea. If you don't write, you can still get C/Z affected, but is it worth a whole instruction? It could take an instruction to move a value from an important register to a dummy register for a destructive operation, but it costs just as much.

    Can you come up with any compelling reasons why we should do this? It's trivial to implement, and I'll go ahead and do it, but what's the practical advantage in this function? I suspect there is one, but it's eluding me.

    P.S. I just made the change in the Verilog and modified my post above to reflect the new behavior.
  • You are correct that an NR instruction could be achieved by moving to a temporary register and then performing the instruction using the temporary register instead. The only saving is the temporary register, which often is available in a program anyway.

    Perhaps there are some tricks we could do using the ALTDS with NR, looking for a bit pattern within a buffer ???

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Unrelated to ALTDS:
    cgracey wrote: »
    The old SETI instruction now writes S[8:0] into D[27:19] (the OOOOOOOCZ bits), instead of into the top bits

    Why exclude the "I" bit?
  • Seairth wrote: »
    Unrelated to ALTDS:
    cgracey wrote: »
    The old SETI instruction now writes S[8:0] into D[27:19] (the OOOOOOOCZ bits), instead of into the top bits

    Why exclude the "I" bit?

    Because we have a SETI instruction that writes the useful instruction field of OOOOOOOCZ and it is the only 9-bit writer instruction up above D and S fields. So, it's needed to set up the write redirection for ALTDS. Nothing against the "I" bit. This all stems from the 9-bit constant limitation. Better to cover the OOOOOOOCZ bits than miss the top one just to pick up "I".
  • Cluso99 wrote: »
    You are correct that an NR instruction could be achieved by moving to a temporary register and then performing the instruction using the temporary register instead. The only saving is the temporary register, which often is available in a program anyway.

    Perhaps there are some tricks we could do using the ALTDS with NR, looking for a bit pattern within a buffer ???

    Yes, there must be some useful trick we can do when RRR=001.
  • cgracey wrote: »
    %RRR: (101 allows instruction substitution)
    000 = don't affect D's CCCCOOOOOOOOOCZI field
    001 = don't affect D's CCCCOOOOOOOOOCZI field, cancel write for next instruction
    010 = decrement D's OOOOOOOCZ field
    011 = increment D's OOOOOOOCZ field
    100 = use D's OOOOOOOCZ field as the result register for the next instruction (separate from D)
    101 = use D's CCCCOOOOOOOCZI field as next instruction's CCCCOOOOOOOCZI field
    110 = use D's OOOOOOOCZ field as the result register for the next instruction, decrement D's OOOOOOOCZ field
    111 = use D's OOOOOOOCZ field as the result register for the next instruction, increment D's OOOOOOOCZ field

    Okay. I was a bit slow on understanding %RRR. Now I get it! "R" for "Result"! Also, now I think I see why SETI is updating precisely 9 bits (excluding "I"). For clarity:

    000 = don't affect D's RRRRRRRRR field
    001 = don't affect D's RRRRRRRRR field, cancel write for next instruction
    010 = decrement D's RRRRRRRRR field
    011 = increment D's RRRRRRRRR field
    100 = use D's RRRRRRRRR field as the result register for the next instruction (separate from D)
    101 = use D's CCCCOOOOOOOCZI field as next instruction's CCCCOOOOOOOCZI field
    110 = use D's RRRRRRRRR field as the result register for the next instruction, decrement D's RRRRRRRRR field
    111 = use D's RRRRRRRRR field as the result register for the next instruction, increment D's RRRRRRRRR field

    RRRRRRRRR is the same bit field as OOOOOOOCZ.
  • cgracey wrote: »
    Because we have a SETI instruction that writes the useful instruction field of OOOOOOOCZ and it is the only 9-bit writer instruction up above D and S fields. So, it's needed to set up the write redirection for ALTDS. Nothing against the "I" bit. This all stems from the 9-bit constant limitation. Better to cover the OOOOOOOCZ bits than miss the top one just to pick up "I".

    Maybe consider renaming SETI to SETR? I'm guessing that this will be the more likely use case (as compared to altering opcodes).
  • Seairth wrote: »
    cgracey wrote: »
    Because we have a SETI instruction that writes the useful instruction field of OOOOOOOCZ and it is the only 9-bit writer instruction up above D and S fields. So, it's needed to set up the write redirection for ALTDS. Nothing against the "I" bit. This all stems from the 9-bit constant limitation. Better to cover the OOOOOOOCZ bits than miss the top one just to pick up "I".

    Maybe consider renaming SETI to SETR? I'm guessing that this will be the more likely use case (as compared to altering opcodes).

    That sounds like a good idea to me.
  • So, what is SETDS for? If this functionality can be handled with SETD and SETS, how about replacing it with GETR? That way, we would have parity for that set of instructions:

    * GETD/SETD
    * GETS/SETS
    * GETR/SETR
  • Normally the SETI (or SETR) is used for modifying the instruction, and hence the name SETI and the new GETI. These are limited to 9 bits to conform to the 9bit standard of D & S.

    So, to me, SETI & GETI make more sense than SETR & GETR.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Normally the SETI (or SETR) is used for modifying the instruction, and hence the name SETI and the new GETI. These are limited to 9 bits to conform to the 9bit standard of D & S.

    So, to me, SETI & GETI make more sense than SETR & GETR.

    SETI does not include the "I" bit, which is certainly part of an instruction. It also does not set the all of the instruction bits of any of the alternate instruction forms. Conversely, SETR always sets 9 bits used for R.

    This also clarifies the intention, as this casts the SETD/SETS (along with SETR) as primarily relating to ALTDS, and secondarily as a means to self-modify code. As Chip pointed out, this is preferred in hubexec mode.
  • Dave HeinDave Hein Posts: 5,957
    edited 2015-09-16 - 13:19:04
    Personally, I prefer SETI over SETR. To me SETI means "SET Instruction". SETR has little meaning to me. If the R refers to the "result" then it should set the result of the instruction's operation, which would make it equivalent to a MOV instruction. Stating that the R in SETR refers to the "result" field described in the ALTDS instruction is confusing. The description of the ALTDS instruction probably should not refer to that field as the result field, but should use some other term instead of "result".

    How about changing SETI to SETINST instead? This is less ambiguous than SETI. Yes, the SETI instruction also sets the C and Z bits, but these can be interpreted as being part of the instruction, and on the P2 the C and Z bits are used to distinguish between certain instructions.
  • Cluso99Cluso99 Posts: 15,452
    edited 2015-09-16 - 13:48:05
    SETI was the MOVI instruction on P1, just like MOVD and MOVS are now SETD and SETS.
    On the P1 MOVI replaced the 9 bit iiiiiizcr. Note here the "I" immediate bit is not replaced. IMHO the "I" bit has more to do with the S operand as a modifier than it does with the instruction. Take an example where MOVI was used in the P1... I the spin interpreter, a rdlong is changed to a wrlong. You would not change the "I"bit here as you would want it left the same as it was because its part of the S operand.

    Actually, I still prefer the MOVI, MOVD and MOVS over SETI/SETR, SETD and SETS, even tho' we now also have GETI/GETR, GETD, GETS.

    FWIW these are only mneumonics so they are unimportant as far as getting an FPGA image or a real P2.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Actually, there is no GETI at the moment. Regardless of what they are called, that is what I was asking about further. Could the opcode for SETDS be instead used for GETI//GETR?
  • cgraceycgracey Posts: 11,735
    edited 2015-09-16 - 18:46:07
    Seairth wrote: »
    Actually, there is no GETI at the moment. Regardless of what they are called, that is what I was asking about further. Could the opcode for SETDS be instead used for GETI//GETR?

    Since we moved the CCCC bits to the top of the instruction, we were able to get rid of SETCCCC. I figured that SETDS was kind of superflous, too, so I got rid of it. That opened two instruction spaces. I added in SEUSSF and SEUSSR which were from the Prop2-Hot. They don't take much logic and they provide a forward and reverse bit-position-and-polarity-change function. These are kind of silly instructions, but they'll provide simple means to obfuscate data or create pseudo-random numbers from counters, etc:
    // seussf
    // !0>11>!25>!29>4>!27>10>21>1>!5>19>!2>!18>!16>13>!8>28>14>7>!30>6>!20>15>23>!31>!22>!9>26>17>12>!3>!24>0
    
    wire [31:0] seussf = { s[23],  s[7],  !s[25], !s[8],   s[4],  !s[9],   s[11], !s[3],
                           s[15], !s[31],  s[10],  s[6],  !s[5],  !s[2],   s[26], !s[18],
                          !s[20],  s[28], !s[16],  s[17], !s[0],  !s[27], !s[22],  s[13],
                           s[14], !s[30],  s[1],  !s[29],  s[12],  s[19],  s[21], !s[24] };
    
    
    // seussr
    // 0<!11<25<!29<!4<27<!10<21<1<5<!19<2<!18<!16<!13<8<!28<14<7<30<!6<20<!15<23<31<!22<!9<!26<17<12<3<!24<!0
    
    wire [31:0] seussr = {!s[22], !s[6],  !s[4],   s[14], !s[10],  s[17], !s[29], !s[0],
                           s[31], !s[9],   s[1],  !s[15],  s[2],  !s[16],  s[12], !s[13],
                           s[23],  s[7],   s[8],   s[3],   s[25],  s[21], !s[26], !s[28],
                           s[30],  s[20], !s[19],  s[27], !s[24], !s[18],  s[5],  !s[11] };
    
    
  • Okay. Is there instruction space to add a GETI/GETR? It seems to me that having a SETI/SETR and a result field in ALTDS is weakened by not having an instruction to easily extract the RRRRRRRRR value back out like you can with GETD and GETS. If not, it's not a big deal, as the same can be accomplished in just a few instructions.
    MOV regR, regDS
    SHR regR, #19
    AND regR, #$1FF
    
  • It's not often required to get back the instruction.

    However, a number of times I have found the use of MOVI is nice to be able to change an instruction within a common subroutine to alter its operation (usually reverse its operation).

    Since the CCCC bits have moved to 28:31 the SETCCCC (was not in the P1) is no longer required since we can do this with the nibble(?) instruction.

    Chip,
    If there are instruction space worries, perhaps GETD & GETS could share an instruction code using the "I" bit to select either GETD or GETS ???
    GETD D,#S (I=1)
    GETS D,#S (I=0)
    It doesn't seem much of a restriction to make the "S" field always immediate.
    Alternately the "C" flag could be used as I don't see a lot of use setting the C flag based on the result.
    The "Z" flag should be retained to test the result for zero.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Seairth wrote: »
    Okay. Is there instruction space to add a GETI/GETR? It seems to me that having a SETI/SETR and a result field in ALTDS is weakened by not having an instruction to easily extract the RRRRRRRRR value back out like you can with GETD and GETS. If not, it's not a big deal, as the same can be accomplished in just a few instructions.
    MOV regR, regDS
    SHR regR, #19
    AND regR, #$1FF
    

    There are no more instruction spaces in that ALU block. I could get rid of SEUSSF or SEUSSR to make room for GETI/GETR, but I'm not sure I want to do that. I don't know that reading that field would be that necessary. The same could be said of GETD/GETS, but they are much more likely to be needed.
  • Cluso99 wrote: »
    It's not often required to get back the instruction.

    However, a number of times I have found the use of MOVI is nice to be able to change an instruction within a common subroutine to alter its operation (usually reverse its operation).

    Since the CCCC bits have moved to 28:31 the SETCCCC (was not in the P1) is no longer required since we can do this with the nibble(?) instruction.

    Chip,
    If there are instruction space worries, perhaps GETD & GETS could share an instruction code using the "I" bit to select either GETD or GETS ???
    GETD D,#S (I=1)
    GETS D,#S (I=0)
    It doesn't seem much of a restriction to make the "S" field always immediate.
    Alternately the "C" flag could be used as I don't see a lot of use setting the C flag based on the result.
    The "Z" flag should be retained to test the result for zero.

    That could work, but it would create a great exception in how instructions are decoded. Also, C and Z are not available for those GETD/GETS instructions. They are in an ALU block that handles all the mux-type instructions and none of those return flags.
  • cgracey wrote: »
    Cluso99 wrote: »
    It's not often required to get back the instruction.

    However, a number of times I have found the use of MOVI is nice to be able to change an instruction within a common subroutine to alter its operation (usually reverse its operation).

    Since the CCCC bits have moved to 28:31 the SETCCCC (was not in the P1) is no longer required since we can do this with the nibble(?) instruction.

    Chip,
    If there are instruction space worries, perhaps GETD & GETS could share an instruction code using the "I" bit to select either GETD or GETS ???
    GETD D,#S (I=1)
    GETS D,#S (I=0)
    It doesn't seem much of a restriction to make the "S" field always immediate.
    Alternately the "C" flag could be used as I don't see a lot of use setting the C flag based on the result.
    The "Z" flag should be retained to test the result for zero.

    That could work, but it would create a great exception in how instructions are decoded. Also, C and Z are not available for those GETD/GETS instructions. They are in an ALU block that handles all the mux-type instructions and none of those return flags.
    Then it's not worth the trouble. In reality, there are probably better things to worry about than the GETI/GETD/GETS instructions. I didn't really miss them in P1.

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • CongaConga Posts: 49
    edited 2015-09-17 - 17:23:44
    Moved to separate thread:
    What are your expectations regarding SEUSSF and SEUSSR ?
    cgracey wrote: »
    I added in SEUSSF and SEUSSR which were from the Prop2-Hot. They don't take much logic and they provide a forward and reverse bit-position-and-polarity-change function. These are kind of silly instructions, but they'll provide simple means to obfuscate data or create pseudo-random numbers from counters, etc

    Hi Chip, hi all,

    What are your expectations regarding SEUSSF and SEUSSR ?

    I do not expect a proper PRNG, much less a cryptographically secure PRNG.

    Just that it would be nice to have a period (cycle length) of 2**30 or greater --- given that SEUSSF and SEUSSR operate on a 32-bit register (the PRNG state), that should be possible, right?

    Getting somewhat evenly distributed 32-bit values would also be nice, even if (maybe) the resulting sequence would fail some statistical tests on randomness.

    Determinism is not a limitation, is a feature: it's useful to have the ability to replicate an output sequence or a simulation run by using same seed 32-bit value.

    But the best part, that I have not seen outside P2, is having a pair of PRNG-like instructions, giving us the ability to "go back" in a pseudo-random sequence (using SEUSSR after SEUSSF, or vice-versa).

    Thanks!
  • Conga wrote: »
    What are your expectations regarding SEUSSF and SEUSSR ?

    Can you move that question to a separate thread? I'd hate for it to get lost inside a thread primarily related to ALTDS.

Sign In or Register to comment.