C to Java Byte Code

[Richard Tobin]

Re: C to Java Byte Code

In article <2uas2oF27j6u9U 1@uni-berlin.de>,
Alfred Z. Newmane <a.newmane.remo ve@eastcoastcz. com> wrote:[color=blue]
>Richard Tobin wrote:[/color]
[color=blue][color=green]
>> No. It starts with the value 3, which is the value of the right-hand
>> side. Then that value is assigned to i, and i is incremented, but the
>> order of these two operations is not defined.[/color][/color]
[color=blue]
>Good point, thanks for mentioning it :-) Still, either order will still
>end up with 4. Either i ++'s to 4 and assigns that bakc to i, or i gets
>3, then ++'ed, giving 4 as well.[/color]

No. The possibilities include

- the rhs is evaluated as 3
- the rhs (3) is assigned to i
- i is incremented

where the result is that i ends up as 4, and

- the rhs is evaluated as 3
- i is incremented
- the rhs (3) is assigned to i

where i ends up as 3.

The standard allows any other behaviour, but the results above are the
most natural ones.

-- Richard

[Richard Tobin]

Re: C to Java Byte Code

In article <4180922a.17112 8963@news.indiv idual.net>,
Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:
[color=blue]
>Worse, in multi-processor or multi-pipeline systems, they could occur
>simultaneously . It isn't inconceivable for this to crash the program
>rather abruptly, or to write a completely unpredictable value to i.[/color]

For example, a C implementation on a multi-processor native INTERCAL
machine might do the assignment half-way through the evaluation of the
addition using the MINGLE and SELECT operators.

-- Richard

[John Bode]

Re: C to Java Byte Code

"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote in message news:<2uamopF26 f9lmU1@uni-berlin.de>...[color=blue]
> Old Wolf wrote:[color=green]
> > Paul Lutus <nospam@nosite. zzz> wrote:[color=darkred]
> >> Old Wolf wrote:
> >>
> >>> Sorry, you are wrong. There is no requirement in the C standard for
> >>> the members of the union to occupy the same piece of memory.
> >>> If you disagree then please quote a standard reference.
> >>
> >> http://explanation-guide.info/meanin...age-union.html
> >>
> >> "Because they occupy the same space, changing u.a also changes the
> >> value of u.b."
> >>
> >> "The primary usefulness of a union is to conserve space, since it
> >> provides a way of letting many different types be stored in the same
> >> space."
> >>
> >> There are plenty of similar references[/color]
> >
> > And what makes you think those pages are accurate?
> > None of these contain references to the C standard.
> > They are comments made by people who are used to programming on
> > implementations that do the what those quotes say. However it is
> > possible to have a conforming C implementation without
> > these quotes applying.
> >
> > As an analogy, I could find screensful of quotes saying that
> > bytes have 8 bits. But as we all know, there are C implementations
> > in which a byte has 9, or 32, or some other amount of bits.
> >[color=darkred]
> >>>> Show us the Java bytecode that allows one to manipulate
> >>>> individual bits of a Java float datatype, as a C union allows.
> >>>
> >>> A C union does not allow that.
> >>> Any C program that relies on it is non-portable.
> >>
> >> Non sequitur. It is a question of syntactic correctness, not
> >> portability.[/color]
> >
> > In C it is possible to have a syntactically correct
> > program that is not portable (by which I mean, it may
> > work reliably on one platform, but give different results,
> > or crash entirely, on different platforms). For example:
> >
> > int i = 3;
> > i = i++;
> > printf("%d\n", i);[/color]
>
> How is non portable? This returns 4 on GCC 3.2.1 (Linux), VC6 & BCB5
> (Win32), and on GCC 2.95.3 (FreeBSD)[/color]

Here's a slightly different example:

[root@rh170 undef]# more undef.c
#include <stdio.h>

int main (void)
{
int i, j;

i = j = 0; j = i++; j = j + i++;
i = 0; i = i++ + i++;
printf ("j = %d, i = %d\n", j, i);

i = j = 0; j = i++; j = j + ++i;
i = 0; i = i++ + ++i;
printf ("j = %d, i = %d\n", j, i);

i = j = 0; j = ++i; j = j + ++i;
i = 0; i = ++i + ++i;
printf ("j = %d, i = %d\n", j, i);

i = j = 0; j = ++i; j = j + i++;
i = 0; i = ++i + i++;
printf ("j = %d, i = %d\n", j, i);

return 0;
}

[root@rh170 undef]# ./undef
j = 1, i = 2
j = 2, i = 3
j = 3, i = 4
j = 2, i = 3

Hmmmmm...

[Alfred Z. Newmane]

Re: C to Java Byte Code

Richard Tobin wrote:[color=blue]
> In article <2uas2oF27j6u9U 1@uni-berlin.de>,
> Alfred Z. Newmane <a.newmane.remo ve@eastcoastcz. com> wrote:[color=green]
>> Richard Tobin wrote:[/color]
>[color=green][color=darkred]
>>> No. It starts with the value 3, which is the value of the
>>> right-hand side. Then that value is assigned to i, and i is
>>> incremented, but the order of these two operations is not defined.[/color][/color]
>[color=green]
>> Good point, thanks for mentioning it :-) Still, either order will
>> still end up with 4. Either i ++'s to 4 and assigns that bakc to i,
>> or i gets 3, then ++'ed, giving 4 as well.[/color]
>
> No. The possibilities include
>
> - the rhs is evaluated as 3
> - the rhs (3) is assigned to i
> - i is incremented
>
> where the result is that i ends up as 4, and[/color]

Sounds good.
[color=blue]
> - the rhs is evaluated as 3
> - i is incremented
> - the rhs (3) is assigned to i
>
> where i ends up as 3.[/color]

If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
not give 4? THe key is in the incrementation; when ever I get
incremented, it becomes 4, does it not? If nto can you please better
explain your logic (in the second example)?

[Alfred Z. Newmane]

Re: C to Java Byte Code

Richard Tobin wrote:[color=blue]
> In article <4180922a.17112 8963@news.indiv idual.net>,
> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:
>[color=green]
>> Worse, in multi-processor or multi-pipeline systems, they could occur
>> simultaneously. It isn't inconceivable for this to crash the program
>> rather abruptly, or to write a completely unpredictable value to i.[/color]
>
> For example, a C implementation on a multi-processor native INTERCAL
> machine might do the assignment half-way through the evaluation of the
> addition using the MINGLE and SELECT operators.[/color]

Sound like that coudl get ugly /fast/. Though I haven't worked with such
setups, aren't there safe guards against such (resulting) data
corruption?

[Alex Fraser]

Re: C to Java Byte Code

"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote in message
news:2ucl32F29t 4ttU1@uni-berlin.de...[color=blue]
> Richard Tobin wrote:[/color]
[snip][color=blue][color=green]
> > No. The possibilities include
> >
> > - the rhs is evaluated as 3
> > - the rhs (3) is assigned to i
> > - i is incremented
> >
> > where the result is that i ends up as 4, and[/color]
>
> Sounds good.
>[color=green]
> > - the rhs is evaluated as 3
> > - i is incremented
> > - the rhs (3) is assigned to i
> >
> > where i ends up as 3.[/color]
>
> If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
> not give 4? THe key is in the incrementation; when ever I get
> incremented, it becomes 4, does it not? If nto can you please better
> explain your logic (in the second example)?[/color]

Given:
i = i++;

The compiler is free to generate code equivalent to:
temp = i; /* evaluate RHS */
i++; /* increment i */
i = temp; /* assign result of evaluation of RHS */

Alex

[Flash Gordon]

Re: C to Java Byte Code

On Thu, 28 Oct 2004 09:30:25 -0700
"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:
[color=blue]
> Richard Tobin wrote:[/color]

