C to Java Byte Code

Maybe you would agree with me that a C compiler that directly
produces Java Byte Code to be run on any JVM is something that is
missing to software programmers so far.  With such a tool one could
stay with C and still be able to produce Java byte code for
platform independent apps.  Also, old programs (with some tweaking)
could be re-compiled and ported to the JVM.

We have been developing such a tool over the last 2 years and currently
beta testing it.

It's called MPC (for Multi-Platform C) and you can download the beta
version at http://www.axiomsol.com or at [url]http://freshmeat.net/projects/c2jvm/[/url
]

Napi

In article <10nk3pjoq09tfa3@corp.supernews.com>,
Paul Lutus  <nospam@nosite.zzz> wrote:
>Mohd Hanafiah Abdullah wrote:
>
>/ ...
> 
>
>Yes, as I expected. So there are no doubles, there are no longs, and there
>are no 8-bit bytes.
>
>Thank you for your candor.

Like I said before, all scalar types are 32-bits long which includes
char, int, short, long, and float.  And for now the same applies for
double and long long as explained in the restriction file that comes with
MPC.

Napi
--
http://www.cs.indiana.edu/hyplan/napi.html

In article <43618c0e.0410151155.5313a302@posting.google.com>,
John Bode <john_bode@my-deja.com> wrote:
>napi@axiomsol.com (napi) wrote in message
>news:<a9083a87.0410141932.589c5eb5@posting.google.com>... 
>
>Alternately, one could bite the bullet and, you know, learn Java for
>new development*.

Yes, you can.  But some people prefer C to Java and there are many C
programmers out there I believe.  It has been around since 1969 starting
at Bell Labs..
 
>
>That's certainly an interesting idea.
>
>So.  How do you handle stuff like graphics, networking, sound, file
>system management, etc., that have all traditionally been handled by
>third-party libraries?  Have you provided your own set of libraries
>for this (a la Neuron Data's Open Interface Elements)?  What vendor
>extensions can you handle?  I can think of some code I've encountered
>over the years that would require a bit more than "some tweaking" to
>conform to a new API.

File system mgmt is covered, while the other APIs we still working on.
We try to use available APIs written in Java and interface to them using
the C syntax.  This was what we did with the File System Mgmt, i.e., using
the ones available from J2SDK.  MPC is still in Beta, so it's still work in
progress.
 
>
>* "Java sucks" is not an excuse.

I think it's just a matter of preference.

Napi

--
http://www.cs.indiana.edu/hyplan/napi.html

Mohd Hanafiah Abdullah wrote:

> In article <43618c0e.0410151155.5313a302@posting.google.com>,
> John Bode <john_bode@my-deja.com> wrote: 
>
> Yes, you can.  But some people prefer C to Java and there are many C
> programmers out there I believe.  It has been around since 1969 starting
> at Bell Labs..

You know, Mr. Abdullah, it would serve the truth better if you explained
what your product cannot do, and if you tried to avoid a marked tendency to
replace candor with marketing hype.

> 

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?
 
>
> File system mgmt is covered, while the other APIs we still working on.
> We try to use available APIs written in Java and interface to them using
> the C syntax.  This was what we did with the File System Mgmt, i.e., using
> the ones available from J2SDK.  MPC is still in Beta, so it's still work
> in progress.
> 

Since Mr. Abdullah has seen fit to start a new cross-posted thread promoting
this commercial C -> Java project, I think it only fair to point out that
the claims on his Web site are not met by his product.

According to the evidence, this project won't actually convert most existing
C programs into Java with a little "tweaking", as is claimed above.

The project may eventually meet some of its claims, but it certainly does
not now, and anyone contemplating involvement with this project should be
very skeptical of the claims being made.

Mr. Abdullah has repeatedly cross-posted messages that are pure marketing
hype, then, when confronted by tough questions, replies with the defense
that the product is in beta, without acknowledging that it very simply
cannot meet the claims posted on the Web site.

--
Paul Lutus
http://www.arachnoid.com

In article <10npbpmkjaqdqa3@corp.supernews.com>, nospam@nosite.zzz
says...
> Mohd Hanafiah Abdullah wrote:
 
>
> And it's false. If, as has been revealed, C programs that use byte indexin
g
> 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 <10npbpmkjaqdqa3@corp.supernews.com>, nospam@nosite.zzz
> says... 
> 
>
> As I understand it, this issue only affects incompetent programmers who
> write code that assumes that bytes have eight bits.

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

<cl7gbh$7th$1@hood.uits.indiana.edu>

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

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

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

Care to retract your argument now, or later?

> The sort of
> programmers in whose code unions are "ubiquitous".

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

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

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

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

--
Paul Lutus
http://www.arachnoid.com

In article <10nqamhfej8qqf5@corp.supernews.com>,
Paul Lutus  <nospam@nosite.zzz> wrote:
>Gerry Quinn wrote:
 
>
>No, the original prohibition to which I refer was provided by Mr. Abdullah,
>who said:
>
><cl7gbh$7th$1@hood.uits.indiana.edu>
>
> ****************************************
*************
>
>" ... programs that assume a byte-addressable architecture will need to be
>modified to suit the one used by MPC."
>
> ****************************************
*************
>
>Care to retract your argument now, or later?

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

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


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

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

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

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


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

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

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


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



dave

--
Dave Vandervies                            dj3vande@csclub.uwaterloo.ca

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

Paul 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 o
f
) unions that they can conjoin two unrelated data types so long as their siz
e
) 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, th
e
) 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 no
t
) 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 th
at
) 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:

