RDLUT/WRLUT with auto-incrementing address

As things stand, there is going to be awful lot of this
	rdlut	lut_data,lut_ptr	' or wrlut
	add	lut_ptr,#1

Would it be possible to post-increment PTRA/PTRB if S = $1F8/1F9 in RDLUT/WRLUT? The above code would then be
	rdlut	lut_data,ptra		' or wrlut/ptrb

For the software-only 640x480x256 HDMI, this would reduce a loop of 33 cycles to 31, a saving of 6% and shorter loops would benefit more. The TMDS encoding for rev B will be done in hardware, but that won't eliminate the wish/need to save every cycle possible when using the two LUT instructions.
Formerly known as TonyB
«1345

Comments

  • 128 Comments sorted by Date Added Votes
  • I will look into that today.
  • Whoa! What if the user doesn't want to post-increment? That should be something explicitly requested in the source code via a "ptra++". Which means having some kind of flag in the instruction encoding (like the one we already have for rdbyte/wrbyte/etc.). In principle this would be a nice thing, but do we really want to be making such big changes this late in the game?

    There's already the setq/rdlut combination for quickly filling the LUT, which is probably the most common use case.
  • The rule would be that if PTRA is used as the address in RD/WRLUT, it would always increment. Pretty low risk. Just something for people to be aware of as they program.
  • TonyB_TonyB_ Posts: 875
    edited November 8 Vote Up0Vote Down
    Thanks, Chip. People could use the 510 other registers to avoid the post-increment. The use-case here is read a long from LUT, process it, then read the next long, etc. (or process, then write, etc.) in a loop as fast as possible.
    Formerly known as TonyB
  • There is no chance someone might be using PTRA with RD/WRLUT but not want the auto increment feature? At the very least the assembler should probably require a "++" for this instruction form and issue an error if it is not present even though it doesn't actually change the binary encoding of the instruction.
  • Related to the soft HDMI, will the following code (a) work and (b) add 40 to ptrb?
    	setq2	#10-1
    	wrlong	first_lut,ptrb++
    
    Formerly known as TonyB
  • I think it will just add one.
  • The rule should be that if either PTRA or PTRB are used by RD/WRLUT, they will auto-increment.
  • TonyB_TonyB_ Posts: 875
    edited November 8 Vote Up0Vote Down
    cgracey wrote: »
    TonyB_ wrote: »
    Related to the soft HDMI, will the following code (a) work and (b) add 40 to ptrb?
    	setq2	#10-1
    	wrlong	first_lut,ptrb++
    

    I think it will just add one.

    Is incrementing ptrx every write not possible?
    Formerly known as TonyB
  • cgracey wrote: »
    The rule should be that if either PTRA or PTRB are used by RD/WRLUT, they will auto-increment.

    Yes, that was my intention.
    Formerly known as TonyB
  • David Betz wrote: »
    There is no chance someone might be using PTRA with RD/WRLUT but not want the auto increment feature? At the very least the assembler should probably require a "++" for this instruction form and issue an error if it is not present even though it doesn't actually change the binary encoding of the instruction.

    Yes, I agree, you do not want any invisible ++ , so the Assembler needs to be explicit here.
  • TonyB_ wrote: »
    Is incrementing ptrx every long not possible?

    I'm sure it's possible. It just hurts to think about. You are talking about SETQ(2)+RD/WRLONG cases, right?
  • TonyB_TonyB_ Posts: 875
    edited November 8 Vote Up0Vote Down
    cgracey wrote: »
    TonyB_ wrote: »
    Is incrementing ptrx every long not possible?

    I'm sure it's possible. It just hurts to think about. You are talking about SETQ(2)+RD/WRLONG cases, right?

    Yes, the fast block moves, read and write. Again it's to avoid an extra instruction to adjust the pointer.

    If both of my suggestions here were implemented, that would save 400 cycles per line for soft 640x480x256 HDMI and there are only 8000 in total.

    EDIT:
    ~7500 of the 8000 have been used, so a saving of 400 would almost double the time available for other stuff.
    Formerly known as TonyB
  • ersmith wrote: »
    In principle this would be a nice thing, but do we really want to be making such big changes this late in the game?

    I think that its absolutely critical that the instruction set is stable, and also perceived as stable, during this next period where we test with real silicon.

    What is being proposed is 'nice' and undoubtedly useful, but the action involved undermines testing (which should uncover other issues needing attention). We've seen this play out several times already, most recently with Peter and Ray's ROM testing.

    There will likely be an opportunity to gather up and slip this stuff in, but this *really* has to be after a good number of people have tested with the P2 evaluation boards.
  • cgracey wrote: »
    The rule would be that if PTRA is used as the address in RD/WRLUT, it would always increment. Pretty low risk. Just something for people to be aware of as they program.

    Umm... so in order to make things easier for programmers, we're going to require them to remember an additional special case? This really seems dubious to me. The more special cases, exceptions, etc. in the instruction set, the harder the chip is to program.

    Moreover, PTRA and PTRB aren't just any registers. They're very useful (because there are many addressing modes for these in rdlong/wrlong/rdbyte/wrbyte/etc.) and so likely to be heavily used. Hence a lot of people are likely to be tripped up by instructions using them in a non-standard way.

    Worse, tools are going to be made more complicated. Every compiler for the P2 is going to have to special case these instructions, and it's going to be a real pain because PTRA and/or PTRB are going to be actively in use (e.g. fastspin uses PTRA for the stack pointer) and so code is going to be generated using these.

    I *strongly* oppose this change. Please, if you're going to make a register auto-increment, use a new instruction or set some bit in the instruction to indicate that it's being handled differently. Or use a new hardware register.
  • I think I'm OK with this one change...

    PTRA/B can get modified in other instructions, so why not here too.

    What are the chances you'd want the same PTRA value for both hub/cog and LUT access?
    Prop Info and Apps: http://www.rayslogic.com/
  • ersmith wrote: »
    cgracey wrote: »
    The rule would be that if PTRA is used as the address in RD/WRLUT, it would always increment. Pretty low risk. Just something for people to be aware of as they program.

    Umm... so in order to make things easier for programmers, we're going to require them to remember an additional special case? This really seems dubious to me. The more special cases, exceptions, etc. in the instruction set, the harder the chip is to program.

    Moreover, PTRA and PTRB aren't just any registers. They're very useful (because there are many addressing modes for these in rdlong/wrlong/rdbyte/wrbyte/etc.) and so likely to be heavily used. Hence a lot of people are likely to be tripped up by instructions using them in a non-standard way.

    Worse, tools are going to be made more complicated. Every compiler for the P2 is going to have to special case these instructions, and it's going to be a real pain because PTRA and/or PTRB are going to be actively in use (e.g. fastspin uses PTRA for the stack pointer) and so code is going to be generated using these.

    I *strongly* oppose this change. Please, if you're going to make a register auto-increment, use a new instruction or set some bit in the instruction to indicate that it's being handled differently. Or use a new hardware register.

    There are no spare instructions slots now, nor spare opcode bits in RD/WRLUT. You're right, PTRA/B are special registers and if compilers use them already then other registers would have to be used for RD/WRLUT which would execute exactly the same as now.
    Formerly known as TonyB
  • TonyB_ wrote: »
    Related to the soft HDMI, will the following code (a) work and (b) add 40 to ptrb?
    	setq2	#10-1
    	wrlong	first_lut,ptrb++
    

    (b) PREB would increment by 4.
    Melbourne, Australia
  • ozpropdev wrote: »
    TonyB_ wrote: »
    Related to the soft HDMI, will the following code (a) work and (b) add 40 to ptrb?
    	setq2	#10-1
    	wrlong	first_lut,ptrb++
    

    (b) PREB would increment by 4.

    Thanks for the info. +4 is not what users would expect at all and it needs fixing. When one orders ++, one expects to be served ++ !
    Formerly known as TonyB
  • Rayman wrote: »
    PTRA/B can get modified in other instructions, so why not here too.
    Not silently... if they are modified it's explicit (the programmer asks for the modification by writing ++ or -- before or after the PTRA/B reference).
    What are the chances you'd want the same PTRA value for both hub/cog and LUT access?

    Pretty high? If PTRA is the stack pointer, it's pretty likely that you might want to copy a value from the HUB stack to LUT. Or if you're copying from an array in HUB to LUT, you might want to use PTRB to index the array.

    Again, the general idea (have a way to auto-increment a pointer that's reading into LUT) is not a bad one. But silently modifying a pointer that the user hasn't asked to modify, and that no other instruction modifies? That's ugly. Do *something* to indicate this behavior is special. Use the wc bit on the instruction to indicate an auto-increment. Or write a magic value with SETQ or SETQ2 sometime before the copy loop. Or, have some new registers which always auto-increment when dereferenced.


  • Is the RDLUT/WRLUT post increment only needed to achieve a soft HDMI, and not needed for the sreamer HDMI mode?
    I'm a bit foggy on this HDMI stuff.
    Melbourne, Australia
  • ozpropdev wrote: »
    Is the RDLUT/WRLUT post increment only needed to achieve a soft HDMI, and not needed for the streamer HDMI mode?
    I'm a bit foggy on this HDMI stuff.

    It would help the soft HDMI considerably but that's just an example, a good one mind you. It would help with hard HDMI and sprites. It would help anywhere and everywhere. Don't forget RDLUT takes three cycles, not two.
    Formerly known as TonyB
  • roglohrogloh Posts: 855
    edited November 9 Vote Up0Vote Down
    TonyB_ wrote: »
    ozpropdev wrote: »
    TonyB_ wrote: »
    Related to the soft HDMI, will the following code (a) work and (b) add 40 to ptrb?
    	setq2	#10-1
    	wrlong	first_lut,ptrb++
    

    (b) PTEB PTRB would increment by 4.

    Thanks for the info. +4 is not what users would expect at all and it needs fixing. When one orders ++, one expects to be served ++ !

    Ignoring soft HDMI (I think we can live with the LUT addressing limitations), I think block transfers of data to/from HUB from COGRAM should be optimized if possible with the pointer registers. This will be a common thing do to for lots of code reading and writing in data in bursts. This is a form of memcpy / memmove between memory regions and it will be widely used.

    So I am more concerned with SETQ and PTRA++/PTRB++ use with WRLONG / RDLONG not incrementing the PTRA/PTRB fully, if that is how it behaves now. I would have expected PTRA would increment by the number of transfers requested*size if you use some ++ form. If it is just by one transfer that seems unexpected.
  • My guess is the block move function is simply setting it's own internal pointer to #/S.

    The block move also has to handle the immediate #S scenario
    	SETQ2	#10-1
    	RDLONG	first_lut,#$20
    

    Melbourne, Australia
  • rogloh wrote: »
    TonyB_ wrote: »
    ozpropdev wrote: »
    TonyB_ wrote: »
    Related to the soft HDMI, will the following code (a) work and (b) add 40 to ptrb?
    	setq2	#10-1
    	wrlong	first_lut,ptrb++
    

    (b) PTEB PTRB would increment by 4.

    Thanks for the info. +4 is not what users would expect at all and it needs fixing. When one orders ++, one expects to be served ++ !

    Ignoring soft HDMI (I think we can live with the LUT addressing limitations), I think block transfers of data to/from HUB from COGRAM should be optimized if possible with the pointer registers. This will be a common thing do to for lots of code reading and writing in data in bursts. This is a form of memcpy / memmove between memory regions and it will be widely used.

    So I am more concerned with SETQ and PTRA++/PTRB++ use with WRLONG / RDLONG not incrementing the PTRA/PTRB fully, if that is how it behaves now. I would have expected PTRA would increment by the number of transfers requested*size if you use some ++ form. If it is just by one transfer that seems unexpected.

    Well, we have to live with how things are for rev A, but not for rev B! The biggest cycle saving (320) in our 640x480x256 loop would be due to the RDLUT address auto-incrementing and from the timing viewpoint I'm much less concerned about SETQ+WRLONG incrementing PTRx correctly as the cycle saving is a lot less (64-80 probably).

    This is not about one particular application, though.
    Formerly known as TonyB
  • ozpropdevozpropdev Posts: 2,287
    edited November 9 Vote Up0Vote Down
    Actually thinking about it you can do this little trick.
    		setq2	#10-1
    		rdlong	0,ptrb++[10]
    
    PTRB increments +40.
    Melbourne, Australia
  • Rev B probably won't need to worry about TMDS encoding for graphics portions of the line, though soft HDMI in general will still be useful for that device too and would remain.

    Perhaps POPLUT/PUSHLUT would be a good instruction pair to have and could be leveraged on reading LUT data to give for automatic address incrementing but I'm not advocating it hard right now. A read using POPLUT could potentially be just 3 instead of 5 cycles with the following increment operation no longer required.
  • ozpropdev wrote: »
    Actually thinking about it you can do this little trick.
    		setq2	#10-1
    		rdlong	0,ptrb++[10]
    
    PTRB increments +40.

    Tautological but it saves two cycles. Auto-increment RD/WRLUT with PTRx and we're done! :)
    Formerly known as TonyB
  • roglohrogloh Posts: 855
    edited November 9 Vote Up0Vote Down
    Cool ozpropdev, so you actually tested this on real P2 HW and it behaves that way?
  • roglohrogloh Posts: 855
    edited November 9 Vote Up0Vote Down
    TonyB_ wrote: »
    This is not about one particular application, though.

    Yeah I was coming at it somewhat less from a performance aspect more from a general expectation of what the opcodes would be expected to do. If you setup X transfers and ask for auto increment with PTRA++, in my view you'd kind of want to increment by the actual number of transfers done, not just one transfer worth. I see ozpropdev found something useful to help improve performance, but that may only work for fixed sizes. Transfer sizes might depend on the application and be totally dynamic, even during run time as setq takes register values as well as constants.

    But if this is not something simple to resolve, it shouldn't go into rev B, far too risky.
Sign In or Register to comment.