«

"Richard Bos" <> wrote in message
news:...
> insist that "every compiler which is used in the
> real world[2] uses the stack",
> [2] I.e. to them, usually, on post-2004 Wintel machines, or so it
> appears, but that, too, is by-the-by

post-2004? I don't own a complete post '98 machine... yet. For the real
real world, try every home computer in the US since 1978 or the PC marketing
war of 1981... and most business platforms too.


RP

"Philip Potter" <> wrote in message
news:fs03b5$vkj$...
> I see nothing wrong with wanting to know about the internals and
> low-level jiggery-pokery for its own sake.

I concur.

> This is, I feel, a
> commendable attitude.

I concur.

> It's just that C doesn't specify the internals

False. ANSI or ISO C STANDARDS documents don't specify C internals. C
_did_ and _does_ specify internals. Various C internals are specified in
numerous papers:

"Portability of C Programs and the UNIX System" by Johnson and Ritchie:
http://cm.bell-labs.com/cm/cs/who/dmr/portpap.html

"The C Language Calling Sequence" by Johnson and Ritchie
http://cm.bell-labs.com/cm/cs/who/dmr/clcs.html

"The UNIX Time-Sharing System" by Ritchie and Thompson
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html

"UNIX Operating System Porting Experiences" by Bodenstab, Houghton, et. al.
http://cm.bell-labs.com/cm/cs/who/dm...orts/newp.html

> precisely because it is designed to run on top of a wide variety of
> architectures,

False. You're confusing cause and effect. C wasn't designed to run on top
of a wide variety of architectures. C was reworked to work from
architecture to architecture by the original creators. And then, they
started a UNIX portability project which forced them to create a
minimalistic C machine model. Read "Portability of C Programs and the UNIX
System" by Johnson and Ritchie:
http://cm.bell-labs.com/cm/cs/who/dmr/portpap.html

> and that portable C code can't depend on such internals,

Despite what others will say, you'll eventually learn that C really isn't
all that portable:

1) 30% of C is portable only because microprocessor design over the past
30 years hasn't changed
2) 40% of C is force to be functionally equivalent
3) 30% of C just isn't portable and it's not worth your time trying to
make it so

Even the most portable language, FORTH, leaves much to the implementor,
because so much varies from architecture to architecture.

> such internals are offtopic here.

According to whom? I don't read much or post much here, but they aren't to
me. Are you interested in a Toll bridge in NY? Are you sure? It's for
sale, comes cheap, and has a nice stream and a good revenue stream... This
is an unmoderated, unchartered, international NG.


Rod Pemberton

Kenny McCormack <> wrote:
> In article <c8vcb5->,
> <> wrote:
>>Philip Potter <> wrote:
>>>
>>> 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.
>
> Yes. By your mother. And by your priest.
> But not in a generally accessed Usenet newsgroup, assumed to be
> populated by consenting adults.

Consenting, maybe, but adults seems doubtful given the current tenor of
the discussion.

-Larry Jones

Oh, now don't YOU start on me. -- Calvin

Rod Pemberton <> wrote:
>
> 1) 30% of C is portable only because microprocessor design over the past
> 30 years hasn't changed
> 2) 40% of C is force to be functionally equivalent
> 3) 30% of C just isn't portable and it's not worth your time trying to
> make it so

And 47.3% of all statistics are made up on the spot.

-Larry Jones

The real fun of living wisely is that you get to be smug about it. -- Hobbes

[snips]

On Wed, 19 Mar 2008 10:39:17 +0100, jacob navia wrote:

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

Here's a trivial notion:

void b(void);

void a(void)
{
b();
}

The hasher needs to know not b, but where in a to return to. Thus it
gets two pieces of information: the name "a" and the address to return
to. Since it's possible to have more than one entry matching a.hash (due
to recursion), the hasher may proceed as follows:

add:
for i = 0 to max
hash = a.returnaddress.i
if found continue
insert return address to hash.a.returnaddress.i


Net result, you can call from a 1,000 times with the same return address
and still get the "latest" when returning.

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

Dunno about fantastic, but functional.

> And so what?

Er, so it goes to show you can create implementations which need no stack
whatsoever, neither a hardware stack nor a logical one; all that's
required is a way to add, find and remove caller information.

> This is a typical attitude of the regulars here.

That C does _not_ require things that C actually doesn't require? Yes, it
should be the attitude of anyone using C.

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

Correct.

> Objective: Confuse beginners and display pedantic knowledge...

Objective: be correct. C does not require a stack; feel free to show any
such requirement in the standard. You can't, it's not there. Nor is
there need of a stack data structure.

> 2) When confronted to reality (no implementation exists that doesn't use
> a stack

Let's assume for the moment there is no such implementation; so what? Is
there a guarantee somewhere that there *won't* be such an implementation
tomorrow? If so, I can't find it.

> and above all, confronted with the stack like structure of
> the language itself) they start with

There is no stack-like structure to the language; there is a structure to
the language which necessitates _some_ form of management of return
addresses and the like, but nothing says that has to be a stack.

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

Correct. It could, as there's no guarantee that even if none exist
today, one won't exist tomorrow.

> 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.

This is why the standard is written the way it is; not to limit the
language to implementations or hardware designs which exist today, but to
make it maximally portable to almost any conceivable design - including
ones with no stacks, with trap representations, ones complement, you name
it.

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

No, we know this, as there is no such requirement in the standard. If
you feel differently, please show where, in the standard, such a thing is
required.

On Wed, 19 Mar 2008 07:33:09 -0500, Morris Dovey <>
wrote:
<snip>
> > 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

And presumably B was the return address set by caller or call?

If you really mean add this will only work once; you need something
somewhere to restore it to 0 before the next call. If you mean partial
overwrite aka replace, that's easier, see below.

> > became the return. Once recursion was added a different
> > calling sequence had to be used. <snip>

> 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
>
DEC PDP-5/8 also stored return address as the first word of the
routine (and started at the next one), but it was done by the
call-site instruction not in the callee. And -6/10 had this as one of
several options. With different assembler syntaxes, of course.

> 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.
>
Yep. Especially on the -5/8 which had no register for a stack pointer,
and the only support for an in-memory pointer was increment (but not
decrement) for 8 words. The real killer is multitasking/threading/etc;
that doesn't guarantee you enough time to 'fix things up'. In theory
interrupt service has the same issue, but in practice recursive
interrupts were too confusing to live anyway.

- formerly david.thompson1 || achar(64) || worldnet.att.net