Home > Archive > Unix Programming > October 2004 > C to Java Byte Code
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
C to Java Byte Code
|
|
|
| Maybe you would agree with me that a C compiler that directly
produces Java Byte Code to be run on any JVM is something that is
missing to software programmers so far. With such a tool one could
stay with C and still be able to produce Java byte code for
platform independent apps. Also, old programs (with some tweaking)
could be re-compiled and ported to the JVM.
We have been developing such a tool over the last 2 years and currently
beta testing it.
It's called MPC (for Multi-Platform C) and you can download the beta
version at http://www.axiomsol.com or at http://freshmeat.net/projects/c2jvm/
Napi
| |
| Mohd Hanafiah Abdullah 2004-10-25, 3:59 am |
| In article <10nk3pjoq09tfa3@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>Mohd Hanafiah Abdullah wrote:
>
>/ ...
>
>
>Yes, as I expected. So there are no doubles, there are no longs, and there
>are no 8-bit bytes.
>
>Thank you for your candor.
Like I said before, all scalar types are 32-bits long which includes
char, int, short, long, and float. And for now the same applies for
double and long long as explained in the restriction file that comes with
MPC.
Napi
--
http://www.cs.indiana.edu/hyplan/napi.html
| |
| Mohd Hanafiah Abdullah 2004-10-25, 3:59 am |
| In article <43618c0e.0410151155.5313a302@posting.google.com>,
John Bode <john_bode@my-deja.com> wrote:
>napi@axiomsol.com (napi) wrote in message
>news:<a9083a87.0410141932.589c5eb5@posting.google.com>...
>
>Alternately, one could bite the bullet and, you know, learn Java for
>new development*.
Yes, you can. But some people prefer C to Java and there are many C
programmers out there I believe. It has been around since 1969 starting
at Bell Labs..
>
>That's certainly an interesting idea.
>
>So. How do you handle stuff like graphics, networking, sound, file
>system management, etc., that have all traditionally been handled by
>third-party libraries? Have you provided your own set of libraries
>for this (a la Neuron Data's Open Interface Elements)? What vendor
>extensions can you handle? I can think of some code I've encountered
>over the years that would require a bit more than "some tweaking" to
>conform to a new API.
File system mgmt is covered, while the other APIs we still working on.
We try to use available APIs written in Java and interface to them using
the C syntax. This was what we did with the File System Mgmt, i.e., using
the ones available from J2SDK. MPC is still in Beta, so it's still work in
progress.
>
>* "Java sucks" is not an excuse.
I think it's just a matter of preference.
Napi
--
http://www.cs.indiana.edu/hyplan/napi.html
| |
| Paul Lutus 2004-10-25, 3:59 am |
| Mohd Hanafiah Abdullah wrote:
> In article <43618c0e.0410151155.5313a302@posting.google.com>,
> John Bode <john_bode@my-deja.com> wrote:
>
> Yes, you can. But some people prefer C to Java and there are many C
> programmers out there I believe. It has been around since 1969 starting
> at Bell Labs..
You know, Mr. Abdullah, it would serve the truth better if you explained
what your product cannot do, and if you tried to avoid a marked tendency to
replace candor with marketing hype.
[color=darkred]
>
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=darkred]
>
> File system mgmt is covered, while the other APIs we still working on.
> We try to use available APIs written in Java and interface to them using
> the C syntax. This was what we did with the File System Mgmt, i.e., using
> the ones available from J2SDK. MPC is still in Beta, so it's still work
> in progress.
>
Since Mr. Abdullah has seen fit to start a new cross-posted thread promoting
this commercial C -> Java project, I think it only fair to point out that
the claims on his Web site are not met by his product.
According to the evidence, this project won't actually convert most existing
C programs into Java with a little "tweaking", as is claimed above.
The project may eventually meet some of its claims, but it certainly does
not now, and anyone contemplating involvement with this project should be
very skeptical of the claims being made.
Mr. Abdullah has repeatedly cross-posted messages that are pure marketing
hype, then, when confronted by tough questions, replies with the defense
that the product is in beta, without acknowledging that it very simply
cannot meet the claims posted on the Web site.
--
Paul Lutus
http://www.arachnoid.com
| |
| Gerry Quinn 2004-10-25, 8:56 am |
| In article <10npbpmkjaqdqa3@corp.supernews.com>, nospam@nosite.zzz
says...
> Mohd Hanafiah Abdullah wrote:
>
> 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?
As I understand it, this issue only affects incompetent programmers who
write code that assumes that bytes have eight bits. The sort of
programmers in whose code unions are "ubiquitous".
- Gerry Quinn
| |
| Paul Lutus 2004-10-25, 4:01 pm |
| Gerry Quinn wrote:
> In article <10npbpmkjaqdqa3@corp.supernews.com>, nospam@nosite.zzz
> says...
>
>
> 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.indiana.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?
> The sort of
> programmers in whose code unions are "ubiquitous".
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 2004-10-25, 4:01 pm |
| In article <10nqamhfej8qqf5@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>Gerry Quinn wrote:
>
>No, the original prohibition to which I refer was provided by Mr. Abdullah,
>who said:
>
><cl7gbh$7th$1@hood.uits.indiana.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?
....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?
>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.
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.
>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.
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.
>If you intend to argue without thinking, don't bother to post.
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 2004-10-25, 4:01 pm |
| Dave Vandervies wrote:
> In article <10nqamhfej8qqf5@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
>
>
> ...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?
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.
>
> 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.
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@hood.uits.indiana.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_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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.
>
> 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.
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.
>
> Does your favorite implementation allow bytes to have many different
> sizes?
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.
> 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.
--
Paul Lutus
http://www.arachnoid.com
| |
| Willem 2004-10-25, 4:01 pm |
| 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 2004-10-25, 4:01 pm |
| Willem wrote:
> 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:
<cl7gbh$7th$1@hood.uits.indiana.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_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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 2004-10-25, 4:01 pm |
| Willem wrote:
> 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,_b
ut_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_platf
orm_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_cla
im
> )> 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:
<cl7gbh$7th$1@hood.uits.indiana.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_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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 2004-10-25, 4:01 pm |
| In article <10nqj6r9cavr842@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>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.
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.
>
>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.
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?
>
>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.
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.
>
>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.indiana.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_ad
dressable_memory_is
>the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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".
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 2004-10-25, 4:01 pm |
| In article <10nqefd36j5pod2@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>Dave Vandervies wrote:
>
>
>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.
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.
>
>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.
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.
>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,
....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.
>
>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.
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.
>
>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.
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 2004-10-25, 8:56 pm |
| Dave Vandervies wrote:
> In article <10nqj6r9cavr842@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
>
>
> And on the 386 running the web server in my closet, the C implementation
> doesn't support unions;
Please do not leave the topic, and try to avoid invention to support your
argument. Unions are part of ANSI C.
> one cannot map a float and a byte array, because
> both are turned into the processor's native bytes,
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.
> 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.
Just stop posting. You want to argue, not think, fortunately for you there
are plenty of suitable newsgroups for this onanistic activity.
>
> [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.
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.
> 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.
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.
/ ...
> 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.
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 2004-10-25, 8:56 pm |
| Paul wrote:
) Willem wrote:
)> That's an odd thing to say. __Maybe_I'm_not_reading_you_correctly,_b
ut_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.indiana.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_ad
dressable_memory_is
) the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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 2004-10-25, 8:56 pm |
| Dave Vandervies wrote:
> In article <10nqefd36j5pod2@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
/ ...
[color=darkred]
>
> 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.
Post the quote in which I used these words, or retract the claim. I never
said what you claim I said.
> Unless you can demonstrate that C requires a byte-addressable memory
> model, your complaint
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@hood.uits.indiana.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_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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."
****************************************
***************************
/ ...
>
> 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?
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.
> They're not stored "as integers";
They are stored as Java native integers.
> they're stored in an array of integers
> that gets treated as a word-addressed memory space.
Onanism.
/ ...
>
> ...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.
Yes, correct, therefore the OP's claims are false.
> 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.
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?
>
> They're not Java native integers.
In fact, that is exactly what they are. The term "native" in Java has a
different meaning than you may be familiar with.
> They're values that happen to be
> represented by a 32-bit word, that happens to fit nicely in a Java
> integer.
They are Java native integers, as distinct from java Integer class
instances.
/ ...
> 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,
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 2004-10-25, 8:56 pm |
| In article <cljnfj$htm$1@rumours.uwaterloo.ca>,
Dave Vandervies <dj3vande@csclub.uwaterloo.ca> wrote:
>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.)
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 2004-10-25, 8:56 pm |
| In article <10nqmt2okb8hnec@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>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.
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 2004-10-25, 8:56 pm |
| Dave Vandervies wrote:
> In article <10nqmt2okb8hnec@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
>
>
> 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.)
When you are ready to address the topic of this thread, post again.
/ ...
> If this is too much trouble, you're clearly not interested in paying
> attention to what I'm saying ...
When you are ready to address the topic of this thread, post again.
> and reading for comprehension, so there's
> no point in me continuing.
There is no point in your valiant attempts to move this thread from its
topic.
--
Paul Lutus
http://www.arachnoid.com
| |
| Alex Fraser 2004-10-25, 8:56 pm |
| "Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10nqmt2okb8hnec@corp.supernews.com...
[snip]
> 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.
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
| |
| Paul Lutus 2004-10-25, 8:56 pm |
| Alex Fraser wrote:
> "Paul Lutus" <nospam@nosite.zzz> wrote in message
> news:10nqmt2okb8hnec@corp.supernews.com...
> [snip]
>
> 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?
1. The OP, unhappy with the original thread and eager to get some additional
free publicity for his commercial product, created a new thread. The old
thread has the same name and starts here:
<a9083a87.0410141937.1a7d4e1d@posting.google.com>
2. Java does not support the mapping of one variable type onto another.
3. The product in question solves this problem by turning everything into a
32-bit word, this making the "union" issue moot, since there is no point
creating a union betweeen a thing and itself.
The basic issue is that the disparate data types that can be mapped using
"union" in C, cannot be mapped at all in Java (because of the latter's
strong data typing). The OP solved this problem by making all data into
32-bit words.
>
> Do you have any other evidence on which you base the claim above?
Please take the time to read this and the prior thread before raising closed
issues.
> And if
> so, what is it?
*sigh*
<cl7gbh$7th$1@hood.uits.indiana.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_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_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."
****************************************
***************************
If, as the OP claims, all data are 32-bit words, then the claim that unions
are supported is false, since (1) Java will not allow disparate data types
to be overlaid in memory, and (2) a union's purpose is the mapping of
disparate data types, and there aren't any disparate data types.
BTW there is also no support for anything that requires fewer or more than
32 bits, e.g no support for typical doubles as just one example.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-25, 8:56 pm |
| Dave Vandervies wrote:
> In article <10nqq7cnnsv8525@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
/ ...
>
> I'm attempting to address the suitability of using an array of 32-bit
> values to store values of varying types and use a union to convert
> between the values stored there.
That is not the topic, and you need to find out what "thread drift" refers
to. You are always free to start any thread, on any topic, in any suitable
newsgroup. For this thread, a thread originated and cross-posted to four
nearly unrelated newsgroups by an unscrupulous commercial vendor eager for
free publicity, you have limited options other than addressing the topic.
> Since that's obviously not what you think the topic of this thread is,
I did not start this thread, cross-post it, or choose its topic.
> there's not much point in me continuing.
There is not much point in your continuing.
> This thread is going in the killfile as soon as I post this article.
Why not before?
> This means you can claim I'm wrong,
Post the quote of the statement you falsely claim I made, or retract your
false claim. Never invent statements for other people. I never said what
you claim, the ball is in your court, we won't hold our breath.
grep "wrong" (this thread) || echo "No evidence, no argument."
> accuse me of onanism, and refuse to
> accept that you might not know everything all you want,
"Everything all you want"? I was right, your brain really is offline.
> and I promise
> not to reply unless somebody changes the subject line.
We'll see.
--
Paul Lutus
http://www.arachnoid.com
| |
| Mohd Hanafiah Abdullah 2004-10-26, 3:56 am |
| In article <10nqamhfej8qqf5@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>
>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.
Excuse me, but unions are supported in the product being discussed.
Napi
--
http://www.cs.indiana.edu/hyplan/napi.html
| |
| Mohd Hanafiah Abdullah 2004-10-26, 3:56 am |
| In article <10nqefd36j5pod2@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>Dave Vandervies wrote:
>
>
>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.
>
>
>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.
All variables are located in the large array of int. As a result of
register allocation several of the variables end up cached in Java native
variables of int type or float type. But, their home locations are always
in the large array of int. And again, unions and structs are supported.
Napi
--
http://www.cs.indiana.edu/hyplan/napi.html
| |
| Mohd Hanafiah Abdullah 2004-10-26, 3:56 am |
| In article <10nqnnc7nau6m73@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>Dave Vandervies wrote:
>
>
>/ ...
>
....[color=darkred]
>
>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?
Actually neither I here nor the website ever claimed this is a conversion from
C to Java, but a conversion from C to Java Byte Code, and that's a big
difference. Please read carefully.
Napi
--
http://www.cs.indiana.edu/hyplan/napi.html
| |
| Paul Lutus 2004-10-26, 3:56 am |
| Mohd Hanafiah Abdullah wrote:
> In article <10nqamhfej8qqf5@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
>
> Excuse me, but unions are supported in the product being discussed.
Post the byte code in which a Java float is united with a Java integer. Or
retract your statement.
Unions are not supported in your product. A C union is a joining of two or
more distinct variable types with simultaneous access to both, e.g. it is
an example of a memory block shared between data types. This is not allowed
in Java because of strong typing.
You have arranged to create a single 32-bit word datatype to represent
everything, so there is no distinction between one kind of variable and
another. Therefore there are no disparate data types, therefore there are
no unions as that term is understood.
But, as I say above, prove me wrong. Post the Java bytecode that unites a
Java float and a Java integer in the same address space, something not
allowed in Java.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-26, 3:56 am |
| Mohd Hanafiah Abdullah wrote:
> In article <10nqefd36j5pod2@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
/ ...
>
> All variables are located in the large array of int. As a result of
> register allocation several of the variables end up cached in Java native
> variables of int type or float type.
Please explain how you have used "register allocation" to circumvent Java's
strong data typing. Or are you talking about native code called by Java?
> But, their home locations are always
> in the large array of int. And again, unions and structs are supported.
Show us the bytecode that overlays a Java float and a Java integer into the
same memory space. That is what a union is. Show us the Java bytecode that
allows one to manipulate individual bits of a Java float datatype, as a C
union allows.
If you use the obvious approach of translating the float using
Float.floatToIntBits() and the reverse method, it wil be interesting to se
how you handle simultanous changes to both forms. In any case, it is not a
union. Java doesn't allow this.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-26, 3:56 am |
| Mohd Hanafiah Abdullah wrote:
> In article <10nqnnc7nau6m73@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
/ ...
>
> Actually neither I here nor the website ever claimed this is a conversion
> from C to Java, but a conversion from C to Java Byte Code, and that's a
> big difference.
No, it is not a difference at all. This is because of "javap" and similar
tools, which allow one to acquire a rudimentary source file from any Java
bytecode file.
Or are you claiming that you have created Java bytecode that cannot be
rendered into human-readable form by "javap" and other similar tools? I am
sure Sun Microsystems will be very interested to hear of this development.
> Please read carefully.
Please check your facts before posting. In any case, as anyone can see by
reading this and the thread you abandoned, the objections are not about
whether Java source or bytecode is generated, but whether the statements
made are valid claims or marketing hype.
--
Paul Lutus
http://www.arachnoid.com
| |
| Mohd Hanafiah Abdullah 2004-10-26, 3:56 am |
| In article <10nre1ja02ulldc@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
>Mohd Hanafiah Abdullah wrote:
>
>
>Post the byte code in which a Java float is united with a Java integer. Or
>retract your statement.
>
>Unions are not supported in your product. A C union is a joining of two or
>more distinct variable types with simultaneous access to both, e.g. it is
>an example of a memory block shared between data types. This is not allowed
>in Java because of strong typing.
>
>You have arranged to create a single 32-bit word datatype to represent
>everything, so there is no distinction between one kind of variable and
>another. Therefore there are no disparate data types, therefore there are
>no unions as that term is understood.
>
>But, as I say above, prove me wrong. Post the Java bytecode that unites a
>Java float and a Java integer in the same address space, something not
>allowed in Java.
Here's an example:
#include <stdio.h>
typedef union abc
{ int x;
float y;
} a_union;
main()
{ a_union z;
z.x = 1078531719;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);
z.y = 3.142;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);
}
MPC produced:
int val = 1078531719
float val = 3.142
int val = 1078531719
float val = 3.142
gcc produced:
int val = 1078531719
float val = 3.142000
int val = 1078531719
float val = 3.142000
Napi
--
http://www.cs.indiana.edu/hyplan/napi.html
| |
| CBFalconer 2004-10-26, 3:56 am |
| Paul Lutus wrote:
> Willem wrote:
>
.... snip ...
>
>
> You really need to set up your newsreader properly. Use this post
> as an example of standard quoting style.
His problem is extremely simple - stop using a non-standard quote
character. The standard is '>', not ')'.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
| |
| Paul Lutus 2004-10-26, 3:56 am |
| Mohd Hanafiah Abdullah wrote:
/ ...
>
> Here's an example:
>
> #include <stdio.h>
>
> typedef union abc
> { int x;
> float y;
> } a_union;
>
> main()
> { a_union z;
>
> z.x = 1078531719;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);
>
> z.y = 3.142;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);
> }
>
> MPC produced:
> int val = 1078531719
> float val = 3.142
> int val = 1078531719
> float val = 3.142
1. This doesn't reply to my post's request.
2. This is not a union, it it two instances of the same variable. Again, to
reply to my post, you need to provide the Java bytecode that unites a Java
float and a Java integer in the same address space, something that is not
allowed in Java.
I would ask that you post an example of two data types of innately different
sizes, but you have already designed your way out of that possibility,
along with any support for doubles and other data types larger or smaller
than 32 bits.
To summarize, this is a commercial exploitation of Usenet for private gain,
an attempt to market a product with hype rather than truth. The description
of the product in the thread by Mr. Abdullah directly, and on his Website,
simply does not correspond to the truth.
According to Mr. Abdullah, a little "tweaking" will make a typical C program
compatible with his product. But in tests and in the few moments of candor
from these threads, this turns out not to be true for several reasons.
Interested readers can read this thread and the one Mr. Abdullah abandoned
to assemble a more accurate picture.
I call on Mr. Abdullah to release review copies of his product to
professional reviewers, rather than try to construct set pieces that have
little to do with the information requested, while valiantly trying to
exploit Usenet for private gain.
--
Paul Lutus
http://www.arachnoid.com
| |
| Keith Thompson 2004-10-26, 3:56 am |
| Paul Lutus <nospam@nosite.zzz> writes:
> Mohd Hanafiah Abdullah wrote:
>
> 1. This doesn't reply to my post's request.
>
> 2. This is not a union, it it two instances of the same variable. Again, to
> reply to my post, you need to provide the Java bytecode that unites a Java
> float and a Java integer in the same address space, something that is not
> allowed in Java.
How is this not a union? What do you think a union is, anyway?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
| |
| Paul Lutus 2004-10-26, 9:00 am |
| Keith Thompson wrote:
> Paul Lutus <nospam@nosite.zzz> writes:
/ ...
>
> How is this not a union? What do you think a union is, anyway?
A union is two or more disparate variable types that share the same memory
space. Because of its strong data typing, Java simply doesn't allow this.
As a result, the program in question has to jump through hoops to pretend
to support a union such as is imagined to exist in the above examples and
those I provided earlier.
This is why I asked to see the Java bytecode, and this is why Mr. Abdullah
refused my request.
--
Paul Lutus
http://www.arachnoid.com
| |
| Richard Herring 2004-10-26, 9:00 am |
| In message <10nre1ja02ulldc@corp.supernews.com>, Paul Lutus
<nospam@nosite.zzz> writes
[too much]
You don't appear to be discussing C++ here, so please remove
comp.lang.c++ from the newsgroups list in your future postings.
Followups set.
A study of BCPL 's type system might shed more light, in any case ;-)
--
Richard Herring
| |
| Azumanga 2004-10-26, 3:58 pm |
| Paul Lutus wrote:
> Mohd Hanafiah Abdullah wrote:
>
>
>
>
> Post the byte code in which a Java float is united with a Java integer. Or
> retract your statement.
Surely the question of if he can unify a java float with a java integer
is not important? The question is if his program can take a program
written in according the the c standard, compile that program, execute
it, and then produce the output the standard says.
Your argument seems to me to read the same as saying "You can't turn C
into assembler on X processor, as X processor doesn't support floating
point". Of course you can, you just emulate the floating point so that
the user cannot tell.
Chris
| |
| Azumanga 2004-10-26, 3:58 pm |
| Paul Lutus wrote:
> Mohd Hanafiah Abdullah wrote:
>
>
>
>
> / ...
>
>
>
>
> Please explain how you have used "register allocation" to circumvent Java's
> strong data typing. Or are you talking about native code called by Java?
>
>
>
>
> Show us the bytecode that overlays a Java float and a Java integer into the
> same memory space. That is what a union is. Show us the Java bytecode that
> allows one to manipulate individual bits of a Java float datatype, as a C
> union allows.
>
He doesn't have to overlay a java float and a java integer in the same
memory space. He merely has to show whatever he has decided to represent
a C integer and a C floating point number in the same memory location.
Of course it would be more efficent if these were java floats and java
integers, but in no way is this necessary (for example the way I would
do this would be to use a less inefficent implementation just for
unions, and then native java variables for non-unions).
Chris
| |
| CBFalconer 2004-10-26, 3:58 pm |
| Mohd Hanafiah Abdullah wrote:
>
.... snip ...
>
> Here's an example:
>
> #include <stdio.h>
>
> typedef union abc
> { int x;
> float y;
> } a_union;
>
> main()
> { a_union z;
>
> z.x = 1078531719;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);
illegal statement here. You cannot access a field of a union as a
type other than what you last wrote into it.
>
> z.y = 3.142;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);
Same thing here.
> }
>
> MPC produced:
Meaningless. This is undefined behavior.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
| |
| joe@invalid.address 2004-10-26, 3:58 pm |
| Paul Lutus <nospam@nosite.zzz> writes:
> Mohd Hanafiah Abdullah wrote:
>
[color=darkred]
>
> Post the byte code in which a Java float is united with a Java
> integer. Or retract your statement.
>
> Unions are not supported in your product. A C union is a joining of
> two or more distinct variable types with simultaneous access to
> both, e.g. it is an example of a memory block shared between data
> types. This is not allowed in Java because of strong typing.
It's not allowed in C/C++ either. Accessing a union member as anything
other than what it was last written as is undefined.
Joe
--
Nothing cures like time and love
- Laura Nyro
| |
|
| joe@invalid.address wrote:
> Paul Lutus <nospam@nosite.zzz> writes:
>
>
>
>
>
>
> It's not allowed in C/C++ either. Accessing a union member as anything
> other than what it was last written as is undefined.
>
> Joe
<C>
Is it undefined or unspecified? Annex J.1 in C99, page 488, lists "The
value of a union member other than the last one stored into", as
unspecified and refers to §6.2.6.1.
I'm not asking just to be a PITA, but because I recently spent at least
an hour browsing the standard for the chapter&verse which said that it
was undefined. Couldn't find anything except J.1.
</C>
boa
| |
| Richard Bos 2004-10-26, 3:58 pm |
| Paul Lutus <nospam@nosite.zzz> wrote:
> Dave Vandervies wrote:
>
# 3.6
# 1 byte
# addressable unit of data storage large enough to hold any member of
# the basic character set of the execution environment
# 2 NOTE 1 It is possible to express the address of each individual byte
# of an object uniquely.
Of course, a byte needn't be an octet, and in fact, in the
implementation under discussion, a byte is _not_ an octet.
[color=darkred]
>
> 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.
I cannot be certain what you mean by "conjoin", but if you mean, as
would be my guess, that you can assign a value to one member of an array
and then read from another member with another type, that capability
does not in fact exist in ISO C, unless the other type is unsigned char.
This does not mean that I think this implementation would be useless for
general programming, nor that this opinion is partly based on its
mapping all basic C types to a Java int. However, unions have little, if
anything, to do with it. <ctype.h> is a larger problem. So is EOF.
Richard
| |
| Richard Bos 2004-10-26, 3:58 pm |
| rlb@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> This does not mean that I think this implementation would be useless for
^^^
do not
> general programming,
*cough* Bloody fingers...
Richard
| |
| Gerry Quinn 2004-10-26, 3:58 pm |
| In article <10ns45fm1agi652@corp.supernews.com>, nospam@nosite.zzz
says...
[My apologies for accidental double post on comp.lang.c. Mr. Lutus is
now attempting to escape his embarrasment by silently changing follow-
ups.]
> Keith Thompson wrote:
typedef union abc
{ int x;
float y;
} a_union;
[color=darkred]
Of course it's a union. It has two members x and y which are in this
instance of different types, although that is by no means part of the
specification.
Within the C program of which the above is a fragment, the data stored
in an instance of the union can be referenced as an int or a float, and
will be interpreted in the appropriate manner. THAT IS ALL. NOTHING
ELSE IS TO BE EXPECTED ACCORDING TO THE DEFINITION OF THE C LANGUAGE.
You can use it as a structured way to store variant data types compactly
(the basic function of unions), or you can use it in a hackerish way to
investigate data storage on a target system and implementation. You
used it in the latter fashion and for some reason you didn't like the
results. But it worked just fine. C doesn't make any promises about
the results of reinterpreting disparate types.
[color=darkred]
>
> A union is two or more disparate variable types that share the same memory
> space. Because of its strong data typing, Java simply doesn't allow this.
> As a result, the program in question has to jump through hoops to pretend
> to support a union such as is imagined to exist in the above examples and
> those I provided earlier.
There is no reason at all why the types should have to be be disparate,
although in this case they are, albeit their representations currently
happen to be the same size. And Java and its strong typing are
completely irrelevant, just as irrelevant as the details of whatever CPU
is running a compiled version of the C program containing the union
definition above. Neither bytecode nor machine code has unions. Unions
are a feature of C, not of compiled executables.
- Gerry Quinn
| |
| Richard Herring 2004-10-26, 3:58 pm |
| In message <MPG.1be88430bd2306c989a5d@news.indigo.ie>, Gerry Quinn
<gerryq@DELETETHISindigo.ie> writes
>In article <10ns45fm1agi652@corp.supernews.com>, nospam@nosite.zzz
>says...
>
>[My apologies for accidental double post on comp.lang.c. Mr. Lutus is
>now attempting to escape his embarrasment by silently changing follow-
>ups.]
Since you're not discussing C++, please spare comp.lang.c++ the rest of
this thread.
Followups set.
--
Richard Herring
| |
| joe@invalid.address 2004-10-26, 3:58 pm |
| boa <root@localhost.com> writes:
> joe@invalid.address wrote:
>
[color=darkred]
[color=darkred]
>
> <C>
> Is it undefined or unspecified? Annex J.1 in C99, page 488, lists "The
> value of a union member other than the last one stored into", as
> unspecified and refers to §6.2.6.1.
Errp, sorry my mistake. It's unspecified. There is an exception given
in 6.5.2.5 though.
Joe
--
Nothing cures like time and love
- Laura Nyro
| |
| Paul Lutus 2004-10-26, 3:58 pm |
| Azumanga wrote:
> Paul Lutus wrote:
>
> Surely the question of if he can unify a java float with a java integer
> is not important? The question is if his program can take a program
> written in according the the c standard, compile that program, execute
> it, and then produce the output the standard says.
>
> Your argument seems to me to read the same as saying "You can't turn C
> into assembler on X processor, as X processor doesn't support floating
> point". Of course you can, you just emulate the floating point so that
> the user cannot tell.
Yes, a point I made earlier, but the product doesn't support anything but
32-bit words, which means a few sample programs I submitted earlier didn't
create the expected results. So I wanted to see if we could establish this
point. If he is performing some internal gymnastics to make it seem as
though a union is present, there may be circumstances when it cannot
function correctly, in particular in Java where there is strict typing.
IOW he is saying unions are supported, but programs that include unions are
misbehaving. I wanted to see if we could get more details, which led to
some of the inquiries in this thread.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-26, 3:58 pm |
| Gerry Quinn wrote:
> In article <10ns45fm1agi652@corp.supernews.com>, nospam@nosite.zzz
> says...
>
> [My apologies for accidental double post on comp.lang.c. Mr. Lutus is
> now attempting to escape his embarrasment by silently changing follow-
> ups.]
>
>
> typedef union abc
> { int x;
> float y;
> } a_union;
>
>
> Of course it's a union. It has two members x and y which are in this
> instance of different types, although that is by no means part of the
> specification.
Yes, it is a union in C, but I am saying it is not a union in the Java
bytecode. You have made this appear to be the meaning of my statement by
concatenating two unconnected parts of posts, creating the illusion of a
sequence that was not present in the original.
This intentional misquote unermines your entire post. My statement is
clearly that, since Java doesn't support anything like a union, the product
doesn't create unions as its output, it can only read them from the C
source and then figure out what to do with them. What it produces in Java
bytecode is not a union. And, more to the point, what it does produce
behaves differently than the original C code does.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-26, 3:58 pm |
| Azumanga wrote:
/ ...
> He doesn't have to overlay a java float and a java integer in the same
> memory space. He merely has to show whatever he has decided to represent
> a C integer and a C floating point number in the same memory location.
> Of course it would be more efficent if these were java floats and java
> integers, but in no way is this necessary (for example the way I would
> do this would be to use a less inefficent implementation just for
> unions, and then native java variables for non-unions).
Yes, true, but the result needs to resemble the behavior of the original C
program. We haven't seen anything like that yet in the two submitted test
programs. The product creates results that differ, in large and small ways,
from the original C programs.
On that topic, here is the post containing the third test program:
<10ns3k0oao3bh4b@corp.supernews.com>
This program uses techniques that are easily managed by C (as well as by
Java if written in Java), but will not produce the expected results if
translated by the product being discussed.
--
Paul Lutus
http://www.arachnoid.com
| |
| Willem 2004-10-26, 3:58 pm |
| Paul wrote:
) Yes, it is a union in C, but I am saying it is not a union in the Java
) bytecode.
It doesnt *need* to be a union in the Java bytecode, you moron.
In case you hadn't noticed, if I compile a piece of C codes with unions
with, say, gcc, then the resulting assembly code does *not* have 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
| |
| Willem 2004-10-26, 3:58 pm |
| Paul wrote:
) Yes, a point I made earlier, but the product doesn't support anything but
) 32-bit words, which means a few sample programs I submitted earlier didn't
) create the expected results.
The programs you submitted most certainly *did* create the expected
results. That the results were not what *you* expected is just because
you're either a troll or a moron.
If I used a normal C-compiler on a computer that had hardware with 32-bit
bytes, then the result would be the same as the result gotten with MPC.
Are you claiming that an ordinary C compiler on such hardware 'does not
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
| |
| E. Robert Tisdale 2004-10-26, 8:56 pm |
| Willem wrote:
> you're either a troll or a moron.
Why not both?
Seriously, check Google groups
http://groups.google.com/
for articles about/by Paul Lutus.
And, once enlightened, consider your own behavior.
| |
| Mark McIntyre 2004-10-26, 8:56 pm |
| On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
<nospam@nosite.zzz> wrote:
>Yes, it is a union in C, but I am saying it is not a union in the Java
>bytecode.
Marvellous. Since this has nothing to do with C any more, why the heck are
you stupidly crossposting this long and pointless thread in CLC and CLC++.
Go away.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
| |
| Old Wolf 2004-10-26, 8:56 pm |
| Paul Lutus <nospam@nosite.zzz> wrote:
> Show us the bytecode that overlays a Java float and a Java integer into the
> same memory space. That is what a union is.
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.
(They must all return the same thing when their address is
taken and then converted to (void *), but it does not follow
from that that they occupy the same physical memory).
> 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.
The following results are conforming to the C specification
(note, this is a minor modification of a program posted
elsewhere in the thread):
#include <stdio.h>
typedef union abc
{ int x;
float y;
} a_union;
main()
{ a_union z;
z.x = 1;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);
z.y = 3.142;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);
return 0;
}
Results:
int val = 1
float val = 3.142
int val = 1
float val = 3.142
| |
| Paul Lutus 2004-10-27, 3:56 am |
| Willem wrote:
> Paul wrote:
> ) Yes, a point I made earlier, but the product doesn't support anything
> but ) 32-bit words, which means a few sample programs I submitted earlier
> didn't ) create the expected results.
>
> The programs you submitted most certainly *did* create the expected
> results.
False. For both programs, the result was not the intended, design output,
the result one gets on a standard, contemporary C compiler.
You know, you cannot argue facts away. This is not philosophy and it is not
a tea party. You cannot twist the truth into a knot, then claim victory.
> That the results were not what *you* expected is just because
> you're either a troll or a moron.
Thank you for moving to your area of conpetence so swiftly. Do you think the
readers of this newsgroup will find this useful, despite it being false?
> Are you claiming that an ordinary C compiler on such hardware 'does not
> support unions'?
No, you are. I have never said this, and you have used this exact same
tactic on countless occasions -- invent a position someone has never taken,
then argue with it. This is called "onanism". Don't wear yourself out.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-27, 3:56 am |
| Mark McIntyre wrote:
> On Tue, 26 Oct 2004 11:36:02 -0700, in comp.lang.c , Paul Lutus
> <nospam@nosite.zzz> wrote:
>
>
> Marvellous. Since this has nothing to do with C any more,
Do you see a reference to C in the sentence above? No? Is there an
optometrist available in your neighborhood?
The discussion is about a C to Java cross-compiler. Both languages are
therefore topical.
> why the heck are
> you stupidly crossposting this long and pointless thread in CLC and CLC++.
The OP, an unscrupulous, predatory commercial vendor, created this
cross-posted thread. If you don't like it, argue with him.
> Go away.
Do the world a favor. Killfile Usenet.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-27, 3:56 am |
| Willem wrote:
> Paul wrote:
> ) Yes, it is a union in C, but I am saying it is not a union in the Java
> ) bytecode.
>
> It doesnt *need* to be a union in the Java bytecode, you moron.
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. But Java does not support unions, and you cannot force Java
to accept anything resembling a union. What you can do is switch data back
and forth using existing getter and setter methods for some data types, but
this masquerade will not always work, as has been shown in this and the
prior thread.
> In case you hadn't noticed, if I compile a piece of C codes with unions
> with, say, gcc, then the resulting assembly code does *not* have unions.
In case you haven't noticed, you have lost the ability to post anything of
any use to anyone. This is why you find it necessary to leave the topic
with such regularity -- it induces in your fingers a belief that your brain
is still online.
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-10-27, 3:56 am |
| Old Wolf wrote:
> Paul Lutus <nospam@nosite.zzz> 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.
I never said it was a requirement. What I said is quoted clearly above your
targetless demurrer.
> If you disagree then please quote a standard reference.
http://explanation-guide.info/meani...uage-union.html
"Because they occupy the same space, changing u.a also changes th | | |