Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!ucsd!ucbvax!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Another great quote from Mr. Good
Message-ID: <1103@atari.UUCP>
Date: 5 Aug 88 17:43:31 GMT
References: <3308@druhi.ATT.COM>
Distribution: comp
Organization: Atari Corp., Sunnyvale CA
Lines: 42

From article <3308@druhi.ATT.COM>, by med@druhi.ATT.COM (Myron Drapal):
> From Computer Shopper August 1988, page 214:
> [deleted]

Please, please, please do not take quotes in a rag like that as Gospel. 
There were at least half a dozen howlers in that article, and this was
one of them. 

The truth of that "quote" is this:

	I tried to fix Malloc so there would be no limits on
	the number of blocks you could have around, by using
	the memory above and below the block to keep track
	of the blocks themselves.  I had to back out this
	improvement, because lots of programs violated
	the commandment:

	  Thou Shalt Not Screw With Memory Thou Ownest Not

	The Malloc you will get in the new ROMs is vastly
	improved, but still has limits because I was forced
	to go on using the OSPool.  The OSPool is statically
	allocated with a fixed size.  It is still expandable
	with FOLDR100.PRG, but the fact remains that it can
	be filled up.

So the summary is, "There were some improvements we tried but had to
back away from because of ill-behaved programs."

Another of those improvements was getting rid of clearing memory before
launching a program.  In 11/20 ROMs (pre-Mega), the code which did this
was REALLY SLOW, but only had a max of <1M to clear.  For a Mega, Landon
Dyer sped up the code, but it now has a max of just under 4M to clear. 
This takes a nontrivial amount of time.  Nobody promised that the space
after your declared BSS and before your initial stack pointer would be
clear, but it has always been that way and some programmers chose to
depend on it.  This is called a "settled expectation" and we have to
live with it in the name of compatibility. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt