C to Java Byte Code

[Paul Lutus]

Re: C to Java Byte Code

Gerry Quinn wrote:
[color=blue]
> In article <10npbpmkjaqdqa 3@corp.supernew s.com>, nospam@nosite.z zz
> says...[color=green]
>> Mohd Hanafiah Abdullah wrote:[/color]
>[color=green][color=darkred]
>> >>> Also, old programs (with some tweaking) could be re-compiled and
>> >>> ported to the JVM.
>> >>
>> >>That's certainly an interesting idea.[/color]
>>
>> And it's false. If, as has been revealed, C programs that use byte
>> indexing and addressing have to be substantially rewritten to accommodate
>> this product, how does the above "tweaking" remark accurately describe
>> this requirement?[/color]
>
> As I understand it, this issue only affects incompetent programmers who
> write code that assumes that bytes have eight bits.[/color]

No, the original prohibition to which I refer was provided by Mr. Abdullah,
who said:

<cl7gbh$7th$1@h ood.uits.indian a.edu>

*************** *************** *************** ********

" ... programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC."

*************** *************** *************** ********

Care to retract your argument now, or later?
[color=blue]
> The sort of
> programmers in whose code unions are "ubiquitous ".[/color]

If you think unions are the work of the devil, why not argue for their
removal in some other thread? But *not* *here*, it is not the topic.

Since unions are not supported in the product being discussed, their
ubiquity is not the issue, and your argument is just that, nothing more.
Also, the only "union" supported in the product is to make two or more
references to the same integer-sized variable (language provided by Mr.
Abdullah). Therefore, in point of fact, the product cannot map two
distinct, same-size entities onto one another, which is what a "union"
should be capable of doing. This means that Mr. Abdullah's claims in this
specific regard are, like so many others, not correct.

In any case, your argument fails because, no matter what misconceptions a
prorgammer brings to the table, and according to Mr. Abdullah as quoted
above, none of them will work on this product unless "byte" is strictly
defined as having the same size as a Java native integer, which violates
the same rule you are trying to use as an argument -- bytes can have many
different sizes. In this product this requirement is not met.

If you intend to argue without thinking, don't bother to post.

--
Paul Lutus

http://www.arachnoid.com

[Dave Vandervies]

Re: C to Java Byte Code

In article <10nqamhfej8qqf 5@corp.supernew s.com>,
Paul Lutus <nospam@nosite. zzz> wrote:[color=blue]
>Gerry Quinn wrote:[/color]
[color=blue][color=green]
>> As I understand it, this issue only affects incompetent programmers who
>> write code that assumes that bytes have eight bits.[/color]
>
>No, the original prohibition to which I refer was provided by Mr. Abdullah,
>who said:
>
><cl7gbh$7th$1@ hood.uits.india na.edu>
>
>************** *************** *************** *********
>
>" ... programs that assume a byte-addressable architecture will need to be
>modified to suit the one used by MPC."
>
>************** *************** *************** *********
>
>Care to retract your argument now, or later?[/color]

....So it doesn't provide a byte-addressable memory model.

Care to provide a reference to support your claim that C requires a
byte-addressable memory model?

[color=blue]
>Since unions are not supported in the product being discussed, their
>ubiquity is not the issue, and your argument is just that, nothing more.
>Also, the only "union" supported in the product is to make two or more
>references to the same integer-sized variable (language provided by Mr.
>Abdullah). Therefore, in point of fact, the product cannot map two
>distinct, same-size entities onto one another, which is what a "union"
>should be capable of doing. This means that Mr. Abdullah's claims in this
>specific regard are, like so many others, not correct.[/color]

I haven't been following this thread too closely, but if I'm not mistaken,
union support was never claimed to be this limited (except by you).

What was claimed is that a float is the same size as an unsigned char;
the two distinct same-size entities that are mapped onto each other
by the union in your example are a single float and an array of one
unsigned char.

The fact that this implementation provides word-addressed memory and
every primitive type's size is a single word doesn't prevent anything
from aliasing any values with an array of unsigned char; it only means
that each primitive type can be aliased with a single unsigned char
(instead of an array of more than one unsigned char) that can be used
to determine the bit pattern.

[color=blue]
>In any case, your argument fails because, no matter what misconceptions a
>prorgammer brings to the table, and according to Mr. Abdullah as quoted
>above, none of them will work on this product unless "byte" is strictly
>defined as having the same size as a Java native integer, which violates
>the same rule you are trying to use as an argument -- bytes can have many
>different sizes. In this product this requirement is not met.[/color]

Does your favorite implementation allow bytes to have many different
sizes?

Bytes have a size that is fixed on a single implementation and can
vary between implementations . I don't think anybody is trying to claim
otherwise.

[color=blue]
>If you intend to argue without thinking, don't bother to post.[/color]



dave

--
Dave Vandervies dj3vande@csclub .uwaterloo.ca

Some of us even have a grip on reality. This is a university, remember?
--Giles Malet in uw.general

[Paul Lutus]

Re: C to Java Byte Code

Dave Vandervies wrote:
[color=blue]
> In article <10nqamhfej8qqf 5@corp.supernew s.com>,
> Paul Lutus <nospam@nosite. zzz> wrote:[color=green]
>>Gerry Quinn wrote:[/color]
>[color=green][color=darkred]
>>> As I understand it, this issue only affects incompetent programmers who
>>> write code that assumes that bytes have eight bits.[/color]
>>
>>No, the original prohibition to which I refer was provided by Mr.
>>Abdullah, who said:
>>
>><cl7gbh$7th$1 @hood.uits.indi ana.edu>
>>
>>************* *************** *************** **********
>>
>>" ... programs that assume a byte-addressable architecture will need to be
>>modified to suit the one used by MPC."
>>
>>************* *************** *************** **********
>>
>>Care to retract your argument now, or later?[/color]
>
> ...So it doesn't provide a byte-addressable memory model.
>
> Care to provide a reference to support your claim that C requires a
> byte-addressable memory model?[/color]

