P2 Tricks, Traps & Differences between P1 (Reference Material Only)

13»

Comments

  • Peter JakackiPeter Jakacki Posts: 8,918
    edited 2020-02-07 - 09:06:35
    ozpropdev wrote: »
    SPAN IO pins feature

    From the docs
    DIRx/OUTx/FLTx/DRVx can now work on a span of pins (+D[10:6] pins).
    Prior SETQ overrides D[10:6].

    WRPIN/WXPIN/WYPIN/AKPIN can now work on a span of pins (+S[10:6] pins).
    Prior SETQ overrides S[10:6].

    Be aware that this feature cannpnt cross the PinA/PinB boundary and
    wraps within the 32 pin group.

    For example the following code configures pins 30,31,0,1 not 30,31,32,33
    		setq	#3
    		wrpin	##%011_00_00000_0,#30 '150k pulldown
    		setq	#3
    		drvl	#30 
    

    The way I read it and taking into account the fact that SETQ would be needed to specify more than 32 pins, I took it that it did span, but alas I tested it and it did not.

    Check pin states where h and l are input states and H and L are output states, then from pin 30 set 8 pins low and check.
    TAQOZ# .io ---  0:hlhhhhhh 8:hhhhhhhh 16:hhhhhhhh 24:hhhhhhhh 32:hlhhhhhh 40:hhhhhhhh 48:lllllhhh 56:LhlLLLHL ok
    TAQOZ# 30 8 PINS LOW ---  ok
    TAQOZ# .io ---  0:LLLLLLhh 8:hhhhhhhh 16:hhhhhhhh 24:hhhhhhLL 32:hlhhhhhh 40:hhhhhhhh 48:lllllhhh 56:LhlLLLHL ok
    

    So SETQ cannot be used to specify more than 32 pins anyway.

    EDIT: This is also a perfect way to sync smartpins. I tried setting P24 for 8 pins as a PIN specifier and then set them to NCO mode at 1 MHZ, They were all perfectly synch'd.
    24 8 PINS PIN 1 MHZ
    
  • ozpropdev wrote: »
    SPAN IO pins feature

    From the docs
    DIRx/OUTx/FLTx/DRVx can now work on a span of pins (+D[10:6] pins).
    Prior SETQ overrides D[10:6].

    WRPIN/WXPIN/WYPIN/AKPIN can now work on a span of pins (+S[10:6] pins).
    Prior SETQ overrides S[10:6].

    Be aware that this feature cannpnt cross the PinA/PinB boundary and
    wraps within the 32 pin group.

    For example the following code configures pins 30,31,0,1 not 30,31,32,33
    		setq	#3
    		wrpin	##%011_00_00000_0,#30 '150k pulldown
    		setq	#3
    		drvl	#30 
    

    This is unfortunate. This must be a bug in the Verilog.
    Wonder if Chip knows about this...
  • cgraceycgracey Posts: 12,382
    edited 2020-02-07 - 17:26:11
    It was not possible to involve both A and B ports in the pin span, since the data-forwarding circuitry only handles one 32-bit register. The bit span wraps, as well.

    So, It's not a bug, but it's not really a feature, either.
  • This is a case where I'd wonder about violating the RISC philosophy and having this instruction take 4 (or more) clock cycles, so as to give the expected result.
  • cgraceycgracey Posts: 12,382
    edited 2020-02-07 - 20:44:15
    > @Rayman said:
    > This is a case where I'd wonder about violating the RISC philosophy and having this instruction take 4 (or more) clock cycles, so as to give the expected result.

    We could have done it all in 2 clocks, but it would have grown the data-forwarding circuit immensely. Didn't seem like it was worth doing.
  • RaymanRayman Posts: 10,212
    edited 2020-02-08 - 11:19:15
    I see the spreadsheet notes this behavior for some instructions.
    But, not for BITH, BITL, etc.
    Are they the same way?


    scratch that... Obviously not the same type of instruction...

    I guess this is another thing that should be added to the docs at some point...
  • P3 will need 64 bit register, but then we might get more then 64 pins and the problem is just moved.

    But since all pins are equal in opposite to other MCs, one can design the pinout on the board to avoid the overlap.
  • Rayman wrote: »
    ozpropdev wrote: »
    SPAN IO pins feature

    From the docs
    DIRx/OUTx/FLTx/DRVx can now work on a span of pins (+D[10:6] pins).
    Prior SETQ overrides D[10:6].

    WRPIN/WXPIN/WYPIN/AKPIN can now work on a span of pins (+S[10:6] pins).
    Prior SETQ overrides S[10:6].

    Be aware that this feature cannpnt cross the PinA/PinB boundary and
    wraps within the 32 pin group.

    For example the following code configures pins 30,31,0,1 not 30,31,32,33
    		setq	#3
    		wrpin	##%011_00_00000_0,#30 '150k pulldown
    		setq	#3
    		drvl	#30 
    

    This is unfortunate. This must be a bug in the Verilog.
    Wonder if Chip knows about this...
    Rayman wrote: »
    This is a case where I'd wonder about violating the RISC philosophy and having this instruction take 4 (or more) clock cycles, so as to give the expected result.

    IMHO this is not a bug, but the standard (and quite logical) way things have been done on any computer, microprocessor, or microcontroller I have worked with. Having such a feature would not only make the logic circuitry more complicated, it would also open up a whole new set of potential bugs.
  • Think I just found a bug in a code related to SHR...

    I assumed that SHR with a source value >31 would result in destination:=0.
    But, seems this type of instruction only looks at the lower 5 bits.

    Wouldn't it be better if SHR with source>31 made result zero?
  • Rayman wrote: »
    Think I just found a bug in a code related to SHR...

    I assumed that SHR with a source value >31 would result in destination:=0.
    But, seems this type of instruction only looks at the lower 5 bits.

    Wouldn't it be better if SHR with source>31 made result zero?

    There are many instructions that have unused source bits but I would not call that a bug. To have it handle the unused bits requires extra logic and do you really want it to work that way anyway?

    I just realized that I had marked the source fields of these instructions in my formatted copy of the instruction sheet as xxxxSSSSS, but that is only correct for immediate mode, or more correctly only 5 bits of the source data.
  • Rayman wrote: »
    Think I just found a bug in a code related to SHR...

    I assumed that SHR with a source value >31 would result in destination:=0.
    But, seems this type of instruction only looks at the lower 5 bits.

    Wouldn't it be better if SHR with source>31 made result zero?

    If it's a bug, it's a bug shared by x86, ARM, and RISC-V -- it seems to be pretty standard in microprocessors to use only the lower 5 bits of the shift amount. I agree that it's unfortunate (it would make more sense to output 0 for values > 31) but the P2 is in good company there.
  • It's only a bug when buggy software trips up on it. ;)
  • Rayman wrote: »
    Think I just found a bug in a code related to SHR...

    I assumed that SHR with a source value >31 would result in destination:=0.
    But, seems this type of instruction only looks at the lower 5 bits.

    Wouldn't it be better if SHR with source>31 made result zero?

    I am pretty confident that this is the same behaviour on P1.
  • Wuerfel_21Wuerfel_21 Posts: 562
    edited 2020-02-10 - 12:12:21
    ersmith wrote: »
    If it's a bug, it's a bug shared by x86, ARM, and RISC-V -- it seems to be pretty standard in microprocessors to use only the lower 5 bits of the shift amount. I agree that it's unfortunate (it would make more sense to output 0 for values > 31) but the P2 is in good company there.

    Hitachi/Renesas/whoever-owns-it-this-week SuperH processors (If you know nothing about them, just know that narrow loads/stores are sign-extended by default to be scared of them for life) do something like that with their SHLD instructions - if you shift left by -32, you get zero... (yet it still only looks at the bottom five bits and the sign bit, so -33 is the same as -1). This whacky nonsense, in addition to the fact that that is the only dynamic shift instruction (aside from SHAD, which does arithmetic shifts, you just get fixed 1/2/8/16 bit shifts and a 1-bit rotate, oof) makes bitwise ops real slow on those, lol.
Sign In or Register to comment.