subroutine stack and C machine model

[Moi]

@invalid.address.org> writes: [...]

[the discussion has moved the point that in priciple different
computations can be executed in parallel]

I'm not sure if a compliant C implementation could do this, but it is
certainly permitted to reorder things. Heavy application of the As If
Rule could presumably allow parallel execution.

Consider
     f (g(), h());

most Pascal implementaions would execute the functions in the order g,
h, f. Most C (or older ones anyway) would execute them in the order h,
g,f (it makes varargs functions eaier to implement).

OK, I didn't know that. I believe the Microsoft compiler I used circa
1991 went left to right but I may have assumed this because of my well-
known tendency to, like a sensible, intelligent person, confuse comma-
as-op with comma-as-parm-sep.

But: in this era, guys like Schildt could KNOW, after making an
experiment and/or examining the compiler output, the order. In the
absence of a standard they were in fact justified at generalizing this
knowledge.

Yes, you're right. Guys like Schildt *should* have known.
And they should have known by performing an N=1 experiment with a random compiler
"du jour" but by looking it up in the language spec.
And since the book was called "The Annotated C Standard",
it could just as well have been the standard itself.

But as we know this killed portability since in fact other compilers
went left to right.

Which was perfectly legal, as explained before.

But note that the grand and glorious standard didn't help because like
Rabbi Levine, it said, "you're both right". It did so not through
tolerance but in order to avoid having to discommode vendors.

I don't know Rabbi Levine, but I don't think that is relevant.

AvK

 

[Phil Carmody]

Absolutely it is.


Not that I've noticed.

Hint: My dislike of the "container class" thing is not because I don't like
abstractions or higher-level thinking. It's because I'd rather pick
abstractions with some awareness of the specific circumstance in which I'm
using them, and because I don't think "container" is a useful abstraction
in a language without something comparable to inheritance or interfaces.

It's not necessarily any better in those kinds of languages. I don't
know if you've ever cplusplussed, but I remember the discussions that
surrounded the idea of an 'object' base class that everything would
be derived from. By the time you've abstracted away so much that you
don't know what the thing is and what it's used for, then you've
started to lose sight of the problem that you were initially trying
to solve.

The biggest muck-ups I've ever had to fix have been because coders
have without thinking stuck objects into inappropriate containers,
with the presumption that the precise behaviour of the container was
irrelevant. All of these coders had 'Design Patterns' on their
bookshelf. Just sayin'.

Phil

 

[Phil Carmody]

int fa(int a);
int fb(int a, int b); /* not shown, but recurses back to fa() or fb() */

int fa(int a)
{
int r;
r = (some condition ? fb( fa(a+1), fa(a-1) ) : a;
return r;
}

**/

...
How is it possible that the "two function calls" "could" be executed
in parallel? C99 standard 6.5.17: "The left operand of a comma
operator is evaluated as a void expression: there is a sequence point
after its evaluation. THEN [emphasis mine] the right operand is
evaluated...".

Where in the above fragment is a comma operator used?

Where's Richard's "You really know bugger all about C" comment,
or whatever it was.

Then again, can we please stop punching this palooka?

Phil

 

[Seebs]

Seebs a écrit :

That is exactly what my interface proposes. Some opeartions like
"Add" for adding an element, or "GetElement" for retrieving
contents, and some others are common to all containers I propose.

Great. So let's see a hunk of code that takes a pointer to a container
object, without knowing what kind of container it is, and other code
calling it with arrays and lists.

This may turn out to be a bit tricky to get right. It's not enough that
the invocations would be spelled the same; the object representations
underlying them also have to be compatible enough that, if you pass two
containers to the same function, and one's an array and one's a list, it
can use them both correctly using the same container calls.

Well it is different, there was a misunderstanding. And so what? What has that to do
with what we are discussing now?

It makes me less sure of whether you understand the distinctions I'm drawing.

-s

 

[Seebs]

It's not necessarily any better in those kinds of languages.

No. But it at least makes sense, because you can write code that
takes reasonable advantage of the attributes of the Array or the List,
but then you can turn around and share at least some stuff with code
that's built for Container. That makes *sense*.

If you can't pass an object of any-of-those-types to a function and
expect it to do the right thing, then "container" turns out to be close to
useless, while array and list are actually still both useful.

The biggest muck-ups I've ever had to fix have been because coders
have without thinking stuck objects into inappropriate containers,
with the presumption that the precise behaviour of the container was
irrelevant. All of these coders had 'Design Patterns' on their
bookshelf. Just sayin'.

Yeah, it turns out behavior does matter.

-s

 

[Moi]

Where's Richard's "You really know bugger all about C" comment, or
whatever it was.

Strange thing: no one seems to have noticed the extra '(' yet.

Then again, can we please stop punching this palooka?

AvK

 

[spinoza1111]

In
spinoza1111wrote: [...]

It happens to
be possible to tell the difference between "an expression known not
to have side effects" and "an expression which may have side
effects" from syntax alone even in C,

  int x = foo();

According to you, it is possible to determine whether the above
expression has side effects. I disagree. Please present evidence to
support your assertion.

[...]

Richard, it appears that one of us has misinterpreted whatspinoza1111
wrote.

foo() is not "an expression known not to have side effects".  It is
"an expression which may have side effects".  It is possible to tell
the difference.

Any C expression is in one of three sets:
    1. Expressions known not to have side effects;
    2. Expressions which may or may not have side effects;
    3. Expressions known to have side effects.

where the word "known" refers to what's known by a particular
compiler with a particular set of options.  For a sufficiently lazy
compiler, the first and third sets could be empty, though at least
all constant expressions should be in the first set.

spinoza1111does not appear to have claimed that it's always possible
to determine whether a given expression has side effects or not
(though he may well have done so in material which you didn't quote).

No, I didn't, and I agree with Keith's phrasing. I had to solve this
problem at Bell Northern Research in an in house compiler.

Optimizers often use a sort of "three valued" logic which to the
ignorant can be confusing and sound like Donald Rumsfeld's "known
unknowns" but has a precise meaning. The problem with C is that what
uneducated and autodidact programmers (including programmers innocent
of university computer science) think is "power" is in fact a LARGER
set of unknowable-effect statements than in languages that were,
unlike C, not developed in a fit of adolescent vanity.

Given that Keith Thompson has confirmed my phrasing while disapproving
of me in so many ways, I now ask for a set of apologies for the
personal destruction posts including Ben Bacarisse's vicious little
remark this morning concerning my helpful response to a poster who
needed assistance in a recursive descent assignment. I also would ask
you faggots to ponder the similarities between your use of your own
limitations, including your limitations in reading comprehension, and
the much more vicious attacks on Herb Schildt. In particular, I need
Peter Seebach to replace his post "C: The Complete Nonsense" with an
apology to Herb and his family for the damage done.

Thank you.

 

[spinoza1111]

Heathfield puts his foot in doo doo because I would never, in the
absence of further information, say that the above statement belongs
to the class of "C statements that are known not to have side effects"
because I don't see the code of foo. If the code of foo is unavailable
to an optimizer doing this taxonomy, it would put the statement in the
unknown class.

Heathfield is mobilizing his own limitations and that of his followers
here in what Adorno calls the "negative dialectic". This is where the
pulse of history reverses sign and instead of sharing knowledge and
using knowledge, people spread ignorance through a misnamed
"skepticism" and a false asceticism of belief.

I think he may be right, at least on this specific example.  You will
note that he does not refer to an expression which *does* have side
effects, only one which *may* have side effects.  I'd say the above is
in the latter category, as it contains a function call, and function
calls *may* have side effects.

Examples:

int x = 3 + 4; /* known not to have side effects */
int z = x++; /* may have side effects */

Note that we are not distinguishing between "may have side effects" and
"necessarily has side effects".  We can't, because function calls are
ambiguous in that regard.  But if an expression has no function calls in it,
you can tell whether or not it has side effects in most cases.  You can
always tell whether it may, except that in some cases the probability is zero:

int a = (x <= z) ? (++x) : (0);

I would say that strictly speaking, we know that this expression does not
have side effects, because (assuming no intervening code), we know that x is
8 and z is 7, so we necessarily don't evaluate the ++x.  However, I think
this analysis proves his point incorrect.  You can correctly determine that
this expression CANNOT have a side effect, but you can't do it by looking
only at the syntax.

On Seebach's left shoulder we see a better angel of his nature: on his
right, a worse. We see him figuring out compiler optimization on his
very own, having majored in something other than compsci in skewl
(perhaps to his credit math).

But I'm afraid you don't even know, Peter, what means "syntax". If the
above statement is preceded by assignments to x and 7 of constants,
flow analysis syntactically proves that the second statement inherits
the property of being without side effects. If you define "flow
analysis" as "not syntax", that's the logical fallacy of definition
against disproof. And if you start shit with me over the meaning of
"syntax", I swear to God I'll finish it.

I do not have a lot of experience in C compilers, but it now appears
to me you have less.

On the other hand, it may be that for his purposes, this counts as "may have
side effects", even though the probability of the side effect occurring is
zero.  You can certainly identify a category of expressions that absolutely
do not have side effects, by syntax alone -- there are some expressions where
analyzing the syntax of the expression proves that there can never be side
effects.  (Actually, I'm not sure of this, either.  Does access to a volatile
count as a "side effect"?  If so, I don't think that counts as a syntactic
feature anymore.  Syntactically, volatile's just a qualifier, it doesn't
have any unique syntactic role...)

You really should have taken those classes. All this stuff is in Aho/
Sethi/Ullman. It is doable for some C and it's what optimizers do.
This is why you erred if as a voting member of the C99 standards
effort, you issued an across the board declaration that the "mere" C
programmer could not have the right to expect certain orders of
evaluation in non-optimized code in order to protect the profits of
your corporate sponsors.

 

[Ben Bacarisse]

... Does access to a volatile count as a "side effect"?

Yes. See 5.1.2.3 paragraph 2.

Your "scare quotes" mean that you might have your own meaning in mind
here but I think it counts for the purposes of your argument as well
as simply meeting the standard's definitions of the term.

<snip>

 

[Seebs]

Yes. See 5.1.2.3 paragraph 2.

Thanks. My memory's gone to bits lately. (Long, long, story involving
ADHD medication, the word "fibrillation", and the discovery that I might
be approved to have a small amount of caffeine sometime in late 2010.
Maybe.)

Your "scare quotes" mean that you might have your own meaning in mind
here but I think it counts for the purposes of your argument as well
as simply meeting the standard's definitions of the term.

In that case, meant to denote the spec's formal meaning as opposed to a
plain-English reading.

Okay, given that, it seems to me that the only expressions which can
be, from analysis of syntax, "known not to contain any side effects",
would be constant expressions. Any expression involving a variable
could, if the variable is volatile-qualified, have side-effects. But
you can't tell by looking at syntax whether a variable is volatile-qualified,
because syntactically, that's just a "type qualifier", and you can't tell
it from const or restrict.

So there's no way you can tell:

const int i = 3;
from
volatile int i = 3;
at the syntax level, and the latter looks to me to contain a side effect.
(Possibly; the implementation could define that initialization is not an
access, I suppose.)

But on the other hand:
3 + 1; /* known not to contain side effects */

So strictly speaking, Spinny's right -- you can determine that at least some
expressions have no side effects, by analysis at the syntax level. However,
since the vast majority of expressions might have side effects (and indeed,
I think most other than typical control expressions DO), it seems useless.
You can't, in general, be sure of whether or not an expression has
side-effects by looking at the syntax.

-s

 

[Seebs]

You are several hundred apologies in arrears. Care to settle up?

I normally don't think apologies work that way. In general, I apologize
if I am convinced that I was in error (or that I harmed someone inadvertantly
in a way that I regret, etc.), and I don't waste time worrying about whether
other people do the same.

Basically, look at it this way:

Consider the likelihood, given a claim from that particular poster, that
you would believe the claim to be true on the grounds that he asserted it.
What does this tell you about a hypothetical case where he claims to be
sorry for something? From what I've seen, he'd be wrong more often than
not...

-s

 

[spinoza1111]

In





spinoza1111wrote:



It is quite true that I misinterpreted you. It is also true that this
is not the first mistake I've ever made. I'm not perfect, after all.
Neither will it be the last mistake I ever make.

Awareness of your posting history leads me to recognise that you will
milk this tiny mistake all you can. It is well for you that I do not
behave that way to you, given the vast number of mistakes you make.

Provide a list of these putative mistakes, and omit "pissing you off".
Also omit "being smarter than you".

And better looking.

 

[spinoza1111]

I normally don't think apologies work that way.  In general, I apologize
if I am convinced that I was in error (or that I harmed someone inadvertantly
in a way that I regret, etc.), and I don't waste time worrying about whether
other people do the same.

Basically, look at it this way:

Consider the likelihood, given a claim from that particular poster, that
you would believe the claim to be true on the grounds that he asserted it..
What does this tell you about a hypothetical case where he claims to be
sorry for something?  From what I've seen, he'd be wrong more often than
not...

Here we go again. Neither you nor Richard have established the
existence of the hundreds of errors you accuse either me or Schildt or
making. Instead, you identified about ten in "C: The Complete
Nonsense". But like Fox News or Senator McCarthy, both of you go on to
make reference to "thousands" of errors which deludes fools who reason
illogically that because a voting member of C99 (without formal
education in comp sci) and the editor (not the author) of a grand
total of one book say so, it must be true, especially because they are
so obviously willing to use this facility to ruin the careers of
anyone who disagrees with them.

You have in fact exhibited a formal case of ad hominem. I need you to
apologize to me, and remove "C: The Complete Nonsense".

 

[spinoza1111]

In





spinoza1111wrote:



It is quite true that I misinterpreted you. It is also true that this
is not the first mistake I've ever made. I'm not perfect, after all.
Neither will it be the last mistake I ever make.

Awareness of your posting history leads me to recognise that you will
milk this tiny mistake all you can. It is well for you that I do not
behave that way to you, given the vast number of mistakes you make.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within- Hide quoted text -

- Show quoted text -

"Nilges has (gasp) calculated the end limit of a for loop in (gasp) a
for loop"

"Nilges has (horrors) mistook comma as operator for comma as
separator. Twice."

"Schildt forgot (oh the humanity) to mention free(NULL)."

"Schildt doesn't return (the pain! the pain!) the right value to the
OS."

"Schildt talks about a stack. I make 200 grand a year as a programmer
with a music degree and I have never hoid of a stack since I program a
pornographic toy. Alert the media."

Then...

"This must be wrong since Nilges said it. Oops, it's right. Well,
there must be a large number of errors he's made."

[Cue, somewhere over the rainbow]

These sorts of things happen in corporations where managers are too
unqualified to make proper technical judgements and delegate them to
the fattest programmers with the largest mouths, who then promote
their buddies. This facility needs in Habermas' sense to be an escape
from that where an OP can get a straight answer without some clown
like Ben Bacarisse telling the OP that the respondent is not to be
trusted.

In fact, it is correct that for better or worse, and in my view to
protect corporate profits, the C99 standard followed the lead of Algol
68 (a disaster) and made too many things undefined. It means that
quite independent of the politics of personal destruction, a case can
be made for downsizing one's style to one that is safe given C99's
"known unknowns, unknown knowns, and unknown unknowns". Instead of
writing his tirade against Schildt, Seebach should have proposed a
book criticising Microsoft's market power, because this market power
created the illusion that C must work the way Microsoft's compilers
work.

But this would take moral courage which is lacking in a person quite
willing to trash a defenseless computer author, alongside hard work
and an ability to communicate. A compsci degree would help but is not
essential.

 

[spinoza1111]

In
<86ca92d9-8821-417f-b7fe-2b68ec749...@i12g2000prg.googlegroups.com>,

[snips]

He does know that. And C does allow one to sensibly predict what code
will do, *provided* one observes good practice - which perhaps goes a
long way towards explaining your attitude.

"Good practice" means abandoning K & R's clear implication that work
could be done in expressions, the subexpressions of which have side
effects, allowing hand optimization in assembler language style. It
means doing something that modern compilers can and should do, which
is to avoid "code motion" when the syntax of a construction shows that
it is unknown whether an expression has a side effect.

In a(b,c) where b is a constant or even a term (for example an int) it
makes sense in certain environments to "evaluate" b after a or even in
parallel. However, the natural expectation of most programmers with
computer science training and experience in other languages is left to
right evaluation and this expectation, not vendor profits, should have
been honored in the C99 standard, by reassuring, not vendor
stockholders, but programmers that their instincts would be honored.

This is because educated people, for better or worse, read left to
right in the modern world even when their original language is right
to left because of the dominance of English...especially in scientific
and technical communication.

The instinct of any competent programmer is going to be to read the
documentation and find out what it says about evaluation order. And then
tailor their code to follow the rules. Software is not mathematics, as
should be clear from the fact that I can write, e.g., x = x + 1; and
neither is it natural language.

Any programmer who thinks otherwise is clearly somewhat naive.
Personally I don't write code that relies on evaluation order.

That's interesting. How do you write any code at all?

a=b; c=a;

"relies on evaluation order" as I rilly hope you know.

Sorry, that was a cheap shot. I realize that primarily to protect
vendor profits, the concept of sync points was invented by unqualified
people (some of whom had not taken compsci classes) and the left to
right expectation of normal, intelligent programmers (which doesn't
include APL apes, of course) was violated.

Which means that C to be safe has to use end-of-statement to express
evaluation order.

But part of the claim of C's efficiency was the ability to fold side
effects into expressions in tight loops.

Basically, the Standard seems to me to have made a sow's ear. It took
K & R C, which could for all its defects be used to write tight code,
and made it into Fortran...with even more ways than Fortran to screw
up.

Nice going, Peter. I won't be nominating you for a Nobel anytime
despite my friendship with the Nobel committee.

[Har har. That's a joke, son. I know no-one on the Nobel committee,
and I knew a grand total of one Nobelist. That was Nash as all you
clowns have heard. Many times.]

 

[Chris McDonald]

Nice going, Peter. I won't be nominating you for a Nobel anytime
despite my friendship with the Nobel committee.

[Har har. That's a joke, son. I know no-one on the Nobel committee,
and I knew a grand total of one Nobelist. That was Nash as all you
clowns have heard. Many times.]

Ah, great, another use of Nash in an attempt to prop up your credidibility.

If you knew anything relevant, you'd know that one cannot be a awarded
a Nobel Prize for Computer Science (or, indeed, for Mathematics).

 

[jacob navia]

Barry a écrit :

In normal programming this doesn't happen, because it's not possible.

I showed code in C that does exactly that. If the common
operations in all containers are at the same place in the virtual table
they are binary compatible and all of them can be used with the same
interface.

Device drivers with direct memory access are as close as it gets.
????

Of course they are written in assembly or C.

Well, we are discussing C precisely.

 

[Nick Keighley]

a=b; c=a;

"relies on evaluation order" as I rilly hope you know.

Sorry, that was a cheap shot. I realize that primarily to protect
vendor profits, the concept of sync points was invented by unqualified
people (some of whom had not taken compsci classes) and the left to
right expectation of normal, intelligent programmers (which doesn't
include APL apes, of course) was violated.

Did you read the post where I quote from the standards for several
different languages? ALL of which don't specify the order of
evaluation of function/procedure arguments.

The only one I've found so far is Java.

 

[spinoza1111]

Did you read the post where I quote from the standards for several
different languages? ALL of which don't specify the order of
evaluation of function/procedure arguments.

The only one I've found so far is Java.

Then you missed C Sharp:

"Except for the assignment operators and the null coalescing operator,
all binary operators are left-associative, meaning that operations are
performed left to right."

"The assignment operators, null coalescing operator and the
conditional operator (? are right-associative, meaning that
operations are performed from right to left"

ISO IEC 23270

 

[spinoza1111]

Nice going, Peter. I won't be nominating you for a Nobel anytime
despite my friendship with the Nobel committee.
[Har har. That's a joke, son. I know no-one on the Nobel committee,
and I knew a grand total of one Nobelist. That was Nash as all you
clowns have heard. Many times.]

Ah, great, another use of Nash in an attempt to prop up your credidibility.

Along with the ability to spell, experience in using multiple C
compilers to support the work of a Nobelist, the completion (with an A
+ average) of most of the work towards MSCS in computer science, and
the completion of the first class in comp sci offered at my
undergraduate institution.

What for you would constitute the difference between a bogus attempt
to prop up credidibility [sic] and qualifications? The willingness to
destroy other people's reputations out of the blue for shits and
giggles?