Re: Storage of Variables

On 2008-08-16, Jean-David Beyer <jeandavid8@xxxxxxxxxxx> wrote:
Grant Edwards wrote (in part):
On 2008-08-16, Jean-David Beyer <jeandavid8@xxxxxxxxxxx> wrote (also in part):

Static variables were stored in RAM.

I was afraid that might be ambiguous. In the C compilers for
the AT&T 3B computers as well as the PDP-11 and VAX machines,
there were three memory "sections" called text, data, and bss.
Text had the program in it. Data had initialized data in it.
Bss was static data that had not been initialized; this
contained undefined values -- in practice, they put in trap
instructions so if you tried to execute them, you got
interrupted. Other implementations put NAN in there, and yet
others filled it with zeros.

The C language definition requires them to be zeros.

But officially, you were not guaranteed to get anything in
particular.

I didn't think the zeroing of static variables was that recent
requirement. I would have sworn it was in the original K&R (I
don't have my copy handy).

For the stack, what you got was undefined and pretty much had
to be, because compilers could move stack items into registers
and if you used a value before you assigned it a value (all
too common, I grieve to say), you could get nasty surprises.

So were automatic variables, one would presume. If you put
them in ROM, it's rather hard to "vary" them. ;)

There was no heap in those days.

Where did malloc() get memory from if there was no heap?

We are probably quibbling here. malloc got its memory by doing
sbrk() calls. It usually did relatively few sbrk calls of
large amounts and the malloc function divided it up using the
"buddy system", and I do not think of that as a heap, though I
admit it could be called that. I think of a heap as something
more complex, needing automatic garbage collection and such.

Fair enough. I've always referred to the memory managed by
free/malloc as "the heap", but what you're describing is a bit
different.

Using a heap for local variables does not make sense (IMAO)
because the overhead of managing such a thing is too high for
something that can be done automatically with a stack.

Right. The one question left unanswered (and unasked) is
whether the automatic variable stack and the call/return stack
are the same.

I never saw separate stacks for automatic and call/return. But
I only saw the Bell Labs stuff and SPARC stuff.

It's common in compilers for some oddly designed
microprocessors (e.g. Intel 8051) that have limited call/return
stack access. For more general purpose processors, it's almost
always a single stack. ISRT the VAX/VMS Pascal compiler did
dual-stacks, but I don't know why.

Since they get allocated and freed at the same time, I see no
need to have separate stacks.

It depends on how easily one can access values on the
call/return stack.

You might justify separate stacks for C on something like the
PDP-11 where the instructions and date _each_ had a 65536 byte
address space and had 16 bits for them. The machine knew if it
were fetching instructions or data and got the stuff from the
right part of memory. But even here, the Bell Labs compiler
used the same stack for call/return and local variables.

For most compilers I've seen, the answer to that
is yes. But, I have seen cases where it wasn't: there were two
stacks: one for call/return and one for automatic variables.

Any idea what hardware architecture would make this a
reasonable thing to do?

The most recent example I've seen is on the 8051, the
call/return stack is fixed in both location and maximum (rather
limited) size. IIRC, there wasn't an easy way to access the
stack pointer or values on the call-return stack other than
push/pop.

--
Grant Edwards grante Yow! HUMAN REPLICAS are
at inserted into VATS of
visi.com NUTRITIONAL YEAST...
.

Relevant Pages

  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... registers (memory mapped) all sorts of fun things happen. ... When the stack overflows you don't see any allocation errors. ...
    (sci.electronics.design)
  • Re: shell code on minix
    ... compilers may be different. ... The stack segment in a i386 processor are not executable and analyzing in details the assembler generated in the Minix and Linux you may see what trick are used and why it works on Linux. ... Reading any book on the i386 family of processors would be of help to understand how memory protection and allocation works. ...
    (comp.os.minix)
  • Re: Storage of Variables
    ... (And in some optimizing compilers, register statements are ignored and the ... function zero out the stack. ... the contents of the memory returned by mallocis undefined. ... whether the automatic variable stack and the call/return stack ...
    (comp.os.linux.misc)
  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... that hard to avoid unless your program is doing something very strange. ... There is no real reason to avoid C on any micro when good compilers ...
    (sci.electronics.design)
  • Re: Statement on Schildt submitted to wikipedia today
    ... However, what Schildt described was not an abstract stack, but a specific ... but not true -- many compilers will ... support the contention that the standard was designed "to protect profits". ... "Sequence points" were designed to protect profits, ...
    (comp.lang.c.moderated)