<cl7gbh$7th$1@hood.uits.indiana.edu>

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

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea. __Using_a_large_array_of_int_to_mimic_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_as
addresses.__This_memory_is_word-addressable_and_not_byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.__Unions_are_supported."

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

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

--
Paul Lutus
http://www.arachnoid.com

Willem wrote:

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

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

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

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

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

Could you please stop posting these wonderful, albeit tautological,
arguments? Or, alternative, ask yourself how much light is shed on this or
any topic through such arguments?

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

You really need to set up your newsreader properly. Use this post as an
example of standard quoting style.

>
> Again not making sense here. __A_float_is_mapped_to_a_java_integer_by
_the
> product, probably by some glue code.

This is false. A float is not mapped to an integer. According to the OP, an
integer is "mapped" to an integer, in fact, it is the same integer. In any
case, Java is strongly typed and will not allow what you suggest.

> You seem to be claiming that a float
> is an int in this case.

No, the OP claimed this. Perhaps you could read the posted data before
posting.

> Which is silly, because then you couldn't do
> floating point math on it, could you ?

False again. Programmers can do this, and in this case will be required to
do it, because Java will not accommodate a revolving door between integers
and floats.

>
> ) Now we have had the argument from both sides. Mr. Quinn thinks it silly
> that ) someone would make any assumptions about the size of a byte, your
> position ) is that it is silly to assume there is any signifgicant
> flexibility about ) this. Maybe you should address Mr. Quinn's argument
> directly, as I was ) doing.
>
> You're not having the argument from both sides, you're just not making
> sense.__Again. __It's_actually_quite_simple:__The_platf
orm_dictates_the
> size of the byte, and the programmer has to be flexible about the size
> of the byte. __Unless_you're_on_a_weird_machine_like_
a_PDP-10_or_something.

Try reading your own sentences before posting, theh delete the ones that
don't make any sense. This will have a salutary effect on the length of
your posts. When I said earlier that there was little flexibility about the
size of bytes, you argued the opposite position -- that bytes could have
any size. Now you argue that there is little flexibility about the size of
bytes, for which I can only add, read the thread more carefully and try to
avoid revesing your position so readily.

> )> Bytes have a size that is fixed on a single implementation and can
> )> vary between implementations. __I_don't_think_anybody_is_trying_to_cla
im
> )> otherwise.
> )
> ) True, and see above.
>
> So if you admit this is true, then why did you make that silly argument
> about how the product fixed the byte size ?

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

<cl7gbh$7th$1@hood.uits.indiana.edu>

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

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea. __Using_a_large_array_of_int_to_mimic_ad
dressable_memory_is
the cause for this. __The_indexes_to_this_large_array_are_tr
eated_as
addresses.__This_memory_is_word-addressable_and_not_byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.__Unions_are_supported."

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

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

--
Paul Lutus
http://www.arachnoid.com