streamers/absolute addressing

rjo__ · 2015-10-21 22:15

I am not myself today and have fiddled with this far too long:) The idea is to transfer the lut to an absolute location in hubram... and then transfer it back again. I am using setq for the hub to lut transfer
and a rep loop for the lut to hub transfer, because I read that $FF bytes in the lut are not copied to hub ... so as to serve a masking role. I have tried a bunch of variants... here is a good example of what doesn't work for me.


hub2lut         SETQ2   #511                    'transfer  Hubram   to lut        
                rdlong  lutstart,##$3000     
                ret


lut2hub          
                mov z,#0
                mov zz,##$3000
                rep @.endtrans,##512
                
                rdlut    x, z 
                wrlong  x,zz
                add   z,#1
                add   zz,#1
.endtrans                


               
                ret

Seairth · 2015-10-21 22:31

Your "add zz, #1" needs to be "add zz, #4".

rjo__ · 2015-10-21 23:30

Thank you. I suddenly feel much better:)

I am now getting meaningful data slung around... but when I do lut->hub-> lut... my data is being shifted down by about -77 locations.

So for example... the original data at lut index 80 is (byte 3->0)=0,0,22,197... after sending it to the hub and back... this value showed up in lut index 3.

And if I set the number of reps to ##512... my P2V goes completely nuts:)

rjo__ · 2015-10-21 23:57

here

Electrodude · 2015-10-22 00:18

What is the point of the $FF feature? It seems like it will do more trouble than good, which has been proven true here. It should at least be disableable.

Seairth · 2015-10-22 00:37

