Shop OBEX P1 Docs P2 Docs Learn Events
P2 Bit(s) Manipulation Instructions — Parallax Forums

P2 Bit(s) Manipulation Instructions

Cluso99Cluso99 Posts: 18,069
edited 2013-12-24 11:08 in Propeller 2
Premised on the assumption that Chip is willing to add a few simple instructions, if they are worthy, I have started this thread to discuss some possibilities.

Currently, other than the extension of SETZC, and perhaps the addition of GETZC, I have no real opinions as to the usefulness of these new ones.
So, lets discuss these and any others. Perhaps there is some killer instructions lurking, just waiting to be discovered and perhaps added...

Bit Pairs

Currently we have instructions that can manipulate individual bits, nibbles, bytes and words.

We are missing pairs (2 bits) although we do have SETZC from D[1:0] and I have suggested this be extended to be able to set z and c from any pair of bits.
I didn't find a converse instruction GETZC where D[1:0] are set by Z & C, but it would be nice.

Otherwise, these two instructions may be nice...
GETPAIR D,S/#,#0..31
SETPAIR D,S/#,#0..31
By utilising the CCCC bits, instruction space may be able to be found.

I have also suggested some bit pair pin instructions that Chip has thought were nice. These may aid their usefulness.

Are there 3 bit instructions that would aid video modes too???

Bit(s) Insertion

Perhaps a bit insert instruction might be useful?

INSERT D,S/#,#0..1
where S = ppppp_wwww; ppppp = lowest bit position to start insertion point; wwww = number of bits to insert; #0..1 = insert zeros or ones

By using this instruction, it may be followed by AND, OR, XOR, GETxxxx, to insert appropriate bits into a field.

The INSERT instruction replaces the following sequence (assuming ppppp=15, wwww=5 ie insert 5 bits at posn 15)
ROR orig,#15=5
SHL orig,#5
OR orig,#$1F 'optional if inserted bits need to be "1"
ROL orig,#15
Typically this would then be followed with
OR/XOR/AND/ANDN orig,bits

Would this instruction be useful?

Variable length bit copy/insertion

Perhaps the following could be useful to get some bit(s) from one long to another...

This would require the ALU result register to be extended to be 64 bits wide to hold resultant bit shifts. But, to the user, only the existing 32 bits do anything. The other 32 bits hold the discarded bits from the normal instructions ROL/ROR/SHL/SHR.

A new instruction is added that can pick up these "discarded" bits by a special pair of SHIFT instructions...

SHLX D,S/#
SHRX D,S/#

These instructions are identical to the SHL & SHR instructions except they shift in (from left or right), those bits previously discarded in a prior/previous ROL/ROR/SHL/SHR instruction.

Examples (only one direction shown)

SHR/ROR orig,#7 ' also copies rightmost "n"=7 bits into the extended ALU register
SHLX new,#7 ' shifts in from the left "n"=7 bits previously saved in the ALU register

This pair of instructions replaces this sequence
SHR/ROR orig,#7
MOV tmp,orig
AND tmp,#$3F 'extract lowest 7 bits
SHL new,#7 'shift left 7 bits
OR new,tmp 'add in lowest extracted 7 bits

Would these instructions be useful?

Comments

  • rjo__rjo__ Posts: 2,114
    edited 2013-12-24 04:14
    I really don't know for sure, and there are so many questions that will only be answered by the next configuration release, I'm not sure anyone can know. But if we are speculating on the usefulness of these changes to the display capabilities, then I think we have to look at the exact problem that we are trying to solve. Right now the quickest way to sling data around is through XFR. XFR allows you to use the SDRAM with high enough throughput to feed data to the VID.


    So, as I understand the flow, in order to use SDRAM data through XFR, the data has to be in the format you want, prior to slinging and the Vid has to be setup to use that format as well. It seems to me that if you want to do these kinds of bit manipulations on the fly, you are going to create bottlenecks no matter how many clocks you use. I would think that the changes should be made to either XFR or to the Vid mechanism, if they can't presently do what you want:)

    Rich
  • ozpropdevozpropdev Posts: 2,791
    edited 2013-12-24 04:35
    If memory serves me right (not always reliable!), Chip mentioned something about modifying the XFR to transfer from HUB direct to AUX.
    This eliminates the double handling of pixel data via the COG ram. He hinted that this would be done in the background and could be
    polled for its status. That would speed things up greatly! :)

    @Cluso
    Interesting instruction ideas, need time to process them.... Head is already in holiday mode :):)
  • SeairthSeairth Posts: 2,474
    edited 2013-12-24 05:53
    I thought Chip was considering generalized get/set bit manipulation operations that would allow arbitrary bit lengths at a given offset. This would also replace current xxxNIB, xxxBYTE, xxxWORD, and MOVx instructions.


    See [post=1227325]Post 1227325[/post] for the last that Chip said on the topic (I think), and read back as far as [post=1227226]Post 1227226[/post] for the initial concept. Personally, I'd like to see up to 8 definable fields, but 4 would be a good start.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-12-24 11:08
    Seairth wrote: »
    I thought Chip was considering generalized get/set bit manipulation operations that would allow arbitrary bit lengths at a given offset. This would also replace current xxxNIB, xxxBYTE, xxxWORD, and MOVx instructions.


    See [post=1227325]Post 1227325[/post] for the last that Chip said on the topic (I think), and read back as far as [post=1227226]Post 1227226[/post] for the initial concept. Personally, I'd like to see up to 8 definable fields, but 4 would be a good start.
    Thanks for the links.

    I haven't done graphics, so don't know what would be helpful. I am just trying to pique interest to see if there is something amazing that could be simple for Chip to implement.
    Something that is repeated often in a loop.

    A complex bit move/mask/combine instruction specifying D & S and the combine info held in internal registers which would be set initially before the loop might be useful...
    SETFLD1 D/# 'combine posn+length
    SETFLD2 D/# 'combine posn+length
    ...
    MOVFLD D,S 'move fields defined by SETFLDn instructions from S into D
Sign In or Register to comment.