tas@ariel.UUCP (07/13/83)
If you're writing C code for an operating system-less microprocessor (i.e. .text and .data in ROM, .bss in RAM), your .bss stuff generally won't get initialized to 0. And, of course, you'll only want to put constants into .data because it's hard to change ROM. Tom Skrobala houx*!ariel!tas
henry@utzoo.UUCP (Henry Spencer) (07/17/83)
If you're writing C code for an operating system-less microprocessor
(i.e. .text and .data in ROM, .bss in RAM), your .bss stuff generally
won't get initialized to 0. And, of course, you'll only want to put
constants into .data because it's hard to change ROM.
If it doesn't initialize .bss to 0, it does not comply with the C reference
manual and therefore is not C. Such a botch will also break many programs
(probably not relevant for this case) and many library functions (rather
more serious). Putting all initialized variables in ROM is also wrong,
for the same reasons. I appreciate the problems involved in figuring out
which things go in ROM and which in RAM, but this is the wrong way to
tackle it.
--
Henry Spencer
U of Toronto
{allegra,ihnp4,linus,decvax}!utzoo!henryguy@rlgvax.UUCP (Guy Harris) (07/17/83)
Bell is considering an addition to C to permit specification of sharable
read-only data vs. non-shared read/write data (to get shared read/write
data, use the shm* system calls in UNIX 5.0 - System V - or whatever will
appear in 4.2BSD), which will solve the problem much more cleanly than it
is being solved now, namely by running selected source modules through an
"sed" script that turns ".data" into ".text".
As for a micro-based application not clearing out ".bss", the method used
by the UNIX kernel, you're right; any C implementation running stand-alone
should have a C startup routine which cleans out "bss" (a little tricky if
your linker won't provide the start of BSS and the end of BSS as globals,
as the UNIX one does) and calls "main".
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy