I think 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
Napi 235  11435 
napi wrote: I think 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.
Probably because writing C for a VM like the Java VM is pretty stupid,
when you /should/ be linking to precompiled libraries from within your
Java (or Perl, or whatever) code.
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.
I can honestly say I've never needed to port legacy C to a VM
environment like the Java VM. I honestly can't see the need, as I've
said above.
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
Heh. /All/ C should be multi-platform, if the programmer is paying
attention to the relevant standards.
napi wrote: I think 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
Napi
The multi platform C runs... in this platform only:
- Linux for x86 operating system (any distribution) running
kernel 2.4 or newer
Period.
AND you should put the MPC logo in your product when shipping
of course.
jacob
On Fri, 15 Oct 2004 02:21:16 -0600, Chris Barts <ch*****@gmail.com>
wrote: napi wrote: I think 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.
Probably because writing C for a VM like the Java VM is pretty stupid,
when you /should/ be linking to precompiled libraries from within your
Java (or Perl, or whatever) code.
Not the same thing. This is the Microsoft .NET approach (which some
people also think is stupid.) 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.
I can honestly say I've never needed to port legacy C to a VM
environment like the Java VM. I honestly can't see the need, as I've
said above.
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
Heh. /All/ C should be multi-platform, if the programmer is paying
attention to the relevant standards.
--
Al Balmer
Balmer Consulting re************************@att.net
On 14 Oct 2004 20:32:39 -0700, na**@axiomsol.com (napi) wrote: I think 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.
I don't know about availability, but there was work done on this from
at least 5 years ago: http://www.cs.ucla.edu/~ashapiro/cminusjava/
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
Why is it restricted to Linux only?
--
Al Balmer
Balmer Consulting re************************@att.net
Alan Balmer wrote: Probably because writing C for a VM like the Java VM is pretty stupid,
when you /should/ be linking to precompiled libraries from within your
Java (or Perl, or whatever) code.
Not the same thing. This is the Microsoft .NET approach (which some
people also think is stupid.)
Incidentally, portable.net includes a C compiler which generates .NET
executables...
Daniel
napi wrote: I think you would agree with me
Are you mad?
<snipped>
goose,
napi wrote: I think 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
C is a procedural language. Unless I am missing something, JVM is only
an OO platform. So, how does it work?
It sounds something like C++ to me.
--
Ioannis Vranos http://www23.brinkster.com/noicys na**@axiomsol.com (napi) wrote in message news:<a9**************************@posting.google. com>... I think 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.
Alternately, one could bite the bullet and, you know, learn Java for
new development*.
Also, old programs (with some tweaking) could be re-compiled and ported
to the JVM.
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.
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
Napi
* "Java sucks" is not an excuse. br***@brianweb.net (Brian Alliet) writes: NestedVM is open source and runs on any platform that GCC runs on. For
more information email Adam Megacz and I (email addrs in the paper).
</shameless plug>
Also in the paper you'll find references to a number of
products/projects like MPC (for example, the Java Bytecode backend for
gcc).
NestedVM has a few other advantages as well; it's not restricted to C
(we've used it on Fortran and Pascal programs as well) and it has no
difficulties with compiler-specific quirks (gcc-specific or
MSVC-specific hacks) since it doesn't try to replace the compiler.
- a
--
I wrote my own mail server and it still has a few bugs.
If you send me a message and it bounces, please forward the
bounce message to me****@gmail.com. Thanks! jo*******@my-deja.com (John Bode) wrote in message news:<43**************************@posting.google. com>... na**@axiomsol.com (napi) wrote in message news:<a9**************************@posting.google. com>... I think 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.
Alternately, one could bite the bullet and, you know, learn Java for
new development*.
Also, old programs (with some tweaking) could be re-compiled and ported
to the JVM.
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.
Currently MPC is in beta and we only support most of the ANSI C
library which includes the file system management. The release
version should support some UNIX system calls library, TCP/IP library,
and graphics library.
MPC is available to be used on Linux/x86 for now which produces code
for the
JVM. Next we will port it to MacOS followed by Solaris and then
Windows XP/NT.
Cheers.
Napi
In article <43**************************@posting.google.com >,
John Bode <jo*******@my-deja.com> wrote: na**@axiomsol.com (napi) wrote in message
news:<a9**************************@posting.google .com>... I think 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.
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.. Also, old programs (with some tweaking) could be re-compiled and ported
to the JVM.
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. 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
Napi
* "Java sucks" is not an excuse.
I think it's just a matter of preference.
Napi
-- http://www.cs.indiana.edu/hyplan/napi.html
Mohd Hanafiah Abdullah wrote: In article <43**************************@posting.google.com >,
John Bode <jo*******@my-deja.com> wrote:na**@axiomsol.com (napi) wrote in message
news:<a9**************************@posting.googl e.com>... I think 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.
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..
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.
Also, old programs (with some tweaking) could be re-compiled and ported
to the JVM.
That's certainly an interesting idea.
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?
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.
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
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
In article <10*************@corp.supernews.com>, no****@nosite.zzz
says... Mohd Hanafiah Abdullah wrote: Also, old programs (with some tweaking) could be re-compiled and ported
to the JVM.
That's certainly an interesting idea.
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
Gerry Quinn wrote: In article <10*************@corp.supernews.com>, no****@nosite.zzz
says... Mohd Hanafiah Abdullah wrote: >>> Also, old programs (with some tweaking) could be re-compiled and
>>> ported to the JVM.
>>
>>That's certainly an interesting idea.
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.
No, the original prohibition to which I refer was provided by Mr. Abdullah,
who said:
<cl**********@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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote: Gerry Quinn wrote:
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:
<cl**********@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 dj******@csclub.uwaterloo.ca
Some of us even have a grip on reality. This is a university, remember?
--Giles Malet in uw.general
Dave Vandervies wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:Gerry Quinn wrote: 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:
<cl**********@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?
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.
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).
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:
<cl**********@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*address able*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.
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.
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?
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
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
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:
<cl**********@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*address able*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
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*p latform*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:
<cl**********@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*address able*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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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. 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.
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? 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.
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. )> 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:
<cl**********@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*address able*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".
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 dj******@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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote: Dave Vandervies wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:Gerry Quinn wrote: 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:
<cl**********@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?
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.
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).
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. 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.
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. 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?
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 dj******@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 wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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;
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
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.
)<cl**********@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*address able*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
Dave Vandervies wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:Dave Vandervies wrote:
/ ...
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.
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:
<cl**********@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*address able*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."
************************************************** *****************
/ ...
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?
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.
/ ...
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.
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?
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.
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
In article <cl**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@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 dj******@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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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 dj******@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 wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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.)
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
"Paul Lutus" <no****@nosite.zzz> wrote in message
news:10*************@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
Alex Fraser wrote: "Paul Lutus" <no****@nosite.zzz> wrote in message
news:10*************@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?
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:
<a9**************************@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*
<cl**********@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*address able*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."
************************************************** *****************
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
Dave Vandervies wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:
/ ...
When you are ready to address the topic of this thread, post again.
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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote: Dave Vandervies wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:Gerry Quinn wrote:
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:
<cl**********@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?
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.
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).
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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote: Dave Vandervies wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:Dave Vandervies wrote:
/ ...
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.
.... 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?
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
Mohd Hanafiah Abdullah wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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.
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
Mohd Hanafiah Abdullah wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:
/ ...
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.
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
Mohd Hanafiah Abdullah wrote: In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote:
/ ...
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.
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
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@nosite.zzz> wrote: Mohd Hanafiah Abdullah wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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.
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
Paul Lutus wrote: Willem wrote:
.... snip ... ) 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
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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Mohd Hanafiah Abdullah wrote:
/ ... 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
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
Paul Lutus <no****@nosite.zzz> writes: Mohd Hanafiah Abdullah wrote: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
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) ks***@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.
Keith Thompson wrote: Paul Lutus <no****@nosite.zzz> writes:
/ ... 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?
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
In message <10*************@corp.supernews.com>, Paul Lutus
<no****@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
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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Paul Lutus <no****@nosite.zzz> writes: Mohd Hanafiah Abdullah wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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.
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 jo*@invalid.address wrote: Paul Lutus <no****@nosite.zzz> writes:
Mohd Hanafiah Abdullah wrote:
In article <10*************@corp.supernews.com>,
Paul Lutus <no****@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.
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
In article <10*************@corp.supernews.com>, no****@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: Paul Lutus <no****@nosite.zzz> writes:
typedef union abc
{ int x;
float y;
} a_union;
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.
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.
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.
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
In message <MP***********************@news.indigo.ie>, Gerry Quinn
<ge****@DELETETHISindigo.ie> writes In article <10*************@corp.supernews.com>, no****@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
Gerry Quinn wrote: In article <10*************@corp.supernews.com>, no****@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: > Paul Lutus <no****@nosite.zzz> writes:
typedef union abc
{ int x;
float y;
} a_union;
>> 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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Dan |
last post by:
Hello.
I have recently tried upgrading the MySql connector for my servlet
from 2.0.4 to 3.0.9. I have found a minor limitation in 2.0.4 and was
hoping that 3.0.9 would fix it. However, now I...
|
by: Gaurav |
last post by:
http://www.sys-con.com/story/print.cfm?storyid=45250
Any comments?
Thanks
Gaurav
|
by: Richard |
last post by:
Level: Java newbie, C experienced
Platform: Linux and Win32, Intel
Another programmer and I are working on a small project together.
He's writing a server process in Java that accepts input...
|
by: napi |
last post by:
I think 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...
|
by: VeeraLakshmi |
last post by:
I am doing a project for internet control using Java,PHP and MySql.All sites
should go through the proxy server only.We are giving access rights as allow or
deny to the sites.If we type the...
|
by: MimiMi |
last post by:
I'm trying to decrypt a byte array in java that was encrypted in C#. I don't get any error messages, just a result that's completely not what I was hoping for.
I think I am using the same type of...
|
by: MimiMi |
last post by:
I'm trying to decrypt a byte array in java that was encrypted in C#. I don't get any error messages, just a result that's completely not what I was hoping for.
I think I am using the same type of...
|
by: r035198x |
last post by:
Setting up.
Getting started
To get started with java, one must download and install a version of Sun's JDK (Java Development Kit).
The newest release at the time of writting this article is...
|
by: Debadatta Mishra |
last post by:
Introduction
In this article I will provide you an approach to manipulate an image file. This article gives you an insight into some tricks in java so that you can conceal sensitive information...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
