Storage of Variables

On 2008-08-16, The Natural Philosopher <a@b.c> wrote:

>> It depends on how easily one can access values on the
>> call/return stack.
>
> The great thing about using the program stack, is that it
> automatically adjusts when you enter/exit a subroutine:

It doesn't automatically adjust if you're using it for storage
of local variables. The compiler has got to "manually" adjust
the stack pointer on function entry to allocate space for
automatic variables, and it has to adjust the stack point again
before returning to clean up.

>> 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.
>
> Arguably a processor that shouldn't be programmed in C anyway.

But that's another thread. C compilers for the 8051 work a lot
better than I ever expected they would.

--
Grant Edwards grante Yow! HUGH BEAUMONT died
at in 1982!!
visi.com

Grant Edwards wrote:
> On 2008-08-17, The Natural Philosopher <a@b.c> wrote:
>> Jean-David Beyer wrote:
>>> The Natural Philosopher wrote:
>>>> Jean-David Beyer wrote:
>>>>> Grant Edwards wrote:
>>>>>> On 2008-08-16, Jean-David Beyer <jeandavid8@verizon.net> wrote:
>>>>>>> Grant Edwards wrote (in part):
>>>>>>>> On 2008-08-16, Jean-David Beyer <jeandavid8@verizon.net> 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.
>>>> malloc and local variables are undefined, static and global variables are
>>>> always zero.
>
>> The term 'sutomatic' never appears in the definition of the langauge AFAICR.
>>
>> Local variables are stack based.
>
> Not if they're static.
>
good point :-)

The Natural Philosopher wrote:

>> I think the original part of this thread concerned the values of
>> _automatic_ variables.
>
> The term 'sutomatic' never appears in the definition of the langauge
> AFAICR.

It appears in A4.1 of the standard,
"There are two storage classes: automatic and static."
>
> Local variables are stack based.
>
That is how I have always seen them.
>
>> In C, there is really no such concept as a heap,
>
> The heap is specifically defined in the C language AFAICR.
>
The heap is not in the index of the standard.

> How do you think statements like
>
> in p=1;
>
> are initalised outside of a subroutine?

The loader copies the data segment of the executable file into the given
addresses in RAM.
>
> The stack and the data segment are generally identical.

Not generally, since the data segment loads the static and global
(typically, but not necessarily external variables) only.

Local variables in functions, unless declared static, are initialized at
each entry to the function.

> If they are not, its clear that the data segment is overlaid with
> intialised data to set up the variables in it. Normally the assmeer will
> take all teh initialised variables and group them at the bittom of the
> data sefment and assign them values. Unitialised static variables are
> generally set to zero by the compiler because its actually quite hard to
> tell most assemblers to reserve a block of memory without telling them
> what to put in it.

Most assemblers, at least since UASAP 3-7 (from the late 1950s) had a bss
statement (or something with a similar name) or a bes statement, which did
just that.

> Since teh data segment is loaded as a unit anyway, there is no penalty to
> setting it to zero or whetever teh stuff is initialised to.
>
If you do it at assembly time, the penalty is that the object files are
larger than they need to be, and that takes disk space (formerly a problem)
and disk transfer time to load them. They can be initialized much faster by
the loader or if necessary, by the routine often called crt0.o before main()
is called.
>
>
> It is simpler to
>> have the loader zero it all out if that was wanted. It would make the
>> object file much smaller that way too.
>
> It would. exceopt that for the heap area, initialised and uninitialised
> variables are mixed up.
>
As I said before, the heap does not appear in the C standard.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 18:25:01 up 11 days, 31 min, 4 users, load average: 4.39, 4.29, 4.27

On 2008-08-17, Jean-David Beyer <jeandavid8@verizon.net> wrote:

> Local variables in functions, unless declared static, are initialized at
> each entry to the function.

They are allocated, but I've never seen a compiler where they
are initialized.

--
Grant Edwards grante Yow! Did I do an INCORRECT
at THING??
visi.com