Stupid question #2 - Large arrays in memory

Up2l8

Ok, I'm starting to feel really dumb now...

I have an 64 byte array of memory and am having difficulties addressing it.

The problem is the very small 16 byte memory pages offset by the 16 byte global registers.
I love the global registers, but allocating the memory and accessing a continous block across them is a PITA.

Example:
ORG 0x10 ;Start after all the global registers

BigArray ds·0x40 ; Define my big array - 64 bytes long

mov W, #BigArray+20 ; Lets try to get offset = 20
mov FSR, W· ;Setup the FSR
mov W, INDF· ; Oops!· Not even close!
--

Since BigArray +·20 = 0x24 the FSR rolls over at 0x20 and splat I'm left accessing 0x04.

I have something that is working but it is a major cycle hog.· For this app speed is king.· Before I set to work to slim it down I thought I'd see what you all had to say - I'm probably missing something fairly straightforward.

Eric


Post Edited (Up2l8) : 9/25/2005 10:18:02 PM GMT

Up2l8

Well, nothing jumped out at me so I just busted my memory up into 4x16-byte pieces, each starting at 0x10 of its page.

A bit messier to index, but it was all I could come up with for the time being.

Eric

Paul Baker

You need to come up with an index to memory mapping function. I have some code for linear addressing the banks I used in stack code, which is a simplified version of what you need. If you start the array at the first cell of a bank, say $10; take the index and divide it by 16, the memory address will be: the base address·+ integer result of division * 32 + remainder of division

So if you have an array of 32 bytes starting at $10 and you are retreiving the 23rd element, 23/16 = 1 remainder 7. The memory location is $10 + $20 + $07 = $37.

<note> changed equation, should be correct now </note>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 9/26/2005 5:46:23 AM GMT

Paul Baker

The code to divide the index by 16 is:
······ mov w, <>Index
·······and w, #$0F
······ mov IDiv, w
and the remainder is simply
······ mov w, Index
······ and· w, #$0F
······ mov RDiv, w

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Up2l8

Paul -

I had something similar to that eventually but I think that I was being dumb and trying to make an address => address mapper instead of an index => address mapper.
What you posted makes much more sense [noparse]:D[/noparse]
I'm afraid that it still might be too time consuming though - that adds 7-8 cycles per read/write.
I suppose you trade code space for cpu time though...

Eric

Post Edited (Up2l8) : 9/26/2005 4:11:43 PM GMT

Paul Baker

Im curious what your cycle overhead is for dividing the array into subarrays, it seems to me it would be roughly the same.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Up2l8

Well, I'm cheating at this point and just treating them as 4 seperate arrays and incrementing within them.

Inside the timing critical loop the data is incremental read only so just incrementing the pointer is much quicker than decoding the index every time.

Your solution is much more practical for random access type stuff.

Eric

Paul Baker

Oh then that is a completely different story, I have very fast code for linear addressing. James has a copy of it here http://www.sxlist.com/techref/scenix/lib/mem/sstack_sx.htm

In essence after you increment the pointer you do:

········ setb dptr.4 ;SX28 bank wrapping adjustment

and after decrementing is

········ jb·· dptr.4, :noroll ;SX28 bank wrapping adjustment
··········· sub dptr, #16
:noroll·························;rest of code



dptr is the index (which must be placed in FSR before indirect access)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 9/27/2005 12:36:38 PM GMT