Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Subject: C to JVM compiler (AMPC)

Reply
Thread Tools

Subject: C to JVM compiler (AMPC)

 
 
Brandon J. Van Every
Guest
Posts: n/a
 
      05-15-2005
Ioannis Vranos wrote:

>
> Regarding C things should be even more difficult since it lacks the
> built-in concept of OO, I can't understand how C programs can interact
> with the JVM APIs. Unless you can't do anything else under JVM apart
> from ISO C code, which doesn't make much sense


Sure it does. The product is aimed at the embedded market. A lot of
that "other Java stuff" is not needed. Customers may also wish to
bridge legacy code from C to the JVM, given that Java is also used in
the embedded market. I think the problem here is you're envisioning
some kind of "do everything a Java applications developer would want to
do" sort of package, which is what actually doesn't make sense. The
target audience is embedded C developers, who want to retarget their
code to the JVM.

> and which is not possible under its entirety (GC is moving objects
> around and thus you can't rely on pointer arithmetic, or compare two
> pointers to see if they point to the same object (memory area),
> memmove etc.


Well, it would be interesting to see what subset of C possibility the
JVM could support. Those are intelligent questions for the vendor, if
you're interested.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"We live in a world of very bright people building
crappy software with total **** for tools and process."
- Ed McKenzie
 
Reply With Quote
 
 
 
 
Brandon J. Van Every
Guest
Posts: n/a
 
      05-15-2005
Keith Thompson wrote:

>
>According to the initial description, it's not a C --> Java compiler,
>it's a C --> Java Bytecode compiler. Java is a high-level language; a
>C --> Java compiler would generate Java source code from C source
>code.
>
>

Eh, semantics. Java, bytecode, whatever. The point is, it goes C
Universe --> Java Universe, and not in the other direction. This
implies certain usage patterns and not others.

> It's entirely possible to compile
>languages other than Java to Java bytecode (for example, there's at
>least one Ada compiler that generates Java bytecode).
>

Indeed the Bigloo and Kawa Scheme compilers can produce Java bytecode.
I'm not sure how well. The Eclipse Schemeway plugin developer is big
into Kawa though. http://schemeway.sourceforge.net/

>C presents some interesting challenges, because its freewheeling use
>of pointers is difficult to express in Java bytecode. I suspect that
>a lot of constructs that invoke undefined behavior but happen to work
>perfectly well with a traditional C compiler will actually fail with a
>C --> JVM compiler. That's probably a good thing; it provides a way
>to weed out non-portable constructs in C code that's intended to be
>portable.
>

Sure, and as an aide de port it may be a valid business model.

> Perhaps the C --> JVM compiler can serve the purpose of the
>DS9000 (a mythical machine with a C implementation that behaves as
>perversely as possible without actually violating the standard).
>
>

Is DS9000 an acronym? Any relation to HAL9000?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"We live in a world of very bright people building
crappy software with total **** for tools and process."
- Ed McKenzie
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-15-2005
"Brandon J. Van Every" <(E-Mail Removed)> writes:
> Keith Thompson wrote:

[...]
>> Perhaps the C --> JVM compiler can serve the purpose of the
>>DS9000 (a mythical machine with a C implementation that behaves as
>>perversely as possible without actually violating the standard).
>>
>>

> Is DS9000 an acronym? Any relation to HAL9000?


DS stands for DeathStation. The 9000 was probably inspired by HAL.

It goes along with the idea that a permitted consequence of undefined
behavior in C is that the implementation makes demons fly out your
nose (often abbreviated to "nasal demons").

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Ed Jensen
Guest
Posts: n/a
 
      05-15-2005
In comp.lang.c++ Mohd Hanafiah Abdullah <(E-Mail Removed)> wrote:
> AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
> (generates Java Bytecode).


I wonder if this, combined with the Comeau compiler, would allow one
to run C++ programs on a JVM?

C++ source -> Comeau -> C source -> AMPC -> JVM
 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      05-15-2005
Mohd Hanafiah Abdullah wrote:

> AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
> (generates Java Bytecode). The resulting .class executables will be
> able to run on any Java Virtual Machine (tm). AMPC enables programmers
> to write/port applications using C targeting the JVM, thus, opening up a
> whole new market dimension vis-a-vis JVM-enabled devices such as desktop
> systems, PDAs, cell-phones, game consoles, set-top boxes, automotive systems
> (GPS based displays, OnStar, Satellite radio systems, etc), and so forth.
> AMPC can also be used to turn legacy applications written in C
> into JVM applications, with a single source base to manage.
> Use existing C skill sets instead of learning new Java skill sets.


This is, of course, a great idea.
Have you got customers?
A user base?
 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      05-15-2005
Brandon J. Van Every wrote:

> Is DS9000 an acronym? Any relation to HAL9000?



A DS9000 is a comp.lang.c imaginary machine, that you do not want to write code with
undefined behaviour and run on it.


I just searched google to find out who thought it up, and the interesting thing is that
there are a few real DS 9000 machines:

http://groups.google.com/groups?q=%2...uwm.edu&rnum=1

http://groups.google.com/groups?q=%2...tel.com&rnum=6


I found who thought it, and he explains some of its naming:

http://groups.google.com/groups?hl=e...FootPrints.net


--
Ioannis Vranos

http://www23.brinkster.com/noicys
 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      05-15-2005
Malcolm wrote:

> The program takes as input the text
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("Hello world\n);
> return 0;
> }
>
> The C to JVM compiler then creates a class called something (probably based
> on the name of the C source file)
>
> class hello_c
> {
> static void main()
> {
> system.out.println("Hello world");
> }
> }
>
> It has the intelligence to know that the call to printf() can be relaced by
> a call to System.out.println() if you remove the trailing newline.
>
> This file then gets fed to a Java complier, which produces a Java .class
> file.
>
> In practise it wouldn't bother creating an intermediate human-readable Java
> file and the Java compiler would be integrated into the C to JVM compiler.
> But that's just a detail. Also it would have to generate lots of fancy Java
> code to handle more complicated printf() calls.



Yes, C and any language can be used to produce java bytecode. I had two misconceptions.
The first that it somehow enabled the developer to access the OO API of JVM directly, and
secondly that it was aimed to PCs and not toward to embedded devices only.


The answer to the first is that they created a procedural API and the second is embedded
devices of course and thus a smaller pain than what it would be to wrap the entire JVM API
to procedural. It is something like the case of .NET framework vs .NET compact framework.
Still the wrapping must have been a pain, unless they have not wrapped everything.


In any case, it can be done. However I imagine (since I do not know JVM API), mapping all
C structures, libraries and abilities to JVM bytecode, can't be that easy or even
possible, when we are talking about *maintaining the C semantics*.


Anyway, I am not personally interested in JVM.



--
Ioannis Vranos

http://www23.brinkster.com/noicys
 
Reply With Quote
 
Mohd Hanafiah Abdullah
Guest
Posts: n/a
 
      05-15-2005
In article <d66e59$4ok$(E-Mail Removed)>,
E. Robert Tisdale <(E-Mail Removed)> wrote:
>Mohd Hanafiah Abdullah wrote:
>
>> AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
>> (generates Java Bytecode). The resulting .class executables will be
>> able to run on any Java Virtual Machine (tm). AMPC enables programmers
>> to write/port applications using C targeting the JVM, thus, opening up a
>> whole new market dimension vis-a-vis JVM-enabled devices such as desktop
>> systems, PDAs, cell-phones, game consoles, set-top boxes, automotive systems
>> (GPS based displays, OnStar, Satellite radio systems, etc), and so forth.
>> AMPC can also be used to turn legacy applications written in C
>> into JVM applications, with a single source base to manage.
>> Use existing C skill sets instead of learning new Java skill sets.

>
>This is, of course, a great idea.
>Have you got customers?
>A user base?


It's a relatively new product which has gone through the beta period and
we are marketing it. Beside being downloaded for free for the last 6 months,
we have interests from Telekom Malaysia's R&D and Universiti Teknologi
Petronas here in Malaysia.

Napi
--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html
 
Reply With Quote
 
Brandon J. Van Every
Guest
Posts: n/a
 
      05-15-2005
Ioannis Vranos wrote:

> I found who thought it, and he explains some of its naming:
>
> http://groups.google.com/groups?hl=e...FootPrints.net
>


Ouch. As an ex-DEC employee, that hurts! Well, some of the DEC Alpha
workstations were great, and others were pieces of junk. Some idiot
decided to ship a 533 MHz machine without much of anything in the way of
memory cache. I forget when this super cheapass memory controller was
supposed to actually be justifiable / not harmful, but talk about
pigeonholeing the applicability of your hardware! We had a 533 MHz box
like that in our lab, and it was regularly getting whipped by our 300
MHz machines that had proper caches. We nicknamed the sucker "the Yugo"
and put a photo of that ignoble automobile on it as the desktop background.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA


 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      05-15-2005
Brandon J. Van Every wrote:

> Ouch. As an ex-DEC employee, that hurts! Well, some of the DEC Alpha
> workstations were great, and others were pieces of junk. Some idiot
> decided to ship a 533 MHz machine without much of anything in the way of
> memory cache. I forget when this super cheapass memory controller was
> supposed to actually be justifiable / not harmful, but talk about
> pigeonholeing the applicability of your hardware! We had a 533 MHz box
> like that in our lab, and it was regularly getting whipped by our 300
> MHz machines that had proper caches. We nicknamed the sucker "the Yugo"
> and put a photo of that ignoble automobile on it as the desktop background.



Interesting. This also makes his explanation more clear.



--
Ioannis Vranos

http://www23.brinkster.com/noicys
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Subject: C to JVM compiler (AMPC) Mohd Hanafiah Abdullah C++ 25 05-17-2005 07:47 AM
MS JVM and Sun JVM problem Young-Jin Lee Java 3 01-21-2004 04:25 AM
Different behavior for newStringUTF() for Sun JVM and IBM Jvm Lasse Java 1 01-05-2004 07:49 PM
Re: Handling both MS JVM and Sun JVM Kevin Hooke Java 2 09-02-2003 05:31 AM
java compiler in JVM Wats Java 7 07-17-2003 02:23 AM



Advertisments