Re: Storage of Variables

Grant Edwards wrote:
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.

I do not believe this is correct. Certainly, the contents of register
variables are undefined unless something is explicitly assigned to them.
(And in some optimizing compilers, register statements are ignored and the
registers are overloaded (different things are assigned to a register at
different times).) Furthermore, I have never seen the code at entry to a
function zero out the stack. In correct code, this would never be necessary,
and in incorrect code you are seriously asking for trouble.

Similarly, the contents of the memory returned by malloc() is undefined.

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.



--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 15:00:01 up 9 days, 21:06, 4 users, load average: 4.06, 4.26, 4.32
.

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: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: Maybe we should stop "Paging Beth Stone" already...
    ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
    (alt.lang.asm)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)