<snip i = i++>
[color=blue][color=green]
> > - the rhs is evaluated as 3
> > - i is incremented
> > - the rhs (3) is assigned to i
> >
> > where i ends up as 3.[/color]
>
> If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
> not give 4? THe key is in the incrementation; when ever I get
> incremented, it becomes 4, does it not? If nto can you please better
> explain your logic (in the second example)?[/color]

You are assuming that one operation is completed before the other, they
could be running in parallel or interleaved. So it could be implemented
as:
Read the value of i in to register a, so reg a=3
Increment value in variable i, so register a=3 and variable i=4
Store register a in i, so i=3

This is not actually a completely unreasonable implementation. It makes
sense because i++ is the post increment, so it's value is the value
before incrementing, so if a processor has an instruction for
incrementing data in RAM (I know some processors do) it is reasonable to
use the values in the expression, then do the in-place increment, then
save the result.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Old Wolf]

Re: C to Java Byte Code

"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:[color=blue]
> Old Wolf wrote:
>[color=green]
> > According to your logic above, this should do:
> > i--; // i is now 2
> > *p = i; // i is now 2
> > i++; // i is now 3
> >
> > and print 3. But if it does the optimisation I suggested
> > then it prints 2. This is indeed what my gcc 3.4.1 prints (2).[/color]
>
> Mine prints 3 :-)
> What options, if any, were you using?
>
> test.c
> ---------------------------------------------------
> #include <stdio.h>
>
> static int i;
>
> void foo(int *p) {
> i--;
> *p = i++;
> }
>
> int main(void) {
> i = 3;
> foo(&i);
> printf("%d\n", i);
>
> return 0;
> }[/color]

Same as yours (ie. gcc -o test test.c) . It didn't make a
difference whether I went -O0 or -O2 or -O3. FWIW I get
2 on gcc 3.4.1 but 3 on egcs 2.91.66 which I also have
installed.

[Flash Gordon]

Re: C to Java Byte Code

On Thu, 28 Oct 2004 09:33:30 -0700
"Alfred Z. Newmane" <a.newmane.remo ve@eastcoastcz. com> wrote:
[color=blue]
> Richard Tobin wrote:[color=green]
> > In article <4180922a.17112 8963@news.indiv idual.net>,
> > Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:
> >[color=darkred]
> >> Worse, in multi-processor or multi-pipeline systems, they could[/color]
> >occur> simultaneously. It isn't inconceivable for this to crash the
> >program> rather abruptly, or to write a completely unpredictable
> >value to i.
> >
> > For example, a C implementation on a multi-processor native INTERCAL
> > machine might do the assignment half-way through the evaluation of
> > the addition using the MINGLE and SELECT operators.[/color]
>
> Sound like that coudl get ugly /fast/. Though I haven't worked with
> such setups, aren't there safe guards against such (resulting) data
> corruption?[/color]

There is one very good safeguard. Don't do things the C standard leaves
undefined. The compiler might me making use of the leeway provided (such
as the time when the increment occurs) to do all sorts of strange and
wonderful optimisations. That is (presumably) why the C language defines
sequence points and that it is only once you reach a sequence point that
you can be certain that all the side effects have occurred.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Richard Tobin]

Re: C to Java Byte Code

In article <2ucl32F29t4ttU 1@uni-berlin.de>,
Alfred Z. Newmane <a.newmane.remo ve@eastcoastcz. com> wrote:
[color=blue][color=green]
>> - the rhs is evaluated as 3
>> - i is incremented
>> - the rhs (3) is assigned to i
>>
>> where i ends up as 3.[/color][/color]
[color=blue]
>If "rhs is evaluated as 3" and then "i is incremented", how wil lthat
>not give 4?[/color]

The variable i is incremented. The value of the right-hand-side has
already been evaluated, and is equal to three. So i is set to 4 when
it is incremented, and back to 3 when the rhs is assigned to it.

Imagine it with a temporary variable for the right-hand side. The two
possibilities I listed are:

rhs = i;
i = rhs;
i = i+1;

and

