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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.
[vbcol=seagreen]
> 

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?
[vbcol=seagreen] 
>
> 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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

Dave Vandervies wrote:

> In article <10nqamhfej8qqf5@corp.supernews.com>,
> Paul Lutus  <nospam@nosite.zzz> wrote: 
> 
>
> ...So it doesn't provide a byte-addressable memory model.
>
> Care to provide a reference to support your claim that C requires a
> byte-addressable memory model?

Before you try to shift the burden of evidence, care to find where I made
this claim? Please do not drift the tread -- this is the easiest imaginable
activity, but it sheds no light on anyting.
 
>
> I haven't been following this thread too closely, but if I'm not mistaken,
> union support was never claimed to be this limited (except by you).

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

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

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

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

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

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

... is false, because if everything is mapped to a native Java integer, the
property and primary value of unions is not provided.

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

But if they are both Java native integers, no mapping is taking place. If
there are two accesses to a simple integer value, the term "mapping" is not
appropriate, but if a C union is provided and two different data types are
mapped/conjoined, the term in appropriate.
 
>
> Does your favorite implementation allow bytes to have many different
> sizes?

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

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

True, and see above.

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

Dave Vandervies wrote:

> In article <10nqj6r9cavr842@corp.supernews.com>,
> Paul Lutus  <nospam@nosite.zzz> wrote:
> 
>
> And on the 386 running the web server in my closet, the C implementation
> doesn't support unions;

Please do not leave the topic, and try to avoid invention to support your
argument. Unions are part of ANSI C.

> one cannot map a float and a byte array, because
> both are turned into the processor's native bytes,

If the compiler is ANSI C compliant, my example program will compile on that
compiler and run on that plartform. Unions are supported by C, they are not
supported by Java, and they are not supported by the program under
discussion.

> so any references to
> one or the other read from a single set of the processor's native bytes;
> IOW the same entity is being accessed in the same way.

Just stop posting. You want to argue, not think, fortunately for you there
are plenty of suitable newsgroups for this onanistic activity.

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

This discussion unfortunately is not just about C, it is about C and Java.
Java does not agree wth you. Floats are treated as a unique data type, and
mixing of data types, as for example in a union, is not allowed in Java.

> If you can stuff the value 42 in and look at the bit pattern and see `00
> 00 28 42', you have something that (for this value at least) acts like
> a 32-bit IEEE floating point number, and you DO NOT have a Java integer.

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

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

/ ...

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

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

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

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

[ Post a follow-up to this message ]