I haven't run the code, but shouldn't line 43 (mov z,#$1FF) be moved to the beginning of send_lut (and similarly for rcv_lut, though that doesn't look like your done writing it yet).

rjo__ · 2015-10-22 01:06

That line is unnecessary... z is set above and is reset every time through loop1... but I think you are on to something.... it appears that lut2hub (which uses z) returns to loop1(which resets z) before the repeat loop is done... that would make sense. Might not be right but it does make sense. I have to stop now and look at it later.

Thanks

Rich

rjo__ · 2015-10-22 01:20

electrodude...

I would make exactly the same argument, based on heuristics. Many people are going to see setq and setq2 and assume they are the same... I like masking as selectable for both setq and setq2... but I'm sure Chip thought about this a long time ago. I want a P2 that Chip absolutely loves. In my mind, if he has something in mind for the masking, God bless him and masking:)

jmg · 2015-10-22 01:27

rjo__ wrote: »

....because I read that $FF bytes in the lut are not copied to hub.

Did you actually confirm that ?
Sounds a little strange, but may be ok if that is an optional feature.

rjo__ · 2015-10-22 01:44

Good point, no I didn't confirm it. And thinking about it... I did see $FF's coming back. What a muddle headed day.

Seairth · 2015-10-22 02:13

jmg wrote: »

rjo__ wrote: »

....because I read that $FF bytes in the lut are not copied to hub.

Did you actually confirm that ?
Sounds a little strange, but may be ok if that is an optional feature.

According to Chip's document, you can use SETQ2 (instead of SETQ) with WRLONG to write only non-FF values to the hub. There is no variant for copying from LUT to HUB.

Electrodude · 2015-10-22 02:13

I remember reading about the $FF business too. I'm pretty sure Chip mentioned it fairly recently, but I could only find this post from May 2014: forums.parallax.com/discussion/comment/1269398/#Comment_1269398

EDIT: That post says filter mode is optional.

EDIT: That post was long before lut-hub block transfer was implemented...

jmg · 2015-10-22 02:39

Seairth wrote: »

According to Chip's document, you can use SETQ2 (instead of SETQ) with WRLONG to write only non-FF values to the hub. There is no variant for copying from LUT to HUB.

A fairly cryptic suffix - '2' means the optional Skip write if 0xFF mode.

Electrodude · 2015-10-22 03:09

Why $FF? What if I want $00? What if I want it written only if the high bit is 0? Drop the whole thing and do it in software, or overcomplicate the hardware and give it a full masked test parameter, so that (somehow) given parameter bytes A and B it only writes a byte X if X & A == B.

Block lut -> hub transfers would be very useful not only for bulk hub -> hub move but for cases where lut is used as scratch pad ram.

Seairth · 2015-10-22 03:14

Electrodude wrote: »

Why $FF? What if I want $00? What if I want it written only if the high bit is 0? Drop the whole thing and do it in software, or overcomplicate the hardware and give it a full masked test parameter, so that (somehow) given parameter bytes A and B it only writes a byte X if X & A == B.

Block lut -> hub transfers would be very useful not only for bulk hub -> hub move but for cases where lut is used as scratch pad ram.

It sounds like we need a SETQ3!

Electrodude · 2015-10-22 03:39

Seairth wrote: »

Electrodude wrote: »

Why $FF? What if I want $00? What if I want it written only if the high bit is 0? Drop the whole thing and do it in software, or overcomplicate the hardware and give it a full masked test parameter, so that (somehow) given parameter bytes A and B it only writes a byte X if X & A == B.

Block lut -> hub transfers would be very useful not only for bulk hub -> hub move but for cases where lut is used as scratch pad ram.

It sounds like we need a SETQ3!

I would say SETQ2 on WRLONG should be made to do the same as on RDLONG. Another instruction can be added to set the transfer mask and target and save them in hidden registers:

WRMASK mask, target ' sets write mask and target, need not precede every write

SETQ2    nlongs ' write nlongs longs from lutram to hubram
WRLONG  lutaddr, hubaddr

This should also work for cogram via SETQ.

This would allow block hub writes from either cogram or lutram and allows for custom write masks for both cogram and lutram.

cgracey · 2015-10-22 05:39

There is no lut-to-hub block transfer using WRLONG, only cog-to-hub with optional $FF write skipping. This write skipping feature was Bagger's idea. It's good for doing byte pixel sprite overlays, where $FF values leave the background intact.

jmg · 2015-10-22 06:11

cgracey wrote: »

There is no lut-to-hub block transfer using WRLONG, only cog-to-hub ...

Having it work both ways has the appeal of symmetry - is there a high cost to doing it both ways ?

evanh · 2015-10-22 06:38

Lol, I'm gonna have to say it ... You're stating the obvious, JMG.

I think Chip answered a similar question a month or so back when he added SETQ2, but I can't remember what was said now.

evanh · 2015-10-22 06:41

Probably just a case of it was easy to tack on in one direction only, as in he just hasn't tried to solve for WRLONG.

cgracey · 2015-10-22 14:33

My thinking was that the LUT is useful for lookup and code. Data needs to go into it, but not come out of it, so much.

I I agree that it would be better to have SETQ2 cause WRLONG to write LUT to hub.

Seairth · 2015-10-22 15:02

Maybe you could use C/Z in SETQ and SETQ2 to implement general masking (in either direction):

CZ
00 : No mask (SETQ/SETQ2)
01 : Mask out $0000_0000 (SETQMZ/SETQMZ2)
10 : Mask out $FFFF_FFFF (SETQMF/SETQMF2)
11: ?? (No mask)

Or something like that...

Rayman · 2015-10-22 15:20

I thought I just read that the only way in or out from LUT was with WRLUT and RDLUT....

Can you really WRLONG and RDLONG with LUT?

If there's enough bits to make LUT source and destination addressable, way can't we just use "MOV" on it?

I think I'm confused...

potatohead · 2015-10-22 15:30

Make the "11" case, "Only write ones", which would also be useful for a variety of graphics operations that would need to leave a background image intact at lower bit depths.

Basically, logical "OR" write mode.

Rayman · 2015-10-22 15:53

I think $ff is fine as it allows bitblt with transparency. Very good for 8bpp graphics with bitmap

potatohead · 2015-10-22 15:56

Yeah, I only tossed it out there on the off chance Chip was going to flesh out the options Seairth put out there.

Rayman · 2015-10-22 16:09

Would be better of course if index could be arbitrary...

Seairth · 2015-10-22 16:29

Rayman wrote: »

I thought I just read that the only way in or out from LUT was with WRLUT and RDLUT....

Can you really WRLONG and RDLONG with LUT?

If there's enough bits to make LUT source and destination addressable, way can't we just use "MOV" on it?

I think I'm confused...

Right now, you have to use RDLUT/WRLUT to move longs between cog and lut memory. Additionally, you can use SETQ2 with RDLONG to load lut memory directly from hub memory. There is no mechanism to use WRLONG between lut and hub. And we can't use MOV with LUT because it's conceptually located at $200-3FF.

The current suggestion is:

* Allow SETQ2 to be used with WRLONG to transfer from lut to hub. However, as this is already used for moving masked data from cog to hub, so this leads to the next part of the suggestion:
* Use C/Z bits in SETQ and SETQ2 to provide more general-purpose masking (in either direction between cog/hub and lut/hub).

cgracey · 2015-10-22 17:11

Seairth wrote: »

Rayman wrote: »

I thought I just read that the only way in or out from LUT was with WRLUT and RDLUT....

Can you really WRLONG and RDLONG with LUT?

If there's enough bits to make LUT source and destination addressable, way can't we just use "MOV" on it?

I think I'm confused...

Right now, you have to use RDLUT/WRLUT to move longs between cog and lut memory. Additionally, you can use SETQ2 with RDLONG to load lut memory directly from hub memory. There is no mechanism to use WRLONG between lut and hub. And we can't use MOV with LUT because it's conceptually located at $200-3FF.

The current suggestion is:

* Allow SETQ2 to be used with WRLONG to transfer from lut to hub. However, as this is already used for moving masked data from cog to hub, so this leads to the next part of the suggestion:
* Use C/Z bits in SETQ and SETQ2 to provide more general-purpose masking (in either direction between cog/hub and lut/hub).

The masking only works going into hub, since it has byte-level write control. Cog and LUT are long-only.

Rayman · 2015-10-22 17:15

Ok. Thanks.

I think I see that you can use SETQ or SETQ2 with rdlong to load LUT with one long per clock.

Need to think about how SETQ2 could be used in practice...

rjo__ · 2015-10-22 18:40

I'm not as foggy today as yesterday, but I wouldn't say that I'm exactly sharp today either;)

Here is a code snippet that attempts to copy hub longs to the lut... twice in a row.
First it uses a repeat loop... which works fine... then it uses setq2... not so good. If I comment out only the setq2 line... everything is ok. If I comment out only the rep line but leave setq2... not so good.

they should do exactly the same thing...twice.

hub2lut         
                mov hubaddr,##30000
                mov  lutaddr,#0
                rep @.endtransH2L,#511
                
                rdlong  x,hubaddr
                wrlut   x,lutaddr
                add lutaddr,#1
                add hubaddr,#4

                
.endtransH2L

                mov lutaddr,#0
                mov hubaddr,##30000

                SETQ2   #511                    'transfer 511+1  Hubram   to lut        
                rdlong  lutaddr,hubaddr    
                
                ret

but they don't

streamers/absolute addressing

Comments