Before you try to shift the burden of evidence, care to find where I made
this claim? Please do not drift the tread -- this is the easiest imaginable
activity, but it sheds no light on anyting.
[color=blue][color=green]
>>Since unions are not supported in the product being discussed, their
>>ubiquity is not the issue, and your argument is just that, nothing more.
>>Also, the only "union" supported in the product is to make two or more
>>references to the same integer-sized variable (language provided by Mr.
>>Abdullah). Therefore, in point of fact, the product cannot map two
>>distinct, same-size entities onto one another, which is what a "union"
>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>specific regard are, like so many others, not correct.[/color]
>
> I haven't been following this thread too closely, but if I'm not mistaken,
> union support was never claimed to be this limited (except by you).[/color]

The OP eventually admitted that all variables are mapped to Java native
integers -- all of them. This means there is no support for the property of
unions that they can conjoin two unrelated data types so long as their size
is adjusted to be the same.

If you think about Java's design, you will quickly realize there is no
support for directly conjoining any two variable types, because of strict
data typing, therefore the claim made by Mr. Abdullah:

<cl7gbh$7th$1@h ood.uits.indian a.edu>

*************** *************** *************** *************** *******

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.  Using a large array of int to mimic addressable memory is
the cause for this.  The indexes to this large array are treated as
addresses.  This memory is word-addressable and not byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.  Unions are supported."

*************** *************** *************** *************** *******

.... is false, because if everything is mapped to a native Java integer, the
property and primary value of unions is not provided.
[color=blue]
>
> What was claimed is that a float is the same size as an unsigned char;
> the two distinct same-size entities that are mapped onto each other
> by the union in your example are a single float and an array of one
> unsigned char.[/color]

But if they are both Java native integers, no mapping is taking place. If
there are two accesses to a simple integer value, the term "mapping" is not
appropriate, but if a C union is provided and two different data types are
mapped/conjoined, the term in appropriate.
[color=blue][color=green]
>>In any case, your argument fails because, no matter what misconceptions a
>>prorgammer brings to the table, and according to Mr. Abdullah as quoted
>>above, none of them will work on this product unless "byte" is strictly
>>defined as having the same size as a Java native integer, which violates
>>the same rule you are trying to use as an argument -- bytes can have many
>>different sizes. In this product this requirement is not met.[/color]
>
> Does your favorite implementation allow bytes to have many different
> sizes?[/color]

Now we have had the argument from both sides. Mr. Quinn thinks it silly that
someone would make any assumptions about the size of a byte, your position
is that it is silly to assume there is any signifgicant flexibility about
this. Maybe you should address Mr. Quinn's argument directly, as I was
doing.
[color=blue]
> Bytes have a size that is fixed on a single implementation and can
> vary between implementations . I don't think anybody is trying to claim
> otherwise.[/color]

True, and see above.

--
Paul Lutus

http://www.arachnoid.com

[Willem]

Re: C to Java Byte Code

Paul wrote:
)> I haven't been following this thread too closely, but if I'm not mistaken,
)> union support was never claimed to be this limited (except by you).
)
) The OP eventually admitted that all variables are mapped to Java native
) integers -- all of them. This means there is no support for the property of
) unions that they can conjoin two unrelated data types so long as their size
) is adjusted to be the same.

That's an odd thing to say. Maybe I'm not reading you correctly, but you
seem to be saying that a union between a float and a long is not this
"conjoin two unrelated data types ..." business you speak of, and that
unions are primarily designed for you to split a float into chunks ?

) If you think about Java's design, you will quickly realize there is no
) support for directly conjoining any two variable types, because of strict
) data typing, therefore the claim made by Mr. Abdullah:
)
) <snip>
)
) ... is false, because if everything is mapped to a native Java integer, the
) property and primary value of unions is not provided.

On every single computer, everything is eventually mapped to a single data
type, namely the bit.

) But if they are both Java native integers, no mapping is taking place. If
) there are two accesses to a simple integer value, the term "mapping" is not
) appropriate, but if a C union is provided and two different data types are
) mapped/conjoined, the term in appropriate.

Again not making sense here. A float is mapped to a java integer by the
product, probably by some glue code. You seem to be claiming that a float
*is* an int in this case. Which is silly, because then you couldn't do
floating point math on it, could you ?

) Now we have had the argument from both sides. Mr. Quinn thinks it silly that
) someone would make any assumptions about the size of a byte, your position
) is that it is silly to assume there is any signifgicant flexibility about
) this. Maybe you should address Mr. Quinn's argument directly, as I was
) doing.

You're not having the argument from both sides, you're just not making
sense. Again. It's actually quite simple: The *platform* _dictates_ the
size of the byte, and the *programmer* has to be _flexible_ about the size
of the byte. Unless you're on a weird machine like a PDP-10 or something.

)> Bytes have a size that is fixed on a single implementation and can
)> vary between implementations . I don't think anybody is trying to claim
)> otherwise.
)
) True, and see above.

So if you admit this is true, then why did you make that silly argument
about how the product fixed the byte size ?


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

[Paul Lutus]

Re: C to Java Byte Code

