Array question

blittled

I am using an array as a FIFO stack. If I use the following

bytemove (@buffer, @buffer+13, 247)

to move 13 bytes "up" the stack will the move work or will the array be destroyed?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!

JonnyMac

A quick test (hint, hint) seems to show that bytemove does what you want: n bytes at buffer+x are moved to the top.

pub main | idx
                                          
  term.start(31, 30, %0000, 115_200)
  pause(1)
  term.tx(CLS)

  repeat idx from 0 to 9
    term.tx(GOTOXY)
    term.tx(0)
    term.tx(idx)
    term.dec(byte[noparse][[/noparse]@testbuf][noparse][[/noparse]idx])

  bytemove(@testbuf, @testbuf+5, 5)  

  repeat idx from 0 to 9
    term.tx(GOTOXY)
    term.tx(8)
    term.tx(idx)
    term.dec(byte[noparse][[/noparse]@testbuf][noparse][[/noparse]idx])

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

blittled

Thanks, Jon. You are right, testing is the best way to find out!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!

MagIO2

But the test is different from what blittled want's to do originally!

@testbuf, @testbuf+5, 5

of course works, as the number of bytes matches with the offset.

@buffer, @buffer+13, 247

won't work (my guess), as it shall move more than 13 (the offset) bytes. The first 13 bytes are fine, but with the 14th byte the move reaches the region where it previously already copied the first 13 bytes to. In the end the stack will always repeat the same 13 bytes again and again.

Alternatives:
1. If you want to use bytemove you need to move it from the end to the top in 13 byte bunches. Which means you have to call bytemove several times (247 / 13).
First call would be bytemove( @buffer + 247 - 13, @buffer + 260 - 13, 13 ), second call bytemove( @buffer + 247 - 2*13, @buffer + 260 - 2*13, 13 ) ... and so on ... of course you can do that in a loop.
2. You could run a modified SPIN interpreter which implements the bytemove differently. Instead of copying from lower address to higher address you can do it the other way around.
3. Propably the easiest if you can efford the extra HUB-RAM: first copy from @buffer to a totally different buffer and from there copy it to @buffer+13

Post Edited (MagIO2) : 6/29/2010 7:43:05 AM GMT

kuroneko

MagIO2 said...
@buffer, @buffer+13, 247

won't work (my guess), as it shall move more than 13 (the offset) bytes. The first 13 bytes are fine, but with the 14th byte the move reaches the region where it previously already copied the first 13 bytes to. In the end the stack will always repeat the same 13 bytes again and again.

It's bytemove(dst, src, count), why shouldn't the above example work?

Phil Pilgrim (PhiPi)

IIRC, bytemove is smart enough to divine the order in which bytes are copied, so as not to clobber things. IOW, if the destination address is less than the target address, moves take place from low to high. If the destination address is above the target address, moves take place from high to low.

But that's beside the point. The bigger issue is that shuttling bytes like this is not the most efficient way to implement a queue (a.k.a. FIFO buffer). It's better just to leave the queue contents alone and manipulate a pair of pointers that indicate the current head and tail of the queue, and which cycle back to the beginning when they overflow the end.

-Phil

MagIO2

Ok ... I'll go back to SPIN-school ... ;o)