JeffVincent Posted September 21, 2018 Share Posted September 21, 2018 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$293Bwith 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-listDEFINE 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=_ba1LIST newLive=_ba2LIST adjacent=_ba3PROC 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)RETURNPROC main() initLists()RETURN Quote Link to comment Share on other sites More sharing options...
funkheld Posted September 21, 2018 Share Posted September 21, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted September 21, 2018 Share Posted September 21, 2018 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 22, 2018 Share Posted September 22, 2018 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 4 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.