Question about Action array size

[JeffVincent]

Hi, I recently started using OSS's Action, but I've run into some problems. In short, is there a limit on the size of arrays? I find that when I try to create a BYTE ARRAY of >256 elements, the compiler starts each array only a few bytes apart (as if it is ignoring the MSB of the size.)

To expand a bit... I was trying to do a Life simulation and wanted to create several linked lists. I've since concluded that can't be done since the language doesn't seem to be able to dynamically allocate memory. So I decided to do a sort of pseudo-linked-list, creating a record with CARDs for capacity and current size and a BYTE for the start of a virtual x,y coordinate array. Then I created a BYTE ARRAY to hold the record with the virtual array and declared the record and assigned it the address of the BYTE ARRAY. When I tried to Zero() the arrays, I ran into trouble, and when I investigated further I found the problem mentioned above. (I've appended the code below to clarify.)

When I run this with a BYTE ARRAY size of 256, it creates three arrays and prints out the starting addresses:
$2933
$2A33
$2B33

which is as expected.
But if i increase the BYTE ARRAY size to 257, it prints:
$2933
$2937
$293B
with the arrays overlapping...

I didn't see any mention of an array size limit in the manual (and they even show a 1000 byte array in the advanced record example.)

 

I'm running this on the Atari800 emulator (3.1.0) in 800XL mode with the Action 3.5 cart on a Linux Mint 18.1 laptop.

 

Thanks for any help you can offer.

 

-- Jeff

 

 

; pseudo-linked-list

DEFINE ARRAY_SIZE="256"

TYPE LIST=[CARD CAPACITY, size BYTE xy]

BYTE ARRAY _ba1(ARRAY_SIZE)
BYTE ARRAY _ba2(ARRAY_SIZE)
BYTE ARRAY _ba3(ARRAY_SIZE)
LIST live=_ba1
LIST newLive=_ba2
LIST adjacent=_ba3

PROC initLists()
BYTE i
BYTE POINTER ptr

live.CAPACITY=(ARRAY_SIZE-4)/2
live.size=0
ptr=@(live.xy)
PrintF("%H%E", ptr)
; Zero(ptr,ARRAY_SIZE-4)

newLive.CAPACITY=(ARRAY_SIZE-4)/2
newLive.size=0
ptr=@(newLive.xy)
PrintF("%H%E", ptr)
; Zero(ptr,ARRAY_SIZE-4)

adjacent.CAPACITY=(ARRAY_SIZE-4)/2
adjacent.size=0
ptr=@(adjacent.xy)
PrintF("%H%E", ptr)
; Zero(ptr,ARRAY_SIZE-4)
RETURN

PROC main()
initLists()
RETURN

[funkheld]

start $3000 :

-------------------------------------

SET $E =$3000

SET $491=$3000

-------------------------------------

from $2000 to $3000 = $1000 free

or ramtop down.

and you have memory that does not bother anyone

greeting

Edited September 21, 2018 by funkheld

[a8isa1]

BYTE arrays (and alias CHAR arrays) are Action!'s means of doing strings. The 0th element contains the string length, 0 to 255.

 

That said, there's not really any bounds checking in Action!. I would think it would allocate whatever amount of space you specified. Odd that it doesn't seem to do so in your case.

[Alfred]

What you're seeing is one of the optimizations that Action! does. For a byte array 256 elements or less, Action! knows it can use LDA $addr,X addressing, so the array is allocated in place. If it's more than 256 bytes, then it has to be handled via zero page the same way Pointer types are handled. So in the case where you allocate more than 256 elements, Action! stores the size of the array in a linked list during compilation, plus two bytes for the pointer. That's why you see the array's four bytes apart. The actual data of the array is at a different address. Action! chains all large arrays together during compile because it doesn't know where they can go until it finishes codegen. Once the last RTS is inserted, it runs the chain of arrays and allocates them, if they had a size specified.

 

So for a byte array of 256 or less, you get codegen like:

LDY index

LDA array,y

 

but for a larger array you end up with

 

clc

lda array

adc index

sta temp1

lda array+1

adc index+1

sta temp1+1

ldy #0

lda (temp1),y