rhs = i;
i = i+1;
i = rhs;

-- Richard

[Willem]

Re: C to Java Byte Code

Paul wrote:
) The claim made by Mr. Abdullah is that unions are supported by his product.
) Since unions are already supported in C, this can only mean his claim
) refers to Java.

That's a very odd thing to say. His product is a C compiler.


Let me ask you a question:

Does GCC support unions ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Thomas G. Marshall]

Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Alan Morgan coughed up:

....[rip]...
[color=blue]
> The statement "i=i++;" invokes undefined behavior. Your compiler
> will very likely behave rationally and give you an answer that you
> might reasonably consider "correct". Don't be fooled. The technical
> definition of "undefined" is "Will give consistent and repeatable
> results until your boss asks for a demo, at which point it starts
> behaving randomly".[/color]


(For yucks, the term "undefined behavior" is actually defined in the C
specification, but that is neither here nor there.)

I don't see i=i++ as ever anything useful, but 45° tangental to this
original thread is something that bothers me. There is a *prevailing*
notion that:

If it ain't standard C, it ain't C

which I think is not quite true. This is related to something else I also
think is false:

If it ain't standard C, you should not write in it

I've been digging here and there about this for a while now and am not sure
that there is a /complete/ consensus on this notion, though the majority
seem to agree with the above statement. It's important because there are
many things that cannot be written in standard C that are nonetheless useful
to write in non-std C:

Device Drivers (usually)
malloc()
Anything embedded that needs to tweek memory
mapped registers

This issue was raised to my attention recently when I was educated by many
here on what the standard actually allows. But knowing the standard, IMHO,
isn't the bottom line. Knowing the "usual" rules of C, particularly the
/likely/ behavior of something undefined or platform dependent in the spec,
is, particularly if you're recruiting.



--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

[Programmer Dude]

Re: Not STD C is &quot;not C&quot; ? ----WAS: Re: C to Java Byte Code

Thomas G. Marshall writes:
[color=blue]
> There is a *prevailing* notion that:
>
> If it ain't standard C, it ain't C
>
> which I think is not quite true.[/color]

Of course not. The only place that "notion" really prevails is in the
comp.lang.c group. And as a number of regulars (or in my case, former
regulars) hang out here, too, we get it here, too.
[color=blue]
> This is related to something else I also think is false:
>
> If it ain't standard C, you should not write in it[/color]

Right (it's false).
[color=blue]
> But knowing the standard, IMHO, isn't the bottom line.[/color]

Right. It's the first line! It's somewhat like an artist needing
to know how to paint a face correctly before they start experimenting
with alternate forms and formats. *Knowledgeable* departure from
the standard is the key.
[color=blue]
> Knowing the "usual" rules of C, particularly the /likely/ behavior
> of something undefined or platform dependent in the spec, is,
> particularly if you're recruiting.[/color]

I don't agree it's the bottom line, but it's an important one, IMO.

[Alfred Z. Newmane]

Re: C to Java Byte Code

Willem wrote:[color=blue]
> Paul wrote:
> ) The claim made by Mr. Abdullah is that unions are supported by his
> product. ) Since unions are already supported in C, this can only
> mean his claim ) refers to Java.
>
> That's a very odd thing to say. His product is a C compiler.
>
>
> Let me ask you a question:
>
> Does GCC support unions ?[/color]

2.9.5 and 3.2 seem to.

[Willem]

Re: C to Java Byte Code

Alfred wrote:
) Willem wrote:
)> Paul wrote:
)> ) The claim made by Mr. Abdullah is that unions are supported by his
)> product. ) Since unions are already supported in C, this can only
)> mean his claim ) refers to Java.
)>
)> That's a very odd thing to say. His product is a C compiler.
)>
)>
)> Let me ask you a question:
)>
)> Does GCC support unions ?
)
) 2.9.5 and 3.2 seem to.

I specifically asked Paul, because he seems to have a strange notion of
what it means for a compiler to 'support unions'.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT