bunch of pedants

[jacob navia]

void foo(int a)
{
int b;
if (condition_not_met()) foo(a);
}

assembly skeleton pseudocode:

void foo(int a)
{
allocate b and store it in a hash table...
call condition_not_met() test function
if return is true{
allocate a copy of a and put it in a hash table. Give this copy to
new foo() call
find copy of a in hash table
remove a from hash table
}
...
remove b from hash table
}

This is not a stack (and just to be contrary, I will remove items
stored a,b,c in order a,b,c instead of b,c,a when I exit). It will
run on a machine without a hardware stack or a software stack.
Logically, it produces the same result as using a stack would.

Thanks. I am collecting all the regular's speculation in a paper
I will send to Guiness. Your proposal is quite similar
to one proposed before, where the stack is implicitely done with
a clock.

Hash tables are normally indexed by names. If you have several "b"s
in your hash table, which one will you remove?

Then, you will have a naming schema, that will simulate stack using
timestamps or similar mechanisms...

Fantastic!

And so what?

This is a typical attitude of the regulars here.

1) They say
"C doesn't use a stack. The word is not mentioned in the standard"

Objective: Confuse beginners and display pedantic knowledge...

2) When confronted to reality (no implementation exists that doesn't use
a stack, and above all, confronted with the stack like structure of
the language itself) they start with

3) An implementation *could* exist that... etc.

This is similar to their "trap representation", "one's complement" or
"sign magnitude" stuff... Nobody has ever seen those machines, there are
no implementations but

"... an implementation *could* exist" and there they go.


But all that is harmless. LET IT BE.

You believe "C" (whatever you understand with that) doesn't need a
stack?

Be happy!!!

Live your life!!!

 

[Nick Keighley]

I don't understand. If [no stack] is required for ordinary functions,
why is one required for recursive functions? How does a
self-invocation differ from invocation of some other function?

I knew a compiler once that planted the return address
at the beginning of the called function. That is
*it edited the code* for the called function.

<scream>"run away"</scream>

fun: b:mody *+1
jmp 0

some code

jmp fun+1

I don't have the assembler exactly right. But the b:mody
added the B register to the specified address. Hence jmp 0
became the return. Once recursion was added a different
calling sequence had to be used. The language distinguised between
recursive and non-recursive procedures.

RECURSIVE list walk (TABLE list)
BEGIN
IF list.ptr = 0
THEN RETURN
ELSE list walk (list.ptr)
END;

syntax may be wrong...

 

[Rod Pemberton]

or to mention that it was
published 30 years ago.

So, the C language was standardized 22 years ago... 1986.

"Work on the first official C standard began in 1983 under the auspices of
the X3J11 ANSI committee. The major functional additions to the language
were settled by the end of 1986, at which point it became common for
programmers to distinguish between 'K&R C' and 'ANSI C'. ... While the core
of ANSI C was settled early, arguments over the contents of the standard
libraries dragged on for years."
- "The Art of Unix Programming", Chapter 17 "Evolution of C", Eric S.
Raymond

By mentioning the date as if it makes the information irrelevant, aren't you
implying the eight years between the two made a difference in the way C was
being implemented on the von Neumann microprocessors and cpu's of the era?
Aren't you implying that some processor between 1978 and 1986 exists for
which there is an ANSI compliant C compiler which can't implement a stack 1)
even though C was standardized from working C implementations and 2) even
though it is requirement of C to be able to implement contiguous sequences
of objects? A call stack is just a contiguous sequence of many procedure
activation records or stack frames, i.e., an array.


Rod Pemberton

 

[Dik T. Winter]

> Peter Nilsson wrote: ....
>
> I don't understand. If none is required for ordinary functions,
> why is one required for recursive functions? How does a
> self-invocation differ from invocation of some other function?

If everything is non-recursive, each variable can get a fixed address.
If there is recursion, that is not possible for the variables local
to the function that recurses.

 

[Morris Dovey]

I don't understand. If [no stack] is required for ordinary functions,
why is one required for recursive functions? How does a
self-invocation differ from invocation of some other function?

I knew a compiler once that planted the return address
at the beginning of the called function. That is
*it edited the code* for the called function.

<scream>"run away"</scream>

fun: b:mody *+1
jmp 0

some code

jmp fun+1

I don't have the assembler exactly right. But the b:mody
added the B register to the specified address. Hence jmp 0
became the return. Once recursion was added a different
calling sequence had to be used. The language distinguised between
recursive and non-recursive procedures.

RECURSIVE list walk (TABLE list)
BEGIN
IF list.ptr = 0
THEN RETURN
ELSE list walk (list.ptr)
END;

syntax may be wrong...

Yuppers. The old IBM 1130 and 1800 hardware stored the return
address at the called address (entry point) and began execution
with the instruction in the following location, so that an
indirect branch through the entry point effected the return.

ENTRY DC *-* # entry point
# (program)
BSC I ENTRY # return to caller

However, that still didn't preclude _saving_ the return address
(and anything else that need saving) and recursing - then
restoring on return. It was enough of a PIA that the only time we
wrote recursive code was for play - or for bragging rights.

However with memory management recursion using save areas would
have been fairly easy - although severely limited by the small
(typically 8K 16-bit words) core memories.

 

[Morris Dovey]

If everything is non-recursive, each variable can get a fixed address.
If there is recursion, that is not possible for the variables local
to the function that recurses.

Hmm - ok. I was thinking of saving a copy of local variables with
each level of calling without thinking of that as a "stack"
(which, in the broader sense, it would have been). Thanks.

 

[Keith Thompson]

So, the C language was standardized 22 years ago... 1986.

The standard wasn't published until 1989. No, I'm not saying that
that 3-year difference is critical.

"Work on the first official C standard began in 1983 under the auspices of
the X3J11 ANSI committee. The major functional additions to the language
were settled by the end of 1986, at which point it became common for
programmers to distinguish between 'K&R C' and 'ANSI C'. ... While the core
of ANSI C was settled early, arguments over the contents of the standard
libraries dragged on for years."
- "The Art of Unix Programming", Chapter 17 "Evolution of C", Eric S.
Raymond

By mentioning the date as if it makes the information irrelevant, aren't you
implying the eight years between the two made a difference in the way C was
being implemented on the von Neumann microprocessors and cpu's of the era?
Aren't you implying that some processor between 1978 and 1986 exists for
which there is an ANSI compliant C compiler which can't implement a stack 1)
even though C was standardized from working C implementations and 2) even
though it is requirement of C to be able to implement contiguous sequences
of objects? A call stack is just a contiguous sequence of many procedure
activation records or stack frames, i.e., an array.

jacob quoted a paragraph about C and stacks, and said only that "This
was written by an expert in C". I honestly don't know why he didn't
cite the source (a paper by Johnson and Ritchie; the URL was posted in
another thread); I would think that mentioning Ritchie's name would
have strengthened his argument. As for the fact that it was published
30 years ago, I didn't say or imply that that makes the information
irrelevant; I merely pointed out that jacob didn't bother to mention
it. IMHO the date of the paper is *part of* the information needed to
judge how relevant the paper is today.

Things have changed since 1978. For one thing, C has been implemented
on a wider range of hardware now than it had been then.

In particular, at least according to some accounts here, and in spite
of jacob's denials, an IBM mainframe C implementation exists that
doesn't use a single contiguous stack. (I have practically no direct
experience with IBM mainframes, so I can't directly determine who's
right.) It's likely that that implementation did not yet exist in
1978.

 

[lawrence.jones]

This is similar to their "trap representation", "one's complement" or
"sign magnitude" stuff... Nobody has ever seen those machines, there are
no implementations but

"... an implementation *could* exist" and there they go.

DEC's Vax floating-point formats have trap representations, as does IEEE
floating-point (signaling NaNs). Unisys mainframes use one's complement
integers. Nearly all floating-point formats use sign/magnitude.
They're not nearly as chimerical as you think.

-Larry Jones

The authorities are trying to silence any view contrary to their own!
-- Calvin

 

[jacob navia]

DEC's Vax floating-point formats have trap representations, as does IEEE
floating-point (signaling NaNs).

All FPUs have "trap representations" then. A nan will generate a trap
on Intel processors if the corresponding flag is cleared in the
control word. Great.

Unisys mainframes use one's complement
integers.

You are out of date. As far as the UNISYS processors for sale
today, they use all Intel processors. See:

http://www.serverwatch.com/hreviews/article.php/3304111

for example.
In any case, it WAS used EONS ago in UNIVAC processors. As I said
before your information is not current.

Nearly all floating-point formats use sign/magnitude.
They're not nearly as chimerical as you think.

-Larry Jones

Maybe, but here it is used without any reference to floating point.
As far as I can see there isn't a single machine that uses one's
complement that is in use today.

The same for sign magnitude. This is a representation used in the IBM
7090, and it is really completely out of date unless you happen to live
in the sixties... The 7090 was produced in 1959.

 

[lawrence.jones]

In particular, at least according to some accounts here, and in spite
of jacob's denials, an IBM mainframe C implementation exists that
doesn't use a single contiguous stack. (I have practically no direct
experience with IBM mainframes, so I can't directly determine who's
right.) It's likely that that implementation did not yet exist in
1978.

It did not. However, AT&T's portable C compiler (pcc) was ported to the
IBM mainframe environment not too long after that and, as I recall, it
also didn't use a single contiguous stack.

-Larry Jones

Buddy, if you think I'm even going to BE here, you're crazy! -- Calvin

 

[user923005]

Thanks. I am collecting all the regular's speculation in a paper
I will send to Guiness. Your proposal is quite similar
to one proposed before, where the stack is implicitely done with
a clock.

Hash tables are normally indexed by names. If you have several "b"s
in your hash table, which one will you remove?

The one with the address that was returned by malloc().

Then, you will have a naming schema, that will simulate stack using
timestamps or similar mechanisms...

Fantastic!

And so what?

This is a typical attitude of the regulars here.

1) They say
    "C doesn't use a stack. The word is not mentioned in the standard"

I don't think any regular has ever said that. They said:
"The C language does not specify a stack. Probably most
implementations use one but there are alternatives."
Or something like that. Your syle of argument here is called "a straw
man."

    Objective: Confuse beginners and display pedantic knowledge...

I think that the objective is to avoid assumptions that are not
necessary. In the case of C using a stack, it is a tempest in a
teapot. In other cases it is more important.

2) When confronted to reality (no implementation exists that doesn't use
    a stack, and above all, confronted with the stack like structure of
    the language itself) they start with

3) An implementation *could* exist that... etc.

This is similar to their "trap representation", "one's complement" or
"sign magnitude" stuff... Nobody has ever seen those machines, there are
no implementations but

"... an implementation *could* exist" and there they go.

There are implementations with trap representations.

But all that is harmless. LET IT BE.

You believe "C" (whatever you understand with that) doesn't need a
stack?

Alternative data structures are possible. Realistically, most C
implementations use one.

Be happy!!!

Live your life!!!

I agree that this is good advice.

 

[robertwessel2]

All FPUs have "trap representations" then. A nan will generate a trap
on Intel processors if the corresponding flag is cleared in the
control word. Great.

Traditional IBM mainframe (hex) float does not have any trap
representations. It's still in wide use, although IEEE binary float
has been supported by the hardware for about a decade, and the newest
machines also support IEEE decimal float.

You are out of date. As far as the UNISYS processors for sale
today, they use all Intel processors. See:

I don't believe that's correct. The high end systems are still "true"
hardware implementations, although the midrange ones are all emulated
on Intel processors. I believe that they've announced that in the
future they'll all be emulated. But the systems, either "real" or
emulated, still use the old ISAs, and run both MCP and OS 2200
(basically) unchanged on top of the Burroughs B5000 or Univac/Sperry
2200* ISAs respectively. The midrange systems can also run Windows,
and *nix, or even several at the same time. Both environments still
have active software development communities, although I have no idea
how much C development happens on MCP or OS 2200, but there's a fair
bit of Java.

*That's the one with one's complement arithmetic.

 

[Flash Gordon]

jacob navia wrote, On 19/03/08 16:33:

All FPUs have "trap representations" then. A nan will generate a trap
on Intel processors if the corresponding flag is cleared in the
control word. Great.

I believe there are a few more implementations than just the VAX an
Intel processors. Something about my having used other implementations
(where the processor did not have an FPU so all floating point was done
in software) suggests you are wrong. You are also completely
misrepresenting what Larry said.

You are out of date. As far as the UNISYS processors for sale
today, they use all Intel processors. See:

http://www.serverwatch.com/hreviews/article.php/3304111

for example.
In any case, it WAS used EONS ago in UNIVAC processors. As I said
before your information is not current.

No, you said, "no one has ever seen those machines." You are clearly
wrong since even you admit that the machines were built and I'm sure you
will not claim that everyone who ever used them was blind.

Maybe, but here it is used without any reference to floating point.
As far as I can see there isn't a single machine that uses one's
complement that is in use today.

So are you going to change you claim to, "there are no current
implementations" instead of the clearly incorrect claim of "no one has
ever seen those machines"?

The same for sign magnitude. This is a representation used in the IBM
7090, and it is really completely out of date unless you happen to live
in the sixties... The 7090 was produced in 1959.

As a general point you might be surprised about how long machines and
processors continue to be used after they go out of production. So
instance I know of a contract that was one which would involve modifying
software for a processor that had gone out of production 5 years earlier
and that another customer had plans to keep the kit going for another 20
years, i.e. 25 years after the processor was no longer manufactured.

 

[lawrence.jones]

As a general point you might be surprised about how long machines and
processors continue to be used after they go out of production.

And just because some feature is currently out of fashion does not mean
that it will remain so. Decimal arithmetic was dead and buried until
IBM started talking about decimal floating point a couple of years ago
and now it's taken on new life and is the hot new thing in computer
architecture.

-Larry Jones

Santa's gonna skip this block for years. -- Calvin

 

[Flash Gordon]

And just because some feature is currently out of fashion does not mean
that it will remain so. Decimal arithmetic was dead and buried until
IBM started talking about decimal floating point a couple of years ago
and now it's taken on new life and is the hot new thing in computer
architecture.

Yes, and I want it for my C application! ;-)

 

[Richard Bos]

Is it possible to store the parameters, call addresses and automatic
variables in a hash table or other random access list?
Is there a formal requirement that (for instance) the first parameter
is removed, and then the second and then the third?

No, but it is a formal requirement that the block- and function-scope
objects of the last called function are removed before those of the one
which called it, and that one's variables before those of the one which
called it, and so on - or at least, that the program itself cannot tell
the difference without straying into UB.
That is, C does require at least a notional call stack. This stack _may_
be entirely ephemeral and exist only in the background, but the program
must behave as if it exists.

However, when posters come here with questions of "why does C put arrays
on the stack and not on the heap", or "does the C stack grow up or
down"[1], or when they insist that "every compiler which is used in the
real world[2] uses the stack", they do _not_ mean that stack, but the
(usually single) hardware and/or OS-provided stack, which C is not
required to use.

Richard

[1] A question for which I've never found an earthly reason why an
ordinary, non-implementor programmer should even care about the
answer, but that's by-the-by.
[2] I.e. to them, usually, on post-2004 Wintel machines, or so it
appears, but that, too, is by-the-by

 

[Philip Potter]

However, when posters come here with questions of "why does C put arrays
on the stack and not on the heap", or "does the C stack grow up or
down"[1],

[1] A question for which I've never found an earthly reason why an
ordinary, non-implementor programmer should even care about the
answer, but that's by-the-by.

I see nothing wrong with wanting to know about the internals and
low-level jiggery-pokery for its own sake. This is, I feel, a
commendable attitude. It's just that C doesn't specify the internals
precisely because it is designed to run on top of a wide variety of
architectures, and that portable C code can't depend on such internals,
and such internals are offtopic here.

 

[Kenny McCormack]

However, when posters come here with questions of "why does C put arrays
on the stack and not on the heap", or "does the C stack grow up or
down"[1], or when they insist that "every compiler which is used in the
real world[2] uses the stack", they do _not_ mean that stack, but the
(usually single) hardware and/or OS-provided stack, which C is not
required to use.

This is such an unbelievably dumb attitude.

Suppose this was a newsgroup about cars. Suppose somebody asked "Why do
cars have 4 wheels?" - or, equivalently, wanted to discuss the
attributes of 4-wheeled cars (the vast majority, by the way). Can you
imagine how dumb it would be - how stupid everyone would think you are -
if the only thing you (and all your cohorts, who are running the group)
could say is "There's no requirement that cars have 4 wheels." ? (In
fact, you would probably go on to say that there is no requirement that
cars have wheels at all. And that would be that. And all of your
buddies would back you up)

It just boggles the mind.

 

[lawrence.jones]

I see nothing wrong with wanting to know about the internals and
low-level jiggery-pokery for its own sake. This is, I feel, a
commendable attitude.

It can be, but asking questions about internals is frequently a prelude to
engaging in "unwarranted chumminess with the implementation", which
should generally be discouraged.

-Larry Jones

Something COULD happen today. And if anything DOES,
by golly, I'm going to be ready for it! -- Calvin

 

[Kenny McCormack]

It can be, but asking questions about internals is frequently a prelude to
engaging in "unwarranted chumminess with the implementation", which
should generally be discouraged.

Yes. By your mother. And by your priest.
But not in a generally accessed Usenet newsgroup, assumed to be
populated by consenting adults.