Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Benoit0123 Newsgroups: comp.sys.apple2.programmer Subject: Re: Streamlining Applesoft - The garbage collector Date: Tue, 23 Feb 2016 15:33:53 -0000 (UTC) Organization: Mac GUI Lines: 42 Message-ID: References: <7ad02214-d93e-4511-bb3d-c80e40614d5c@googlegroups.com> <6f8f2b6f-3c25-4030-893a-a5573dcad824@googlegroups.com> <5361254e-8102-4b1f-9fc2-06f40a164cec@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 23 Feb 2016 15:33:53 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="ac9e0e4d7dd3957fb97803ee6801bab8"; logging-data="18371"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19imIBuwXBs48kDiBhKz98l" User-Agent: Mac GUI Usenet In-Reply-To: <5361254e-8102-4b1f-9fc2-06f40a164cec@googlegroups.com> Cancel-Lock: sha1:d4J4oLxXV5hMTXw1KAUoxmcrMeo= Xref: csiph.com comp.sys.apple2.programmer:2362 gids.rs wrote: >> This is great work! >> >> > This would give us and allow for 256 string pointers through each pass >> > through the variable tables. I apologize for mis-leading you to think >> > we are only collecting 128 strings at a time, but such is the suspense >> > of story telling. >> >> Question that is tangential to this: >> >> Is there a limit on the number of strings Applesoft can handle, aside >> from a memory one? 256 max strings? i.e. if LOMEM was set to something >> ridiculous so that Applesoft had ~32K available, is there a hard limit to >> the number of strings or is strictly memory limited? > > > Applesoft limits each array indice to 65536. So the array > NAME$(65536,65536,65536) is a valid array and would allow for, lets just > say that is a really big number of strings. The array itself would not > even fit in memory, let alone any strings. But even if it did have the > memory, this is much larger than the 16 Mb file limit of Prodos. Small adjustment: Plain vanilla Applesoft accepts indice values from 1 to 32767 while handling DIM statements and from 0 to 32767 within array element lookup. For instance, DIM A%(32768) will lead to an "?ILLEGAL QUANTITY ERROR" raised at the time the indice value is evaluated.. DIM A%(32767) will lead to an "?OUT OF MEMORY ERROR" instead, raised afterwards when time is coming for ensuring enough RAM available within the heap. At the time of Applesoft release, this was a sensible choice as adressable mémory was limited to 64K and smallest element size for arrays was the 16bits (2 bytes wide) integer (65536 / 2 = 32768)... -- Growing old is mandatory.. growing up is optional.. But the other way round is as true.