Shop OBEX P1 Docs P2 Docs Learn Events
RDFAST/WRFAST - is there a current pointer we can access — Parallax Forums

RDFAST/WRFAST - is there a current pointer we can access

Peter JakackiPeter Jakacki Posts: 10,193
edited 2015-10-31 05:52 in Propeller 2
Chip, I was looking at using RDFAST (and rfword/rflong etc)in my doNext loop but I need to be able to read the current position and save it so that I can change the address and then later restore it as well as when I need to read inline literals etc. Is there a register that we can access or can you make that register visible?

Comments

  • evanhevanh Posts: 15,910
    edited 2015-10-31 06:09
    I'm in favour of this! That FIFO I think can be so useful under programmatic control.
    Seairth is going to have quiet words with me too ...
  • cgraceycgracey Posts: 14,151
    I'd have to make a pointer, as one is not kept now.

    There's only a block counter that counts 16-long chunks on the other side of the FIFO.

    I'll make a note to add this.
  • evanhevanh Posts: 15,910
    edited 2015-10-31 06:29
    Oh, I hadn't imagined it as that basic. So, the address info of the RDLONG, for example, is ignored then? You can be reading the same location over and over, for example, but the data the FIFO will fetch is still sequential in HubRAM?
  • cgraceycgracey Posts: 14,151
    edited 2015-10-31 07:09
    evanh wrote: »
    Oh, I hadn't imagined it as that basic. So, the address info of the RDLONG, for example, is ignored then? You can be reading the same location over and over, for example, but the data the FIFO will fetch is still sequential in HubRAM?

    RDFAST and WRFAST establish hub FIFO modes for sequential reading and writing via RFxxxx/WFxxxx.

    RDxxxx and WRxxxx are random access reads and writes and they use slots that the FIFO doesn't need.
  • evanhevanh Posts: 15,910
    Uh-oh, bugger, I'm lost. I'm in real trouble with Seairth now.

  • SeairthSeairth Posts: 2,474
    evanh wrote: »
    Uh-oh, bugger, I'm lost. I'm in real trouble with Seairth now.

    :lol: Everyone else is distracting him from the smart pins, so you may as well also.
  • potatoheadpotatohead Posts: 10,261
    Seems like a last stage clean and polish. Smart Pins are coming, but this stuff probably should get sorted first. Then it's largely done. These last minute things seem like high value changes so far.

    I'm super eager to see how those end up myself.

  • ElectrodudeElectrodude Posts: 1,657
    If you make the FIFO keep track of its address, could you also make a RDFAST/WRFAST with the same address that the FIFO is already on act as a NOP (or maybe an FBLOCK)?

    Could you even make a RDFAST that's only skipping a few bytes not even reload the FIFO?
  • evanhevanh Posts: 15,910
    I've now gone and read Chip's write-up on RD/WRFAST FIFO mode setting and the associated RF/WF(LONG/WORD/BYTE) handling instructions.

    Okay, the key info I hadn't seen, alongside the obvious not even knowing about RF/WF instructions, is that RFLONG, for example, unlike RDLONG, has no S operand - No specified HubRAM address. So, it clearly just takes whatever the FIFO is feeding it. Question answered.
  • evanhevanh Posts: 15,910
    Now this FBLOCK thingy, it's activation looks to be buffered - "FBLOCK can be executed right after RDFAST or WRFAST to establish what will happen when the current block count is reached." Sounds bang on what I've been looking for. This is where more control could be cool. Namely to allow direction change too.

    Change FBLOCK into two instructions, one for read, RDFASTX (from http://forums.parallax.com/discussion/comment/1352094/#Comment_1352094), and one for write, WRFASTX, with the intent to allow a smooth regular transition back and forth between reading a block from HubRAM then writing another block back to HubRAM.
  • evanhevanh Posts: 15,910
    edited 2015-11-01 00:11
    Grr, damn it, I guess it also needs status/event to show that data is ready and direction change has occurred. There's going to be complications with adding this. It's amazing how much simpler unidirectional transfers are. Two separate but alternating FIFO's is the sensible solution. I think I'll forget about it.

    PS: This probably should be in Seairth's FDS topic.
  • SeairthSeairth Posts: 2,474
    evanh wrote: »
    PS: This probably should be in Seairth's FDS topic.

    No, it shouldn't. :P
  • cgraceycgracey Posts: 14,151
    edited 2015-11-04 02:22
    Would a readable tracking pointer for RFxxxx/WFxxxx really be that useful?

    It would save needing to do some kind of register increment for every RFxxxx/WFxxxx, but the only time I can see tracking being needed is when you don't know how much data you'll be reading or writing, like in the case of strings, maybe.

    I can add this tracking counter, but to make it handle block wraps will require a lot more hardware than if it just increments by 1/2/4 on RFxxxx/WFxxxx.

    How important is having a readable pointer?
  • Peter JakackiPeter Jakacki Posts: 10,193
    I haven't had any success yet with fast read in the inner interpreter but if i did i would only need the tracking pointer to increment as there would never be a wrap. The idea is that i have a pointer i could push onto the Forth return stack to later restore for another rdfast assuming that there are no problems with this approach.
  • cgraceycgracey Posts: 14,151
    Peter Jakacki wrote: »
    I haven't had any success yet with fast read in the inner interpreter but if i did i would only need the tracking pointer to increment as there would never be a wrap. The idea is that i have a pointer i could push onto the Forth return stack to later restore for another rdfast assuming that there are no problems with this approach.

    So, not having to do discrete ADD's to keep track of RFxxxx's would, indeed, save you a lot of code/time?
  • Peter JakackiPeter Jakacki Posts: 10,193
    I maintained a pointer along with every fast access which is why i thought that simply having access to the fast pointer would be more efficient, just as the fast ops themselves are more efficient. Having an accessible pointer puts a finishing touch on this implementation.
  • cgraceycgracey Posts: 14,151
    I hear you. I looked into it. It's pretty simple, as long as we don't have it track block wraps.
  • cgraceycgracey Posts: 14,151
    I've got the RFxxxx/WFxxxx pointer read implemented.

    GETPTR D - read the fast pointer into D
  • CongaConga Posts: 51
    Why not name the instruction "GETFPTR"?
    Relationship to RF... / WF... would be more clear, and length would be still under 8 chars to go well with tab stops in source.
  • cgraceycgracey Posts: 14,151
    Conga wrote: »
    Why not name the instruction "GETFPTR"?
    Relationship to RF... / WF... would be more clear, and length would be still under 8 chars to go well with tab stops in source.

    Okay.
  • Cluso99Cluso99 Posts: 18,069
    Might GETPTRF be more in keeping with PTRA, PTRB, CT1, DIRA, etc
  • ElectrodudeElectrodude Posts: 1,657
    edited 2015-11-05 21:59
    Cluso99 wrote: »
    Might GETPTRF be more in keeping with PTRA, PTRB, CT1, DIRA, etc

    But GETFPTR looks more like {R,W}F{BYTE,WORD,LONG}. Since it's part of the FIFO, it should use FIFO naming conventions.
  • TonyB_TonyB_ Posts: 2,178
    edited 2020-01-06 11:36
    cgracey wrote: »
    I've got the RFxxxx/WFxxxx pointer read implemented.

    GETPTR D - read the fast pointer into D

    Recycling this old thread from before I joined ...

    As I understand it, GETPTR returns hub address of the last RFxxxx/WFxxxx. I'm more interested in knowing the hub address of the next RFxxxx/WFxxxx, without any fiddling about, therefore I think it would be good to have a single instruction that could do this in the future.

    Can GETPTR handle block wraps as it is now?
  • ozpropdevozpropdev Posts: 2,792
    GETPTR returns the curren fifo pointer value not the last.
  • cgraceycgracey Posts: 14,151
    GETPTR returns the current address, which is the next to be read or written. It doesn't work with block wrapping, though, as it just keeps counting up in 20 bits. I tried to make it work with block wrapping, but it would have been very complicated to implement.
  • ozpropdevozpropdev Posts: 2,792
    cgracey wrote: »
    It doesn't work with block wrapping, though, as it just keeps counting up in 20 bits. I tried to make it work with block wrapping, but it would have been very complicated to implement.
    Hmm, I wasn't aware of that one.
    Just tried this code to see. 
    	rdfast	#1,#$100	'64 byte wrap
	rep	#1,#16		'read 64 bytes
	rflong	pa
	getptr	pa
	cmp	pa,#$140 wz
	drvnz	#56		'led 56 on = no wrap!
	jmp	#$

    Docs need this to be included for sure.

  • TonyB_TonyB_ Posts: 2,178
    Thanks for the GETPTR corrections. It's debatable what "current" means. Just to confirm for XBYTE, PA = current bytecode and PB = address of next bytecode?

    I think it would be clearer if spreadsheet description of GETPTR were changed from 
    Get current FIFO hub pointer into D.
    to 
    Get hub address of next fast read/write into D.

    Other spreadsheet/doc suggestions:

    1. Add that _RET_ takes 0 extra cycles for XBYTE ($1FF on top of stack).
    2. Amend $001F8..$001FF to $001FF in doc DEBUG INTERRUPT section.
  • Christof Eb.Christof Eb. Posts: 1,195

    Hi,
    when I studied RFWORD these days, and wondered if it could be used to gain speed in a wordcode machine as a variant of TAQOZ, google found this thread. So Peter (are you perhaps reading this?) thought about it in 2015. But he did NOT use it in TAQOZ. Instead
    rdword x,PTRA++
    is used.
    As far as I understand, there would be 2 advantages, if RFWORD would be used: PTRA would be freed and some speed gain should be possible. Is it much?
    So, why didn't he do it?
    Perhaps there are some thoughts about this?
    Christof

Sign In or Register to comment.