Willem said:
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 ?
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.
) 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.
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?
) 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.
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.
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.
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.
) 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.
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.
)> 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 ?
That argument was made by Mr. Abdullah, not my me, and it is time for you to
do you own reading:
<
[email protected]>
*******************************************************************
"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".
