C to Java Byte Code

[napi]

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

[Chris Barts]

Re: C to Java Byte Code

napi wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
>
> 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[/color]

Heh. /All/ C should be multi-platform, if the programmer is paying
attention to the relevant standards.

[jacob navia]

Re: C to Java Byte Code

napi wrote:[color=blue]
> 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[/color]

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

[Alan Balmer]

Re: C to Java Byte Code

On Fri, 15 Oct 2004 02:21:16 -0600, Chris Barts <chbarts@gmail. com>
wrote:
[color=blue]
>napi wrote:[color=green]
>> 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.[/color]
>
>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.
>[/color]
Not the same thing. This is the Microsoft .NET approach (which some
people also think is stupid.)
[color=blue][color=green]
>> 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.[/color]
>
>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.
>[color=green]
>>
>> 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[/color]
>
>Heh. /All/ C should be multi-platform, if the programmer is paying
>attention to the relevant standards.[/color]

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Alan Balmer]

Re: C to Java Byte Code

On 14 Oct 2004 20:32:39 -0700, napi@axiomsol.c om (napi) wrote:
[color=blue]
>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.[/color]

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/
[color=blue]
> 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[/color]

Why is it restricted to Linux only?

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Daniel Fischer]

Re: C to Java Byte Code

Alan Balmer wrote:
[color=blue][color=green]
>>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.
>>[/color]
> Not the same thing. This is the Microsoft .NET approach (which some
> people also think is stupid.)[/color]

Incidentally, portable.net includes a C compiler which generates .NET
executables...




Daniel

[goose]

Re: C to Java Byte Code

napi wrote:
[color=blue]
> I think you would agree with me[/color]

Are you mad?

<snipped>

goose,

[Ioannis Vranos]

Re: C to Java Byte Code

napi wrote:[color=blue]
> 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[/color]


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

[John Bode]

Re: C to Java Byte Code

napi@axiomsol.c om (napi) wrote in message news:<a9083a87. 0410141932.589c 5eb5@posting.go ogle.com>...[color=blue]
> 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.[/color]

Alternately, one could bite the bullet and, you know, learn Java for
new development*.
[color=blue]
> Also, old programs (with some tweaking) could be re-compiled and ported
> to the JVM.[/color]

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.
[color=blue]
> 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[/color]

* "Java sucks" is not an excuse.

[Brian Alliet]

Re: C to Java Byte Code

Alan Balmer <albalmer@att.n et> wrote:[color=blue]
> 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/[/color]

<shameless plug>
There is also NestedVM (http://nestedvm.ibex.org/, but unfortunately
we don't really have a website for it yet). You can read about it in
our IVME paper at http://www.megacz.com/research/paper...dvm.ivme04.pdf

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>

-Brian

[Adam Megacz]

Re: C to Java Byte Code


brian@brianweb. net (Brian Alliet) writes:[color=blue]
> 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>[/color]

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 megacz@gmail.co m. Thanks!

[napi]

Re: C to Java Byte Code

john_bode@my-deja.com (John Bode) wrote in message news:<43618c0e. 0410151155.5313 a302@posting.go ogle.com>...[color=blue]
> napi@axiomsol.c om (napi) wrote in message news:<a9083a87. 0410141932.589c 5eb5@posting.go ogle.com>...[color=green]
> > 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.[/color]
>
> Alternately, one could bite the bullet and, you know, learn Java for
> new development*.
>[color=green]
> > Also, old programs (with some tweaking) could be re-compiled and ported
> > to the JVM.[/color]
>
> 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.[/color]

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

[Mohd Hanafiah Abdullah]

Re: C to Java Byte Code

In article <43618c0e.04101 51155.5313a302@ posting.google. com>,
John Bode <john_bode@my-deja.com> wrote:[color=blue]
>napi@axiomsol. com (napi) wrote in message
>news:<a9083a87 .0410141932.589 c5eb5@posting.g oogle.com>...[color=green]
>> 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.[/color]
>
>Alternately, one could bite the bullet and, you know, learn Java for
>new development*.[/color]

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..
[color=blue][color=green]
>> Also, old programs (with some tweaking) could be re-compiled and ported
>> to the JVM.[/color]
>
>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.[/color]

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.
[color=blue][color=green]
>> 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[/color]
>
>* "Java sucks" is not an excuse.[/color]

I think it's just a matter of preference.

Napi

--

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

[Paul Lutus]

Re: C to Java Byte Code

Mohd Hanafiah Abdullah wrote:
[color=blue]
> In article <43618c0e.04101 51155.5313a302@ posting.google. com>,
> John Bode <john_bode@my-deja.com> wrote:[color=green]
>>napi@axiomsol .com (napi) wrote in message
>>news:<a9083a8 7.0410141932.58 9c5eb5@posting. google.com>...[color=darkred]
>>> 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.[/color]
>>
>>Alternately , one could bite the bullet and, you know, learn Java for
>>new development*.[/color]
>
> 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..[/color]

You know, Mr. Abdullah, it would serve the truth better if you explained
what your product cannot do, and if you tried to avoid a marked tendency to
replace candor with marketing hype.
[color=blue]
>[color=green][color=darkred]
>>> Also, old programs (with some tweaking) could be re-compiled and ported
>>> to the JVM.[/color]
>>
>>That's certainly an interesting idea.[/color][/color]

And it's false. If, as has been revealed, C programs that use byte indexing
and addressing have to be substantially rewritten to accommodate this
product, how does the above "tweaking" remark accurately describe this
requirement?
[color=blue][color=green]
>>
>>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.[/color]
>
> 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.
>[color=green][color=darkred]
>>> 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[/color][/color][/color]

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

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

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

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

--
Paul Lutus

http://www.arachnoid.com

[Gerry Quinn]

Re: C to Java Byte Code

In article <10npbpmkjaqdqa 3@corp.supernew s.com>, nospam@nosite.z zz
says...[color=blue]
> Mohd Hanafiah Abdullah wrote:[/color]
[color=blue][color=green][color=darkred]
> >>> Also, old programs (with some tweaking) could be re-compiled and ported
> >>> to the JVM.
> >>
> >>That's certainly an interesting idea.[/color][/color]
>
> And it's false. If, as has been revealed, C programs that use byte indexing
> and addressing have to be substantially rewritten to accommodate this
> product, how does the above "tweaking" remark accurately describe this
> requirement?[/color]

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