Shop OBEX P1 Docs P2 Docs Learn Events
streamers/absolute addressing - Page 2 — Parallax Forums

streamers/absolute addressing

2»

Comments

  • cgraceycgracey Posts: 14,208
    rjo__ wrote: »
    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

    After the SETQ2, the RDLONG instruction should be:

    RDLONG 0,hubaddr

    The D operand in RDLONG is the first register in LUT (0..511) that you want to receive the data into. In other words, it's direct, not indirect.
  • rjo__rjo__ Posts: 2,114
    excellent... so, a reference to D must be declared as a constant.

  • cgracey wrote: »
    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.

    That's fine. could you still use the CZ approach for masks, even if it's just cog->hub or LUT->hub?

    As an aside, it just occurred to me: can SETQ/SETQ2 be used with BYTE or WORD variants? I don't see how, but I figured I'd ask...
  • RaymanRayman Posts: 14,768
    Is there any point to using the Q2 version when reading into LUT?
    Sounds like Q2 only works between COG and HUB...
    I guess I still don't understand it...
  • rjo__rjo__ Posts: 2,114
    reading from hub to lut, setq2 is fine. reading from lut to hub use rep.

    I love the idea setq2 for lut ram, because then I don't have to worry about where my code is or how much cogram I have left, a phobia that could also be cured if I would just learn a little bit more:) This way, I don't have to worry. And if I learn more, I learn more. If not, I'm safe.

    I love it.

    Rich



  • jmgjmg Posts: 15,175
    cgracey wrote: »
    After the SETQ2, the RDLONG instruction should be:

    RDLONG 0,hubaddr

    The D operand in RDLONG is the first register in LUT (0..511) that you want to receive the data into. In other words, it's direct, not indirect.

    I think the context-dependent & obtuse semantics of all this is going to cause confusion.

    Can these paired (64b) opcodes, be morphed into more readable / user friendly versions ?

    eg there is rdlut and wrlut menmonics for LUT access already.

    Binary opcodes generated will be the same.
  • rjo__rjo__ Posts: 2,114
    I didn't mind bumping into it. I think the tools can take of this. They just need to throw back an error if you use an illegal address type with setq2... that will solve the issue.
    I think the mnemonics could help... H2Lq,H2Cq,C2Hq would make it clear, without actually changing the instructions.
  • cgraceycgracey Posts: 14,208
    Rayman wrote: »
    Is there any point to using the Q2 version when reading into LUT?
    Sounds like Q2 only works between COG and HUB...
    I guess I still don't understand it...

    I'm changing things around so that SETQ2 can be used before RDLONG/WRLONG in order lot write/read the lut in block mode. I'll make some other means to control the masked writing to hub.
  • RaymanRayman Posts: 14,768
    I can see that adding a lot of value to LUT memory...
  • evanhevanh Posts: 16,040
    Cluso will be liking all this too. Speaking of which, I haven't seen him post anything for a couple of weeks.
Sign In or Register to comment.