Willem wrote:
[color=blue]
> Paul wrote:
> )> I haven't been following this thread too closely, but if I'm not
> mistaken, )> union support was never claimed to be this limited (except by
> you). )
> ) The OP eventually admitted that all variables are mapped to Java native
> ) integers -- all of them. This means there is no support for the property
> of ) unions that they can conjoin two unrelated data types so long as
> their size ) is adjusted to be the same.
>
> That's an odd thing to say. Maybe I'm not reading you correctly, but you
> seem to be saying that a union between a float and a long is not this
> "conjoin two unrelated data types ..." business you speak of, and that
> unions are primarily designed for you to split a float into chunks ?[/color]

1. In C, unions can be used to do what you suggest, this is not their only
purpose. My original example program did just that, but the result using
this product didn't.

2. The product being discussed doesn't map different data types together. It
reads the original C program and (according to the OP) creates everything
using native Java integer data types. What this means in practice is that,
on the Java side, it does not map a float and a long together, for a number
of reasons, not least of which is that Java will not allow this.

So the OP's claim the "unions are spported" is false. One cannot map, as in
the original example, a float and a byte array, as one can do in C. In this
scheme both are turned into Java native integers, so any references to one
or the other read from a single instance of a Java native integer. IOW the
same entity is being accessed in the same way.
[color=blue]
>
> ) If you think about Java's design, you will quickly realize there is no
> ) support for directly conjoining any two variable types, because of
> strict ) data typing, therefore the claim made by Mr. Abdullah:
> )
> ) <snip>
> )
> ) ... is false, because if everything is mapped to a native Java integer,
> the ) property and primary value of unions is not provided.
>
> On every single computer, everything is eventually mapped to a single data
> type, namely the bit.[/color]

Could you please stop posting these wonderful, albeit tautological,
arguments? Or, alternative, ask yourself how much light is shed on this or
any topic through such arguments?
[color=blue]
> ) But if they are both Java native integers, no mapping is taking place.
> If ) there are two accesses to a simple integer value, the term "mapping"
> is not ) appropriate, but if a C union is provided and two different data
> types are ) mapped/conjoined, the term in appropriate.[/color]

You really need to set up your newsreader properly. Use this post as an
example of standard quoting style.
[color=blue]
>
> Again not making sense here. A float is mapped to a java integer by the
> product, probably by some glue code.[/color]

This is false. A float is not mapped to an integer. According to the OP, an
integer is "mapped" to an integer, in fact, it is the same integer. In any
case, Java is strongly typed and will not allow what you suggest.
[color=blue]
> You seem to be claiming that a float
> *is* an int in this case.[/color]

No, the OP claimed this. Perhaps you could read the posted data before
posting.
[color=blue]
> Which is silly, because then you couldn't do
> floating point math on it, could you ?[/color]

False again. Programmers can do this, and in this case will be required to
do it, because Java will not accommodate a revolving door between integers
and floats.
[color=blue]
>
> ) Now we have had the argument from both sides. Mr. Quinn thinks it silly
> that ) someone would make any assumptions about the size of a byte, your
> position ) is that it is silly to assume there is any signifgicant
> flexibility about ) this. Maybe you should address Mr. Quinn's argument
> directly, as I was ) doing.
>
> You're not having the argument from both sides, you're just not making
> sense. Again. It's actually quite simple: The *platform* _dictates_ the
> size of the byte, and the *programmer* has to be _flexible_ about the size
> of the byte. Unless you're on a weird machine like a PDP-10 or something.[/color]

Try reading your own sentences before posting, theh delete the ones that
don't make any sense. This will have a salutary effect on the length of
your posts. When I said earlier that there was little flexibility about the
size of bytes, you argued the opposite position -- that bytes could have
any size. Now you argue that there is little flexibility about the size of
bytes, for which I can only add, read the thread more carefully and try to
avoid revesing your position so readily.
[color=blue]
> )> Bytes have a size that is fixed on a single implementation and can
> )> vary between implementations . I don't think anybody is trying to claim
> )> otherwise.
> )
> ) True, and see above.
>
> So if you admit this is true, then why did you make that silly argument
> about how the product fixed the byte size ?[/color]

That argument was made by Mr. Abdullah, not my me, and it is time for you to
do you own reading:

<cl7gbh$7th$1@h ood.uits.indian a.edu>

*************** *************** *************** *************** *******

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.  Using a large array of int to mimic addressable memory is
the cause for this.  The indexes to this large array are treated as
addresses.  This memory is word-addressable and not byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.  Unions are supported."

*************** *************** *************** *************** *******

Translation: "Unions are not supported, instead everything is translated
into an integer".

--
Paul Lutus

http://www.arachnoid.com

[Paul Lutus]

Re: C to Java Byte Code

Willem wrote:
[color=blue]
> Paul wrote:
> )> I haven't been following this thread too closely, but if I'm not
> mistaken, )> union support was never claimed to be this limited (except by
> you). )
> ) The OP eventually admitted that all variables are mapped to Java native
> ) integers -- all of them. This means there is no support for the property
> of ) unions that they can conjoin two unrelated data types so long as
> their size ) is adjusted to be the same.
>
> That's an odd thing to say.  Maybe I'm not reading you correctly, but you
> seem to be saying that a union between a float and a long is not this
> "conjoin two unrelated data types ..." business you speak of, and that
> unions are primarily designed for you to split a float into chunks ?[/color]

1. In C, unions can be used to do what you suggest, this is not their only
purpose. My original example program did just that, but the result using
this product didn't.

2. The product being discussed doesn't map different data types together. It
reads the original C program and (according to the OP) creates everything
using native Java integer data types. What this means in practice is that,
on the Java side, it does not map a float and a long together, for a number
of reasons, not least of which is that Java will not allow this.

