[comp.lang.c] Initial values

chris@mimsy.UUCP (Chris Torek) (10/25/87)

>In article <9897@brl-adm.ARPA> tom@vax1.acs.udel.EDU (Tom Uffner) writes:
>>externals and statics can be initialized "for free" ... at compile time

In article <6917@prls.UUCP> gardner@prls.UUCP (Robert Gardner) answers:
>This isn't necessarily true....  One compiler I worked with allocates
>space for global variables dynamically before calling main(), zeroes
>it, and then executes a bunch of initialization statements that move
>the initialization values into the proper places, then calls main().
>There is approx. one move for each initializer, so each initializer
>takes about twice as much space as you would expect.

Consider, however, that if you set each variable at run-time, you
would (assuming the compiler is any good) generate exactly the same
sequence of moves.  Hence the compile time initialisers gain nothing
and lose nothing on such a compiler.

>On the other hand, this is a net gain if there are only a few
>initializers compared to the number of global variables, since
>allocating space for all the global variables in the executable
>(as RSX does) can take more space than the initialization code ....

There is yet a better way, and that is to record in the executable
only the size in bytes (or words or whatnot) of `uninitialised
global variables'.  These must then be placed in a single group
(unless you are willing to allow multiple `n-bytes-of-globals'
records).  This is what the Unix `bss' space is all about.

On machines with demand paging, there is yet another benefit from
simply adding up the sizes of uninitialised globals.  Instead of
allocating and zeroing pages for these, the system can allocate
`zero fill on demand' pages.  This has the usual fill-on-demand
tradeoffs, of course.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris