Re: subroutine stack and C machine model

(Richard Tobin) writes:
> In article
> <0.704abb301ea09d7944c6.20091031175011GMT.878wertp >,
> Ben Bacarisse <> wrote:
>
>>>>> But in the
>>>>> past, in other folks' code, I do recall the use of ++ on non-lValues
>>>>> that compiled.
>
>>>>Broken compiler, if true.
>
>>> Not necesarily. For example, the useful *((int *)pc)++ was allowed in some
>>> pre-standard compilers and in some post-standard ones as an extension.
>>> That's not because the compilers in question were "broken".
>
>>I doubt that this is a counter-example. The most reasonable way to
>>permit the above is to extend the meaning of the cast operator so that
>>it yields an lvalue if it's operand is an lvalue.
>
> That would make Spinoza's claim meaningless, which it isn't. He
> obviously meant that the compiler allowed ++ on operands which were
> not lvalues according to the usual (standard) interpretation; how
> (if at all) this was rationalised is irrelevant to whether his claim
> is true and whether the compilers were broken.

It would make Spinoza's claim false, or at least unsupported in this
particular instance.

I don't know what he actually meant by his claim about "the use of ++
on non-lValues that compiled". But one simple explanation is that he
saw the use of ++ on a casted pointer and concluded, not that a casted
pointer is treated as an lvalue by that particular implementation, but
that the implementation permits ++ to be applied to a non-lvalue.

Given the level of C knowledge he's displayed, I hesitate to take his
claim literally. I suppose this could be settled if he provided a
concrete example, but I'm not holding my breath.

>>If memory serves, I think this has been done at least once.
>
> Some drafts of the ANSI standard made cast lvalue pointers "lvalues
> for the purpose of additive operations on them".