So the OP's claim the "unions are spported" is false. One cannot map, as in
the original example, a float and a byte array, as one can do in C. In this
scheme both are turned into Java native integers, so any references to one
or the other read from a single instance of a Java native integer. IOW the
same entity is being accessed in the same way.
[color=blue]
>
> ) If you think about Java's design, you will quickly realize there is no
> ) support for directly conjoining any two variable types, because of
> strict ) data typing, therefore the claim made by Mr. Abdullah:
> )
> )  <snip>
> )
> ) ... is false, because if everything is mapped to a native Java integer,
> the ) property and primary value of unions is not provided.
>
> On every single computer, everything is eventually mapped to a single data
> type, namely the bit.[/color]

Could you please stop posting these wonderful, albeit tautological,
arguments? Or, alternative, ask yourself how much light is shed on this or
any topic through such arguments?
[color=blue]
> ) But if they are both Java native integers, no mapping is taking place.
> If ) there are two accesses to a simple integer value, the term "mapping"
> is not ) appropriate, but if a C union is provided and two different data
> types are ) mapped/conjoined, the term in appropriate.[/color]

You really need to set up your newsreader properly. Use this post as an
example of standard quoting style.
[color=blue]
>
> Again not making sense here.  A float is mapped to a java integer by the
> product, probably by some glue code.[/color]

This is false. A float is not mapped to an integer. According to the OP, an
integer is "mapped" to an integer, in fact, it is the same integer. In any
case, Java is strongly typed and will not allow what you suggest.
[color=blue]
> You seem to be claiming that a float
> is an int in this case.[/color]

No, the OP claimed this. Perhaps you could read the posted data before
posting.
[color=blue]
> Which is silly, because then you couldn't do
> floating point math on it, could you ?[/color]

False again. Programmers can do this, and in this case will be required to
do it, because Java will not accommodate a revolving door between integers
and floats.
[color=blue]
>
> ) Now we have had the argument from both sides. Mr. Quinn thinks it silly
> that ) someone would make any assumptions about the size of a byte, your
> position ) is that it is silly to assume there is any signifgicant
> flexibility about ) this. Maybe you should address Mr. Quinn's argument
> directly, as I was ) doing.
>
> You're not having the argument from both sides, you're just not making
> sense.  Again.  It's actually quite simple:  The platform dictates the
> size of the byte, and the programmer has to be flexible about the size
> of the byte.  Unless you're on a weird machine like a PDP-10 or something.[/color]

Try reading your own sentences before posting, theh delete the ones that
don't make any sense. This will have a salutary effect on the length of
your posts. When I said earlier that there was little flexibility about the
size of bytes, you argued the opposite position -- that bytes could have
any size. Now you argue that there is little flexibility about the size of
bytes, for which I can only add, read the thread more carefully and try to
avoid revesing your position so readily.
[color=blue]
> )> Bytes have a size that is fixed on a single implementation and can
> )> vary between implementations .  I don't think anybody is trying to claim
> )> otherwise.
> )
> ) True, and see above.
>
> So if you admit this is true, then why did you make that silly argument
> about how the product fixed the byte size ?[/color]

That argument was made by Mr. Abdullah, not my me, and it is time for you to
do you own reading:

<cl7gbh$7th$1@h ood.uits.indian a.edu>

*************** *************** *************** *************** *******

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.  Using a large array of int to mimic addressable memory is
the cause for this.  The indexes to this large array are treated as
addresses.  This memory is word-addressable and not byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.  Unions are supported."

*************** *************** *************** *************** *******

Translation: "Unions are not supported, instead everything is translated
into an integer".

--
Paul Lutus

http://www.arachnoid.com

[Dave Vandervies]

Re: C to Java Byte Code

In article <10nqj6r9cavr84 2@corp.supernew s.com>,
Paul Lutus <nospam@nosite. zzz> wrote:
[color=blue]
>So the OP's claim the "unions are spported" is false. One cannot map, as in
>the original example, a float and a byte array, as one can do in C. In this
>scheme both are turned into Java native integers, so any references to one
>or the other read from a single instance of a Java native integer. IOW the
>same entity is being accessed in the same way.[/color]

And on the 386 running the web server in my closet, the C implementation
doesn't support unions; one cannot map a float and a byte array, because
both are turned into the processor's native bytes, so any references to
one or the other read from a single set of the processor's native bytes;
IOW the same entity is being accessed in the same way.

[I don't actually have a 386 running a web server in my closet, but
it's not at all an unreasonable thing to expect, and it's really no
different from a JVM; any floating-point operations are done by the
runtime environment and not the underlying hardware, just as the C-on-JVM
implementation under discussion appears to do.]

Where the data is stored doesn't make it a float; how it's treated does.
If you can stuff the value 42 in and look at the bit pattern and see `00
00 28 42', you have something that (for this value at least) acts like
a 32-bit IEEE floating point number, and you DO NOT have a Java integer.

There's nothing stopping a C implementation from storing its floating
point values in a processor's native bytes, or in Java integers, or in
a cave somewhere in Antarctica (well, perhaps common sense and physical
laws, but nothing in the definition of the language), as long as an
attempt to look at the bytes AS DEFINED IN THE DEFINITION OF THE LANGUAGE
(which allows them to be 32 bits long, f'rexample for a word-addressed
platform) that make up that float succeeds and gives reasonable values.


[color=blue][color=green]
>> Again not making sense here.  A float is mapped to a java integer by the
>> product, probably by some glue code.[/color]
>
>This is false. A float is not mapped to an integer. According to the OP, an
>integer is "mapped" to an integer, in fact, it is the same integer. In any
>case, Java is strongly typed and will not allow what you suggest.[/color]

A float is represented by a bit pattern that happens to be stored in a
Java integer.
An int is represented by a bit pattern that happens to be stored in a
Java integer.

Is this really that difficult to understand?

[color=blue][color=green]
>> Which is silly, because then you couldn't do
>> floating point math on it, could you ?[/color]
>
>False again. Programmers can do this, and in this case will be required to
>do it, because Java will not accommodate a revolving door between integers
>and floats.[/color]

I see no revolving door here; I see a particular method of storing
bits being used to store bits that happen to be the representation of
a floating point value.


[color=blue][color=green]
>> )> Bytes have a size that is fixed on a single implementation and can
>> )> vary between implementations .  I don't think anybody is trying to claim
>> )> otherwise.
>> )
>> ) True, and see above.
>>
>> So if you admit this is true, then why did you make that silly argument
>> about how the product fixed the byte size ?[/color]
>
>That argument was made by Mr. Abdullah, not my me, and it is time for you to
>do you own reading:
>
><cl7gbh$7th$1@ hood.uits.india na.edu>
>
>************** *************** *************** *************** ********
>
>"The size of each char, int, long, or float is 1 word (32 bits long).
>So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
>you got the idea.  Using a large array of int to mimic addressable memory is
>the cause for this.  The indexes to this large array are treated as
>addresses.  This memory is word-addressable and not byte-addressable.
>And programs that assume a byte-addressable architecture will need to be
>modified to suit the one used by MPC.  Unions are supported."
>
>************** *************** *************** *************** ********
>
>Translation: "Unions are not supported, instead everything is translated
>into an integer".[/color]

Everything is translated into bit patterns that can be stored in an
integer. (Call it a "virtual machine word" if calling it an integer
bothers you.)

Just like on an implementation for a general-purpose hardware processor,
everything is translated into bit patterns that can be stored in a set
of memory bytes.

By your logic, the compiler I use on the workstation in front of
me doesn't support unions; instead, everything is translated into a
string of bytes, and if I try to look at something with a union it's
just reading from a single instance of that string of bytes.


Are you really so thick you're still not getting this, or are you just
pathologically unable to admit that you might be wrong about something?


dave

--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

[Dave Vandervies]

Re: C to Java Byte Code

In article <10nqefd36j5pod 2@corp.supernew s.com>,
Paul Lutus <nospam@nosite. zzz> wrote:[color=blue]
>Dave Vandervies wrote:
>[color=green]
>> In article <10nqamhfej8qqf 5@corp.supernew s.com>,
>> Paul Lutus <nospam@nosite. zzz> wrote:[color=darkred]
>>>Gerry Quinn wrote:[/color]
>>[color=darkred]
>>>> As I understand it, this issue only affects incompetent programmers who
>>>> write code that assumes that bytes have eight bits.
>>>
>>>No, the original prohibition to which I refer was provided by Mr.
>>>Abdullah, who said:
>>>
>>><cl7gbh$7th$ 1@hood.uits.ind iana.edu>
>>>
>>>************ *************** *************** ***********
>>>
>>>" ... programs that assume a byte-addressable architecture will need to be
>>>modified to suit the one used by MPC."
>>>
>>>************ *************** *************** ***********
>>>
>>>Care to retract your argument now, or later?[/color]
>>
>> ...So it doesn't provide a byte-addressable memory model.
>>
>> Care to provide a reference to support your claim that C requires a
>> byte-addressable memory model?[/color]
>
>Before you try to shift the burden of evidence, care to find where I made
>this claim? Please do not drift the tread -- this is the easiest imaginable
>activity, but it sheds no light on anyting.[/color]

A few lines above in the quoted material, you present the fact that
code requiring a byte-addressable memory model will not work with this
implementation as support for your claim that this implementation imposes
unreasonable constraints on the programmer.

Unless you can demonstrate that C requires a byte-addressable memory
model, your complaint is with the language, not with the implementation.

[color=blue][color=green][color=darkred]
>>>Since unions are not supported in the product being discussed, their
>>>ubiquity is not the issue, and your argument is just that, nothing more.
>>>Also, the only "union" supported in the product is to make two or more
>>>references to the same integer-sized variable (language provided by Mr.
>>>Abdullah). Therefore, in point of fact, the product cannot map two
>>>distinct, same-size entities onto one another, which is what a "union"
>>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>>specific regard are, like so many others, not correct.[/color]
>>
>> I haven't been following this thread too closely, but if I'm not mistaken,
>> union support was never claimed to be this limited (except by you).[/color]
>
>The OP eventually admitted that all variables are mapped to Java native
>integers -- all of them. This means there is no support for the property of
>unions that they can conjoin two unrelated data types so long as their size
>is adjusted to be the same.[/color]

Really? What's stopping it? Is it really that difficult to treat a bit
pattern as a float when you store it and then treat it as an unsigned
char when you retreive it?
They're not stored "as integers"; they're stored in an array of integers
that gets treated as a word-addressed memory space. The same way an
implementation producing code for an Intel processor stores its variables
in an array of bytes that gets treated as a byte-addressed memory space.

[color=blue]
>If you think about Java's design, you will quickly realize there is no
>support for directly conjoining any two variable types, because of strict
>data typing,[/color]

....which invalidates the claim that this is a C-to-Java translator in
the sense that it outputs Java code that runs directly on the JVM.

It does NOT invalidate the claim that this is a C implementation targeting
the JVM, with runtime code that treats a large array of Java integers
as a word-addressable memory space.

[color=blue][color=green]
>> What was claimed is that a float is the same size as an unsigned char;
>> the two distinct same-size entities that are mapped onto each other
>> by the union in your example are a single float and an array of one
>> unsigned char.[/color]
>
>But if they are both Java native integers, no mapping is taking place. If
>there are two accesses to a simple integer value, the term "mapping" is not
>appropriate, but if a C union is provided and two different data types are
>mapped/conjoined, the term in appropriate.[/color]

They're not Java native integers. They're values that happen to be
represented by a 32-bit word, that happens to fit nicely in a Java
integer.

[color=blue][color=green][color=darkred]
>>>In any case, your argument fails because, no matter what misconceptions a
>>>prorgammer brings to the table, and according to Mr. Abdullah as quoted
>>>above, none of them will work on this product unless "byte" is strictly
>>>defined as having the same size as a Java native integer, which violates
>>>the same rule you are trying to use as an argument -- bytes can have many
>>>different sizes. In this product this requirement is not met.[/color]
>>
>> Does your favorite implementation allow bytes to have many different
>> sizes?[/color]
>
>Now we have had the argument from both sides. Mr. Quinn thinks it silly that
>someone would make any assumptions about the size of a byte, your position
>is that it is silly to assume there is any signifgicant flexibility about
>this. Maybe you should address Mr. Quinn's argument directly, as I was
>doing.[/color]

Implementations need not be flexible; a C implementation is constrained
only by the requirement that CHAR_BIT be not less than 8.

This means that, by assuming a byte-addressed memory model with 8-bit
bytes, a programmer is restricting the set of implementations their code
works on to those that match that assumption, which is a proper subset
of "all C implementations ". If not being able to read word-addressed
memory a byte at a time bothers you, your choices are to restrict your
selection of implementations to those that match your assumptions or
to remove byte-addressibility from the list of things you expect from
word-addressed implementations .


dave

--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

[Paul Lutus]

Re: C to Java Byte Code

Dave Vandervies wrote:
[color=blue]
> In article <10nqj6r9cavr84 2@corp.supernew s.com>,
> Paul Lutus <nospam@nosite. zzz> wrote:
>[color=green]
>>So the OP's claim the "unions are spported" is false. One cannot map, as
>>in the original example, a float and a byte array, as one can do in C. In
>>this scheme both are turned into Java native integers, so any references
>>to one or the other read from a single instance of a Java native integer.
>>IOW the same entity is being accessed in the same way.[/color]
>
> And on the 386 running the web server in my closet, the C implementation
> doesn't support unions;[/color]

Please do not leave the topic, and try to avoid invention to support your
argument. Unions are part of ANSI C.
[color=blue]
> one cannot map a float and a byte array, because
> both are turned into the processor's native bytes,[/color]

If the compiler is ANSI C compliant, my example program will compile on that
compiler and run on that plartform. Unions are supported by C, they are not
supported by Java, and they are not supported by the program under
discussion.
[color=blue]
> so any references to
> one or the other read from a single set of the processor's native bytes;
> IOW the same entity is being accessed in the same way.[/color]

Just stop posting. You want to argue, not think, fortunately for you there
are plenty of suitable newsgroups for this onanistic activity.
[color=blue]
>
> [I don't actually have a 386 running a web server in my closet, but
> it's not at all an unreasonable thing to expect, and it's really no
> different from a JVM; any floating-point operations are done by the
> runtime environment and not the underlying hardware, just as the C-on-JVM
> implementation under discussion appears to do.]
>
> Where the data is stored doesn't make it a float; how it's treated does.[/color]

This discussion unfortunately is not just about C, it is about C and Java.
Java does not agree wth you. Floats are treated as a unique data type, and
mixing of data types, as for example in a union, is not allowed in Java.
[color=blue]
> If you can stuff the value 42 in and look at the bit pattern and see `00
> 00 28 42', you have something that (for this value at least) acts like
> a 32-bit IEEE floating point number, and you DO NOT have a Java integer.[/color]

At which word did your brain go offline? Post the stack dump.

If you read a thread like this, and you have nothing to contribute, do not
reply. It is a simple rule.

/ ...
[color=blue]
> A float is represented by a bit pattern that happens to be stored in a
> Java integer.
> An int is represented by a bit pattern that happens to be stored in a
> Java integer.[/color]

Java recognizes that a float and an integer are different data types, and
refuses them to be freely mixed, as C allows in a union. This is wy the OP
chose to make all the data types the same. This is why his product does not
suppoert doubles at all -- he had some hard choices to make.

On the topic of hard choices, is there a timetable for you to bring your
brain back on line?

--
Paul Lutus

http://www.arachnoid.com

[Willem]

Re: C to Java Byte Code

Paul wrote:
) Willem wrote:
)> That's an odd thing to say.  Maybe I'm not reading you correctly, but you
)> seem to be saying that a union between a float and a long is not this
)> "conjoin two unrelated data types ..." business you speak of, and that
)> unions are primarily designed for you to split a float into chunks ?
)
) 1. In C, unions can be used to do what you suggest, this is not their only
) purpose. My original example program did just that, but the result using
) this product didn't.

I would say that chopping op a float into chunks is usually only used in
'hackish' code, and probably falls under the 'undefined behaviour' clause.

) So the OP's claim the "unions are spported" is false. One cannot map, as in
) the original example, a float and a byte array, as one can do in C. In this
) scheme both are turned into Java native integers, so any references to one
) or the other read from a single instance of a Java native integer. IOW the
) same entity is being accessed in the same way.

I really don't understand what you're saying here. Firstly, one can most
certainly map a float and a byte array. That the array has a different
size is not relevant to that.

)> On every single computer, everything is eventually mapped to a single data
)> type, namely the bit.
)
) Could you please stop posting these wonderful, albeit tautological,
) arguments? Or, alternative, ask yourself how much light is shed on this or
) any topic through such arguments?

I just wanted to point out that your argument about floats and bytes being
mapped to integers is stupid, because on most computers, as I just wrote,
they are also being mapped to a single something.
I assume you understood that perfectly and, unable to respond to the actual
argument, chose this ad hominem approach instead.

)> ) But if they are both Java native integers, no mapping is taking place.
)> If ) there are two accesses to a simple integer value, the term "mapping"
)> is not ) appropriate, but if a C union is provided and two different data
)> types are ) mapped/conjoined, the term in appropriate.
)
) You really need to set up your newsreader properly. Use this post as an
) example of standard quoting style.

Your newsreader and/or editor is the one that rewraps the lines, not mine.
If you're complaining about my use of a closing paren instead of a
greater-than, then your complaint is noted and ignored.

)> Again not making sense here. A float is mapped to a java integer by
)> the product, probably by some glue code.
)
) This is false. A float is not mapped to an integer. According to the OP, an
) integer is "mapped" to an integer, in fact, it is the same integer. In any
) case, Java is strongly typed and will not allow what you suggest.

Your claim about what else is mapped to an integer is meaningless.
The actual question is what do you claim happens with the float ?

)> You seem to be claiming that a float
)> is an int in this case.
)
) No, the OP claimed this. Perhaps you could read the posted data before
) posting.

The OP claimed that all data types are represented as integers, not that
they are treated the same. Heed your own words.

)> Which is silly, because then you couldn't do
)> floating point math on it, could you ?
)
) False again. Programmers can do this, and in this case will be required to
) do it, because Java will not accommodate a revolving door between integers
) and floats.

According to the OP, his product does do floating point math on the
floating point numbers even though they are represented as integers.

)> You're not having the argument from both sides, you're just not making
)> sense. Again. It's actually quite simple: The platform dictates the
)> size of the byte, and the programmer has to be flexible about the size
)> of the byte. Unless you're on a weird machine like a PDP-10 or something.
)
) Try reading your own sentences before posting, theh delete the ones that
) don't make any sense. This will have a salutary effect on the length of
) your posts. When I said earlier that there was little flexibility about the
) size of bytes, you argued the opposite position -- that bytes could have
) any size. Now you argue that there is little flexibility about the size of
) bytes, for which I can only add, read the thread more carefully and try to
) avoid revesing your position so readily.

You must be trolling, because in the very sentence above this, I said quite
clearly what my position is, which involves both flexibility in byte sizes
(on the part of the programmer) and inflexibility in byte sizes (on the
part of the platform).

If you fail to apply context to arguments, then obviously they will make
little sense. This only shows that you're either too stupid to read the
context in which arguments are made, or that you're deliberately
misinterpreting me. Which, IMO, is also stupid.

)> So if you admit this is true, then why did you make that silly argument
)> about how the product fixed the byte size ?
)
) That argument was made by Mr. Abdullah, not my me, and it is time for you to
) do you own reading:

You may want to reread what I wrote.
I did not say 'argument that the product',
I said 'argument about how the product'.
That means that I was talking about your response to the
argument you quoted below.

)<cl7gbh$7th$1@ hood.uits.india na.edu>
)
) *************** *************** *************** *************** *******
)
) "The size of each char, int, long, or float is 1 word (32 bits long).
) So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
) you got the idea.  Using a large array of int to mimic addressable memory is
) the cause for this.  The indexes to this large array are treated as
) addresses.  This memory is word-addressable and not byte-addressable.
) And programs that assume a byte-addressable architecture will need to be
) modified to suit the one used by MPC.  Unions are supported."
)
) *************** *************** *************** *************** *******
)
) Translation: "Unions are not supported, instead everything is translated
) into an integer".

I fail to see where you get this weird translation from.
You must think that the sole purpose of a union is to be able to chop up
certain data types into chunks.
This must also mean that you think a union between a float and an int is
completely useless, and actually not even a union.


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

[Paul Lutus]

Re: C to Java Byte Code

Dave Vandervies wrote:
[color=blue]
> In article <10nqefd36j5pod 2@corp.supernew s.com>,
> Paul Lutus <nospam@nosite. zzz> wrote:[color=green]
>>Dave Vandervies wrote:[/color][/color]

/ ...
[color=blue][color=green][color=darkred]
>>> Care to provide a reference to support your claim that C requires a
>>> byte-addressable memory model?[/color]
>>
>>Before you try to shift the burden of evidence, care to find where I made
>>this claim? Please do not drift the tread -- this is the easiest
>>imaginable activity, but it sheds no light on anyting.[/color]
>
> A few lines above in the quoted material, you present the fact that
> code requiring a byte-addressable memory model will not work with this
> implementation as support for your claim that this implementation imposes
> unreasonable constraints on the programmer.[/color]

Post the quote in which I used these words, or retract the claim. I never
said what you claim I said.
[color=blue]
> Unless you can demonstrate that C requires a byte-addressable memory
> model, your complaint[/color]

The quote on wuich you are relying is an invention of yours. I never used
the words you posted. Start retracting and apologizing for misquoting now.

Mr. Abdullah made this statement, I did not. He said:

<cl7gbh$7th$1@h ood.uits.indian a.edu>

*************** *************** *************** *************** *******

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.  Using a large array of int to mimic addressable memory is
the cause for this.  The indexes to this large array are treated as
addresses.  This memory is word-addressable and not byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.  Unions are supported."

*************** *************** *************** *************** *******

/ ...
[color=blue][color=green]
>>The OP eventually admitted that all variables are mapped to Java native
>>integers -- all of them. This means there is no support for the property
>>of unions that they can conjoin two unrelated data types so long as their
>>size is adjusted to be the same.[/color]
>
> Really? What's stopping it? Is it really that difficult to treat a bit
> pattern as a float when you store it and then treat it as an unsigned
> char when you retreive it?[/color]

This is not a tutorial about Java, and you can do your own reading. In any
case, I never made the claim, the OP did.
[color=blue]
> They're not stored "as integers";[/color]

They are stored as Java native integers.
[color=blue]
> they're stored in an array of integers
> that gets treated as a word-addressed memory space.[/color]

Onanism.

/ ...
[color=blue][color=green]
>>If you think about Java's design, you will quickly realize there is no
>>support for directly conjoining any two variable types, because of strict
>>data typing,[/color]
>
> ...which invalidates the claim that this is a C-to-Java translator in
> the sense that it outputs Java code that runs directly on the JVM.[/color]

Yes, correct, therefore the OP's claims are false.
[color=blue]
> It does NOT invalidate the claim that this is a C implementation targeting
> the JVM, with runtime code that treats a large array of Java integers
> as a word-addressable memory space.[/color]

Ther OP made false claims both here and on his Web site. I said the claims
were false. At which point did you lose track of the topic?
[color=blue][color=green][color=darkred]
>>> What was claimed is that a float is the same size as an unsigned char;
>>> the two distinct same-size entities that are mapped onto each other
>>> by the union in your example are a single float and an array of one
>>> unsigned char.[/color]
>>
>>But if they are both Java native integers, no mapping is taking place. If
>>there are two accesses to a simple integer value, the term "mapping" is
>>not appropriate, but if a C union is provided and two different data types
>>are mapped/conjoined, the term in appropriate.[/color]
>
> They're not Java native integers.[/color]

In fact, that is exactly what they are. The term "native" in Java has a
different meaning than you may be familiar with.
[color=blue]
> They're values that happen to be
> represented by a 32-bit word, that happens to fit nicely in a Java
> integer.[/color]

They are Java native integers, as distinct from java Integer class
instances.

/ ...
[color=blue]
> This means that, by assuming a byte-addressed memory model with 8-bit
> bytes, a programmer is restricting the set of implementations their code
> works on to those that match that assumption, which is a proper subset
> of "all C implementations ". If not being able to read word-addressed
> memory a byte at a time bothers you,[/color]

It doesn't bother me, it bothers the OP. His program cannot do it. He
requires programmers to rewrite their C programs to accommmodate his
program.

At which word, in which post, did you lose track of the topic?

--
Paul Lutus

http://www.arachnoid.com

[Dave Vandervies]

Re: C to Java Byte Code

In article <cljnfj$htm$1@r umours.uwaterlo o.ca>,
Dave Vandervies <dj3vande@csclu b.uwaterloo.ca> wrote:
[color=blue]
>Find a word-addressed processor that does 32-bit chars and 32-bit floats
>in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
>a Cray-1 or a DSP.)[/color]

Note that 64-bit words and CHAR_BIT==64 is also acceptable. (Requiring 32
would invalidate the use of a Cray-1 as an example.)


dave

--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

[Dave Vandervies]

Re: C to Java Byte Code

In article <10nqmt2okb8hne c@corp.supernew s.com>,
Paul Lutus <nospam@nosite. zzz> wrote:
[color=blue]
>If the compiler is ANSI C compliant, my example program will compile on that
>compiler and run on that plartform. Unions are supported by C, they are not
>supported by Java, and they are not supported by the program under
>discussion.[/color]

Fine.

Find a word-addressed processor that does 32-bit chars and 32-bit floats
in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
a Cray-1 or a DSP.)

Run your code snippet on it and tell us what you get back.

If you get more than one "byte" printed out (and can verify that my
conditions are met), I'll concede the point.

If you get a single "byte" printed out, then tell us why that
implementation doesn't support unions.

If this is too much trouble, you're clearly not interested in paying
attention to what I'm saying and reading for comprehension, so there's
no point in me continuing.


dave

--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

[Paul Lutus]

Re: C to Java Byte Code

Dave Vandervies wrote:
[color=blue]
> In article <10nqmt2okb8hne c@corp.supernew s.com>,
> Paul Lutus <nospam@nosite. zzz> wrote:
>[color=green]
>>If the compiler is ANSI C compliant, my example program will compile on
>>that compiler and run on that plartform. Unions are supported by C, they
>>are not supported by Java, and they are not supported by the program under
>>discussion.[/color]
>
> Fine.
>
> Find a word-addressed processor that does 32-bit chars and 32-bit floats
> in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
> a Cray-1 or a DSP.)[/color]

When you are ready to address the topic of this thread, post again.

/ ...
[color=blue]
> If this is too much trouble, you're clearly not interested in paying
> attention to what I'm saying ...[/color]

When you are ready to address the topic of this thread, post again.
[color=blue]
> and reading for comprehension, so there's
> no point in me continuing.[/color]

There is no point in your valiant attempts to move this thread from its
topic.

--
Paul Lutus

http://www.arachnoid.com

[Alex Fraser]

Re: C to Java Byte Code

"Paul Lutus" <nospam@nosite. zzz> wrote in message
news:10nqmt2okb 8hnec@corp.supe rnews.com...
[snip][color=blue]
> If the compiler is ANSI C compliant, my example program will compile on
> that compiler and run on that plartform. Unions are supported by C, they
> are not supported by Java, and they are not supported by the program
> under discussion.[/color]

From these statements, I infer that you have an example program which
demonstrates that unions are not supported. Is this correct? And if so, what
is this example program?

Do you have any other evidence on which you base the claim above? And if so,
what is it?

Alex