Old Wolf wrote:
> "jimjim" wrote:
> >
> > So, my question is whether anyone knows a  non-stack-oriented
> > implementation and any high-level implementation details.
>
> I have used a non-stack implementation for C (not C++ though).
> It did use a function call stack, but automatic variables were
> statically allocated.
>
> The linker would analyse the possible execution paths, and give
> you a warning if you tried to call a function recursively.
> (In theory, anyway, in practise its analysis was far from perfect).
>
> It was possible to declare a function 're-entrant' meaning that
> it would have 3 copies of its local variables allocated statically
> (and supposedly the linker would also check that you couldn't enter
> it to a depth of 4 times or more).

There are two features of C that make a stack-oriented implementation
likely: function call stack and automatic variables. If that
implementation does use a stack for the first feature, and doesn't
correctly implement the second, then it's not a good example of a
non-stack-oriented implementation of standard C++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
> * "jimjim":

> > I ve been told that "C++ does not have any mechanisms to
> > check how close the "stack" is to its exhaustion, since the
> > virtual machine on which C++ programs execute does not have
> > any particular "stack" implementation."  Should I assume
> > that because it is not specified by the C++ standard, on
> > certain hardware platforms there may be no stack segment on
> > which automatic variables are allocated to (unlike x86
> > perhaps?)?

> Let's be precise.  "segment" is a particular form of memory
> management that only exists on certain platforms.  "stack" is
> a much more general notion, which doesn't need hardware
> support, and so your question is really whether a C++ program
> necessarily uses a stack for automatic variables.

A stack can be based on any number of data structures.  I've
already used an implementation of C where the "stack" was a
linked list (of memory allocated from the pool used by malloc).

> In practice, yes, for non-inlined function calls auto
> variables are allocated on a stack, because it's so simple
> especially with respect to handling return addresses -- the
> use of the hardware-assisted stack (which in practice every
> computer has) is then natural also for auto variables and
> arguments.

I wonder about that "every computer".  Most of the different
architectures I've seen had no direct hardware support for a
stack.  Of course, most of them are long gone and forgotten, but
the IBM 390, today, is a direct descendant of the IBM 360, which
didn't have any hardware support for a stack.

I suspect that many modern RISC architecture, and probably some
embedded processors as well, do not have direct hardware support
for a stack, as such.  Of course, all of them allow adding the
contents of a register into an address.  And of course, adding
or subtracting a constant to or from a register.  Which means
that a "push" or a "pop" operation can be done in two
instructions.  (In the end, it depends on what you mean by
hardware support for a stack.  All modern machines will
certainly make it easy to implement recursive functions and
such, with a local stack frame.)

> In theory, no.  For example, if the compiler can prove that
> there are no recursive calls, or that the recursion nesting
> depth is bounded, it can in theory allocate auto variables
> statically (at logical addresses assigned at compilation), and
> put each function's return address at a static address.

> > Moreover, why is it that C++ enables you to verify whether
> > dynamic memory has been allocated properly (catching the
> > bad_alloc exception that might be thrown by new) but not
> > about the memory allocated for automatic variables?

> That's been partially answered over in [comp.lang.c++]: if you
> get a stack overflow the stack is likely corrupted, some
> arguments pushed but a return address not yet pushed.  Also,
> on a machine without hardware supported bounds/address
> checking adding stack checking to every function would impose
> a cost.  That's the same situation as with integer division by
> zero, say: on some machines that can be easily detected by
> hardware, on others detection would require costly software
> checks, and it's not something you need in every or even most
> programs, so C++ doesn't give you any standard detection
> mechanism -- only pay for what you actually use.

> The dynamic allocation that a C++ 'new' invokes is, on the
> other hand, costly and reports whether it succeeds, so it's no
> big deal to pass that information up to the programmer via an
> exception.

