🚀 go-pugleaf

In article <nevin-2509951503200001@mac-nevin.cs.arizona.edu>, nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:

|> And the original engineers weren't willing to use up an extra 256
|> bytes of RAM.  

The original engineers (of AppleSoft Basic on the Apple II) were
Microsoft employees.  That explains it.

|> You made classic space/time tradeoff.  I don't remember how much
|> RAM the original Apple's came with 

4K.  The original Apple ][+, that came with AppleSoft in ROM, might
have started with 16K.

|> (I came on the scene when they had 16K of RAM).  That is a lot of
|> memory to dedicate to something that, by previous arguments of
|> yours against heap compaction (it's the same thing), just doesn't
|> happen very often.

|> For a 4K machine, you'd be wasting 6.25% of the RAM for this.

It's worse than that, because you lose 256 bytes for 0-page, 
another 256 for the stack, 960 bytes for the text page (and another
960 bytes for text page 2, if you used it.)  How much RAM is left?
2624 bytes.  So the "little" 256-byte look up table chews up 10% of
RAM.

|> > Not possible. 8x10000 > 48x1024, right?

|> You had 48K, and you still needed to compact the string space?  I thought
|> you said that it was a rare occurance.

Most Applesoft Basic programs that would use a lot of strings would
"take a nap" every 20 minutes or so, to defrag the string space.

Chris
-- 
Speaking only for myself, of course.
Chris Wood    christw@lexis-nexis.com   ChrisCWood@aol.com