Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!cbmvax!uunet!mcvax!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: null fill eliminated
Message-ID: <497@philmds.UUCP>
Date: 8 Jun 88 18:35:46 GMT
References: <490@philmds.UUCP> <1067@atari.UUCP>
Reply-To: leo@philmds.UUCP (L.J.M. de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 124

I just couldn't resist...

In article <1067@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>From article <490@philmds.UUCP>, by leo@philmds.UUCP (Leo de Wit):
>> null fill (there could be a 1/(vbls/sec) delay %-) and is guaranteed NOT to 
>> work on all ROM versions 8-).
>> The main problem will be the addresses (start, end) of the fill-routine
>> in ROM. 
>
>
>This is appalling! Please get over the idea that you can fool with stuff
>in ROM.  For starters, some programs EXPECT that the whole heap (not
>just the declared BSS) is zeroed at startup...  Microsoft Write is one. 

Then I think those programs are wrong, in sofar that they depend too
strongly on the environments they work in. A portable C program should never
expect the heap to contain all zeros, although many O.S.'s may do this:
the clearing of pages that for instance Unix applies when a process asks
for more space (more heap by calling sbrk, more stack by pushing data on it),
has nothing to do with initializing, but with protection; that process may
not peek at what another process left there. It could be just as well be set
to all 1's, or 0xe5 (but some Unix boxes have probably fast clear instructions).
When I come to think of it, it is even not very trivial to write a program that
uses that 'zero' feature; let's see, assume we have

#define DATASIZE 5000
then:

1) first try:

char egdata[DATASIZE];
static char sgdata[DATASIZE];

but these are not good examples; both are BSS so my fastload also clears them
(according to K&R).

2) second try:

function()
{
	char adata[DATASIZE];
	static char sldata[DATASIZE];

	/* code here */
}

are also not good examples; sldata is BSS so my fastload also clears it; 
adata is on the stack so assuming it contains zeroes is bluntly wrong.

3) third try:

function()
{
	char *pdata;

	pdata = malloc(DATASIZE);
	/* code here */
}

Wrong again; if the malloc() was preceded by free() you're likely to get
non-zero space; use calloc(), that's a portable way to get cleared space.
The same applies when you use the GEMDOS call Malloc(); it can just as
well contain non-zero space. And so for sbrk() and brk().

Moral: If you know beforehand the size you can use BSS declarations to
get a zero-initialized data element; note that they take no data space in the
program file (or use the initialized data segment by explicitly initializing it
to zero). If you don't, don't rely on some magic undocumented builtin
trick of some O.S. (you can put a T in front) but do it the standard way,
using calloc() for heap and _bzero() or setmem() or repmem() or 
zero_it_yourself_mem() for general space clearing; more likely to be portable
and big chance it's faster than the ROM's routines; this goes not for all 
parts of it, but some are really badly if at all optimized (but that's another 
chapter).

>Maybe the disk cache you use, or the hard disk compaction utility, or
>something equally deadly expects this -- and you'll learn the hard way
>not to fool with this kind of thing.

Maybe the new ROMs have their disk IO reorganized. All disk cache owners
will be surprised then, but not happily 8-). They will learn not to fool
with machines that are so poorly documented (please no flames, this is
merely a plea for better and less terse manuals in the future). I
understand it's easier for Atari not to make any statements regarding
the behaviour of their machines, in order to fix certain problems easier;
but they should understand that in order to get a machine, or perhaps better,
an O.S. accepted, they have to specify a certain standard, whatever that might
be, so that developers can rely on it, have fait in it (this is not a
follow-up to 'What Atari should do' 8-).

>I know the clearing takes a long time on 11/20 ROMs.  It's much faster
>in Mega and future ROMs.  But it's still there, because it is a "settled
>expectation" among developers.  ("Settled expectations" are things that
>people count on despite the fact that nobody promised they'd stay true.)

I don't need to count on it and I wouldn't settle for it %-). Besides I think
it is a pure waste: 
On my 520 ST+ with harddisk many of the tools I use take more time to
clear their space than to actually load. My programs and shell scripts run
much faster after this fix and most programs don't use even 10% of the so 
slowly cleared space. The editor and compiler that use BSS space amongst 
others are perfectly happy.

>I urge people not to use this trick or any other which changes the
>environment that programs execute in, or depends so heavily on actual
>addresses in ROM. 

Ever taken a look at AHDI.PRG, the hard disk driver that comes with the SH204?
This one also uses fixed addresses to check for ROM version etc. I think
there's no other way if you want to fix things, or you end up rewriting
complete parts of TOS/GEMDOS, and I wouldn't like that. My utility could
just as well be extended to settle for more ROM versions, and I would help
anyone that wants to find things out for his version. You can also easily
modify it to give you all cleared space, if you insist on that; it will still
be more than 7 times as fast as what my ROM does.

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

Now you're making sense! And I hope my opinions CLEARed things a bit...
only the BSS, that will do 8-).

	Leo.