Regretfully, this depends on the system as well, and some
systems never report failure (but will crash the program later
if the memory wasn't available).

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uhdgc6vvg.fsf@boost-consulting.com...
> "jimjim" <netuser@blueyonder.co.uk> writes:
>
>>>> Should I assume that because it is not specified by the C++ standard,
>>>> on
>>>> certain hardware platforms there may be no stack segment on which
>>>> automatic variables are allocated to (unlike x86 perhaps?)?
>>>
>>> No, you can't really conclude anything about what hardware does from
>>> looking at what's left unspecified in the standard.
>>
>> Is there a logical error?
>>
>> try{
>> if ( C++ standard enforced a "stack" implementation)
>>             I am sure that no matter the hardware platform the allocation
>> of
>> memory is stack oriented;
>> else
>>             I can assume that on certain hardware platforms the
>> implementation is not stack oriented;
>> }catch(...)
>> { cout <<  "You are a beginner. You dont know what you are talking
>> about";}
>
> Yes, there's a logical error.  The C++ standard is written to avoid
> putting needless constraints on possible implementations, so you can't
> conclude that a non-stack-oriented implementation actually exists from
> the fact that it isn't forbidden.
>

In my else statement I wrote "I can assume" that on certain hardware
platforms the implementation may not be stack oriented. So, my question is
whether anyone knows a  non-stack-oriented implementation and any high-level
implementation details.

TIA

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"jimjim" wrote:
>
> So, my question is whether anyone knows a  non-stack-oriented
> implementation and any high-level implementation details.

I have used a non-stack implementation for C (not C++ though).
It did use a function call stack, but automatic variables were
statically allocated.

The linker would analyse the possible execution paths, and give
you a warning if you tried to call a function recursively.
(In theory, anyway, in practise its analysis was far from perfect).

It was possible to declare a function 're-entrant' meaning that
it would have 3 copies of its local variables allocated statically
(and supposedly the linker would also check that you couldn't enter
it to a depth of 4 times or more).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello,

I ve been told that "C++ does not have any mechanisms to check how close the
"stack" is to its exhaustion, since the virtual machine on which C++
programs execute does not have any particular "stack" implementation."
Should I assume that because it is not specified by the C++ standard, on
certain hardware platforms there may be no stack segment on which automatic
variables are allocated to (unlike x86 perhaps?)?

Moreover, why is it that C++ enables you to verify whether dynamic memory
has been allocated properly (catching the bad_alloc exception that might be
thrown by new) but not about the memory allocated for automatic variables?
(Given that such a decision is determined by certain requirements or
restrictions).

TIA


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

netuser@blueyonder.co.uk ("jimjim") writes:

> Hello,
>
> I ve been told that "C++ does not have any mechanisms to check how close the
> "stack" is to its exhaustion, since the virtual machine on which C++
> programs execute does not have any particular "stack"
> implementation."

That's correct.

> Should I assume that because it is not specified by the C++ standard, on
> certain hardware platforms there may be no stack segment on which automatic
> variables are allocated to (unlike x86 perhaps?)?

No, you can't really conclude anything about what hardware does from
looking at what's left unspecified in the standard.

> Moreover, why is it that C++ enables you to verify whether dynamic memory
> has been allocated properly (catching the bad_alloc exception that might be
> thrown by new) but not about the memory allocated for automatic
> variables?

Well, in part it's probably historical -- you want C programs just to
run under C++ without having to consider whether simply entering a
stack frame with only scalar automatic variables might throw.  In part
it's certainly that some platforms we'd like to target with C++ have
no efficient means to detect that stack space has run out.  Finally,
although I'm fairly certain the original designers didn't consider
this issue, you need to have some kinds of data that can be guaranteed
to be manipulated without throwing, if only so that you can execute
the actions that must happen during exception unwinding.  If you bring
the possibility of scalar automatic variables throwing into the
programming model, it becomes impossible to write any kind of
reasonable recovery code.

> (Given that such a decision is determined by certain requirements or
> restrictions).

Let me also add that nothing prevents a particular implementation from
throwing exceptions in such conditions, as a way of implementing the
undefined behavior that results from exceeding the implementation's
resource limits (stack overflow).

HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

* "jimjim":
>
> I ve been told that "C++ does not have any mechanisms to check how close the
> "stack" is to its exhaustion, since the virtual machine on which C++
> programs execute does not have any particular "stack" implementation."
> Should I assume that because it is not specified by the C++ standard, on
> certain hardware platforms there may be no stack segment on which automatic
> variables are allocated to (unlike x86 perhaps?)?

Let's be precise.  "segment" is a particular form of memory management that
only exists on certain platforms.  "stack" is a much more general notion,
which doesn't need hardware support, and so your question is really whether
a C++ program necessarily uses a stack for automatic variables.

In practice, yes, for non-inlined function calls auto variables are
allocated on a stack, because it's so simple especially with respect to
handling return addresses  --  the use of the hardware-assisted stack (which
in practice every computer has) is then natural also for auto variables and
arguments.

In theory, no.  For example, if the compiler can prove that there are
no recursive calls, or that the recursion nesting depth is bounded, it
can in theory allocate auto variables statically (at logical addresses
assigned at compilation), and put each function's return address at a
static address.


> Moreover, why is it that C++ enables you to verify whether dynamic memory
> has been allocated properly (catching the bad_alloc exception that might be
> thrown by new) but not about the memory allocated for automatic variables?

That's been partially answered over in [comp.lang.c++]: if you get a stack
overflow the stack is likely corrupted, some arguments pushed but a return
address not yet pushed.  Also, on a machine without hardware
supported bounds/address checking adding stack checking to every function
would impose a cost.  That's the same situation as with integer division by
zero, say: on some machines that can be easily detected by hardware, on
others detection would require costly software checks, and it's not
something you need in every or even most programs, so C++ doesn't give you
any standard detection mechanism  --  only pay for what you actually use.

The dynamic allocation that a C++ 'new' invokes is, on the other hand,
costly and reports whether it succeeds, so it's no big deal to pass that
information up to the programmer via an exception.


> (Given that such a decision is determined by certain requirements or
> restrictions).

?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

thx for the reply

>> I ve been told that "C++ does not have any mechanisms to check how close
>> the
>> "stack" is to its exhaustion, since the virtual machine on which C++
>> programs execute does not have any particular "stack"
>> implementation."
>
>That's correct
>
>>Should I assume that because it is not specified by the C++ standard, on
>> certain hardware platforms there may be no stack segment on which
>> automatic
>> variables are allocated to (unlike x86 perhaps?)?
>
> No, you can't really conclude anything about what hardware does from
> looking at what's left unspecified in the standard.
>

Is there a logical error?

try{
if ( C++ standard enforced a "stack" implementation)
            I am sure that no matter the hardware platform the allocation of
memory is stack oriented;
else
            I can assume that on certain hardware platforms the
implementation is not stack oriented;
}catch(...)
{ cout <<  "You are a beginner. You dont know what you are talking about";}

> Well, in part it's probably historical -- you want C programs just to
> run under C++ without having to consider whether simply entering a
> stack frame with only scalar automatic variables might throw.
>
I cant understand what you mean.

> Finally,although I'm fairly certain the original designers didn't consider
> this issue, you need to have some kinds of data that can be guaranteed
> to be manipulated without throwing, if only so that you can execute
> the actions that must happen during exception unwinding.  If you bring
> the possibility of scalar automatic variables throwing into the
> programming model, it becomes impossible to write any kind of
> reasonable recovery code.
>
Again I cant understand (please try to explain it in an uncomplicated way)

TIA

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"jimjim" <netuser@blueyonder.co.uk> writes:

>>> Should I assume that because it is not specified by the C++ standard, on
>>> certain hardware platforms there may be no stack segment on which
>>> automatic
>>> variables are allocated to (unlike x86 perhaps?)?
>>
>> No, you can't really conclude anything about what hardware does from
>> looking at what's left unspecified in the standard.
>
> Is there a logical error?
>
> try{
> if ( C++ standard enforced a "stack" implementation)
>             I am sure that no matter the hardware platform the allocation of
> memory is stack oriented;
> else
>             I can assume that on certain hardware platforms the
> implementation is not stack oriented;
> }catch(...)
> { cout <<  "You are a beginner. You dont know what you are talking about";}

Yes, there's a logical error.  The C++ standard is written to avoid
putting needless constraints on possible implementations, so you can't
conclude that a non-stack-oriented implementation actually exists from
the fact that it isn't forbidden.

>> Well, in part it's probably historical -- you want C programs just to
>> run under C++ without having to consider whether simply entering a
>> stack frame with only scalar automatic variables might throw.
>>
> I cant understand what you mean.

Most programs not written with exceptions in mind become broken if one
of the operations they use starts to throw exceptions.  Of course C
programs aren't written with exceptions in mind.  If using an
automatic ("on the stack") int variable could cause an exception, it
would render the program broken.

>> Finally,although I'm fairly certain the original designers didn't consider
>> this issue, you need to have some kinds of data that can be guaranteed
>> to be manipulated without throwing, if only so that you can execute
>> the actions that must happen during exception unwinding.  If you bring
>> the possibility of scalar automatic variables throwing into the
>> programming model, it becomes impossible to write any kind of
>> reasonable recovery code.
>>
> Again I cant understand (please try to explain it in an
> uncomplicated way)

Can you give me some hint about where I lost you?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]