Interesting, I've never heard of that. Can you provide a citation?
(I understand that that might not be feasible.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

In article <>,
Keith Thompson <kst-> wrote:

>> Some drafts of the ANSI standard made cast lvalue pointers "lvalues
>> for the purpose of additive operations on them".

>Interesting, I've never heard of that. Can you provide a citation?
>(I understand that that might not be feasible.)

I have done so several times before, but annoyingly Google is unable
to find any. I probably have such a draft at work; if so I will try
to remember to post a reference on Monday.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin

(Richard Tobin) writes:
> In article <622a334d-cc8f-4f46-9736->,
> spinoza1111 <> wrote:
>
>>> If you're talking about Microsoft's C compiler, I'd be very interested
>>> in seeing some evidence to support your claim that it claims
>>> conformance with C99, since all indications from MS so far have been
>>> to the contrary.
>
>>Well, it doesn't use a random number generator to order a()+b().
>>Should it?
>
> Early versions of gcc effectively did. At least, they chose between
> different optimisations in a way that was not always consistent between
> instances of the same compiler version, and possibly not between
> runs of compiler. This was because it used qsort() to choose between
> optimisations, and qsort() is not guaranteed to be stable.
>
> This was noticed when gcc itself was used as a SPEC benchmark program,
> and unexpected differences were found in the output.

My google-fu is very poor today. The above sounds like it could
yield a fun Sunday afternoon's read - do you have any pointers or
magic search strings?

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

Phil Carmody

In article <hciqk0$n3b$>, I wrote:

>In article <>,
>Keith Thompson <kst-> wrote:

>>> Some drafts of the ANSI standard made cast lvalue pointers "lvalues
>>> for the purpose of additive operations on them".

>>Interesting, I've never heard of that. Can you provide a citation?
>>(I understand that that might not be feasible.)

>I have done so several times before, but annoyingly Google is unable
>to find any. I probably have such a draft at work; if so I will try
>to remember to post a reference on Monday.

Document X3J11/84-061, April 26 1984. Section 4.2.4 Cast operators:

If P is an lvalue of pointer type and T is the name of a pointer
type, (T)P is an lvalue of type T for purposes of additive
operations on P. Otherwise, if L is an lvalue and T is the name of
a type, (T)L is not an lvalue.

Example:

Provided the pointers s1 and s2 are suitably aligned, the following
code may be used to copy an array several characters at a time:

char *s1, *s2;
...
while(...)
*((long int *)s1)++ = *((long int *)s2)++;

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin

(Richard Tobin) writes:
> In article <hciqk0$n3b$>, I wrote:
>
>>In article <>,
>>Keith Thompson <kst-> wrote:
>
>>>> Some drafts of the ANSI standard made cast lvalue pointers "lvalues
>>>> for the purpose of additive operations on them".
>
>>>Interesting, I've never heard of that. Can you provide a citation?
>>>(I understand that that might not be feasible.)
>
>>I have done so several times before, but annoyingly Google is unable
>>to find any. I probably have such a draft at work; if so I will try
>>to remember to post a reference on Monday.
>
> Document X3J11/84-061, April 26 1984. Section 4.2.4 Cast operators:
>
> If P is an lvalue of pointer type and T is the name of a pointer
> type, (T)P is an lvalue of type T for purposes of additive
> operations on P. Otherwise, if L is an lvalue and T is the name of
> a type, (T)L is not an lvalue.
>
> Example:
>
> Provided the pointers s1 and s2 are suitably aligned, the following
> code may be used to copy an array several characters at a time:
>
> char *s1, *s2;
> ...
> while(...)
> *((long int *)s1)++ = *((long int *)s2)++;

Thank you.

I didn't realize that X3J11 had started that early, but I see from
the Wikipedia "ANSI C" article that the committee was formed in 1983.

Are these early drafts available online, or are they only in printed
form (Dead C Scrolls)? The 1990 ISO C standard itself is available
only in a PDF that appears to have been scanned from a printed copy,
so I'm not optimistic.

Incidentally, that article, <http://en.wikipedia.org/wiki/ANSI_C>,
is in need of some work. It says, correctly, that ANSI adopted
the ISO C99 standard in 2000, and then goes on to say that ANSI C
is now supported by almost all the widely used compilers (obviously
using "ANSI C" to refer to C89/C90, but that's not clear to reader
who doesn't already know the details.) The rest of the article is
very sketchy. The list of "Vendors supporting ANSI C" is:

* Microsoft (C90. A few features of C99)
* ARM RealView

It looks like it was written before the C99 standard came out, and
then only perfunctorily updated -- except that Wikipedia was founded
in 2001.

I think I have a Wikipedia account, but if someone else wants to work
on the article, go ahead. (No, spinoza1111, not you.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

In article <>,
Keith Thompson <kst-> wrote:
>Are these early drafts available online, or are they only in printed
>form (Dead C Scrolls)? The 1990 ISO C standard itself is available
>only in a PDF that appears to have been scanned from a printed copy,
>so I'm not optimistic.

I have only a couple of printed drafts. I could scan them in,
but it would be tedious. Perhaps some of the early committee members
have copies?

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin

In article <076a9825-f23e-4660-a7f2-> spinoza1111 <> writes:
> On Nov 2, 8:54 pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
....
> > > It can reorder a+b where a and b are unaliased lValues, but a good
> > > optimizer would not reorder a(...)+b(...), a+b(...), or a(...)+b,
> > > unless it had full information about the internals of a and b.
> > >
> > > Perhaps this is why Algol failed long term. Not knowing how to
> > > optimized, the developers of Algol adopted what Adorno called the
> > > "scientifically ascetic" viewpoint. Whereas languages controlled by
> > > vendors such as early Fortran were more portable as a practical matter
> > > simply because they ran on IBM machines or clones.
> >
> > You know that in Fortran in the expression:
> > A(...) + B(...)
> > A and B can be evaluated in any order? Worse, given the expression:
> > A(...) + A(...)
> > when the argument lists are the same, A need only be called once.
> >
> > And I have seen many non-portable Fortran programs and libraries in the
> > course of time.
>
> And this infantile disorder is a precedent we need use?

No, I mention it to refute your claim that Fortran was more portable.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Dik T. Winter

On 29 Oct 2009 15:30:44 GMT, Seebs <usenet-> wrote:

> On 2009-10-29, spinoza1111 <> wrote:

> > This is nonsense, since a||b and a&&b have always been implemented
> > such that b is not evaluated when a is true (in the case of or) or b
> > is false (in the case of and).
>
> "Always" may be a bit strong, there may be some stuff in the 1972 era
> that wasn't sure about it.
>
I doubt it. According to dmr's HOPL2 paper, on his website as
chist.html, B like BCPL had *both* semantics in & and | -- in a
predicate context they shortcircuited, and in a value context they
fully evaluated. He added && and || precisely to split off the
shortcircuit semantics, leaving & and | (and ^) bitwise.

> But! That is a special case, introduced because it allowed some particular
> idioms to work, such as "s && *s".
>
> It is, to use the term correctly (a rarity), the exception that proves the
> rule. The fact that these are called out as a special exception shows that
> the rule exists. The reason they're called out as a special exception even
> shows you why the rule exists.
>
(That's a phrase, not a term. <G>)

And I don't think this is quite right either. They imply that some
other rule exists, but they don't tell you what it is. It could be all
right to left, *except* for && || ?: and comma. It could be inmost
out, i.e. in same order as operator precedence and associativity;
IME this is even what some people expect, and in dataflow terms
I think it tends to be good if not optimal. It could be impl-defined:
documented, and at least sufficiently deterministic to be documented.
Of course actually it is unspecified -- explicitly.

<snip rest of criticisms I agree with>

David Thompson