Axiomatic Multi-Platform C generates Java bytecode from C source

Discussions

News: Axiomatic Multi-Platform C generates Java bytecode from C source

  1. Axiomatic Solutions has a product called AMPC (Axiomatic Multi-Platform C) that generates Java bytecode from C source code. It claims to support a "very large subset" of C89, with no bit field support, limited support for double types (which are java floats), different fork() semantics, and addressable memory is represented as a large array of ints.

    Specifically, from the installation notes:
    The AMPC (Axiomatic Multi-Platform C) compiler/IDE tries to follow the ANSI C (1989) standard as closely as possible, but it is yet to be fully compliant. Although it is not pure ANSI C (1989), it supports a very large subset of the standard. The JVM architecture has no built-in addressable memory architecture, hence, we resort to using one large array of int as a substitute for addressable memory. We minimize referencing the large array of int when referencing local variables by means of a register allocation technique based on the priority based graph coloring algorithm, utilizing JVM's local variables as "registers". This results in faster executables somewhat.

    Each address location of the monolithic memory architecture takes up 32-bit space. So, the memory space is 4-bytes-addessable (word-addressable) and not byte-addressable. Consequently, all scalar data types are 4 bytes long and they are int, char, float, and double.
    If the compiler supports C well enough, one can easily imagine object libraries from the vast C source code repositories finding their way into Java programs, broadly extending Java's reach.

    The compiler suite sells for $99USD, with a demo version being available from Download.com.

    What do you think of this? Could a compiler like this be used to retarget source for scripting languages such as Perl, PHP, or Ruby into Java bytecode? Would this even be useful?

    Threaded Messages (19)

  2. Interesting idea[ Go to top ]

    This looks like a pretty good idea for porting subsets of legacy code. Two main points that I'm curious about:

    1. How well does it handle substantial projects (things like libc and uclibc)? Does it then require a special support library?

    2. If we end up with bytecode - why not go all the way and produce Java code from that? (as we have the C source, var names and comments could be preserved)

    The price isn't bad, but more in-depth documentation is really needed before taking a plunge (will be taking a look at the demo as well!)
  3. Interesting idea[ Go to top ]

    See nestedvm. It works OK for simple programs, in particular normal libraries. If you try to compile something like Kaffe, Mono, or Ruby with it, though, you'll run into a world of pain, since such runtime engines tend to be much closer to the system, and have to support OS-specific functionality, like FFIs, which kills the idea [1]. Been there, done that.

    cheers,
    dalibor topic

    [1] In case of FFIs, a uniform scalar representation kills the idea on OSes where scalars are non-uniform and your runtime engine provides facilities to interface with native code which uses a different ABI, think JNI & friends.
  4. Interesting idea[ Go to top ]

    On a side note, in my tests nestedvm compiled bytecode ended up running an order of magnitude faster on kaffe 1.1.6 than on sun's 1.4, since it is really hard to hot-spot optimize.

    cheers,
    dalibor topic
  5. Interesting idea[ Go to top ]

    The documentation on AMPC is available mostly in the
    directory: http://www.axiomsol.com/hedesu/kb/

    as well as a PDF file named UserManual-AMPC-Version-1.3-1.pdf
    in the directory http://www.axiomsol.com/hedesu/fm/

    Thanks.

    Napi
  6. How reliable is the conversion ?
    How to debug java errors - there is no java source code ?
    How to maintain the source goign forward ?
    How many of us will use it to convert a good size application using it ? Whats the confidance level ?
    And finally how do all of the above compare to rewriting the legacy system in java from scratch ?
  7. It is possible to debug using any text file in theory ( C source code in this case), but I do not know how this compiler generates debug info.
  8. How reliable is the conversion ?
    AMPC has been used to convert a large Telco app
    (200 C source files). AMPC has also been used to compile
    itself.

    >How to debug java errors - there is no java source code ?
    The debugger is still in Beta. Right now, the best way
    to debug is to use printf.

    >How to maintain the source goign forward ?
    Same as you would maintain any C project code.

    >How many of us will use it to convert a good size application using it ?

    >Whats the confidance level ?

    >And finally how do all of the above compare to rewriting the legacy system in java from scratch ?
    It depends on available skillsets and preferences for which
    labguage(s).
  9. Not really[ Go to top ]

    If the C code is portable enough to work well with AMPC it can probably be compiled for most platforms with minor tweaks anyway. I would use JNI. That retains the native performance of the C code and avoids many of the pitfalls (while of course adding others).

    There may be some cases where the product is useful, but I would rewrite the code in Java or wrap it with JNI if I had half a choice.
  10. Note that on the AMPC website, the goal of AMPC is to produce retargetable deployables, so that Java's WORA facility - such that it is - is also available for C as well.
  11. that sort of thing is interesting if you are deploying to a Microsoft 1.1 JVM, and want, for example, to have sane font rendering in applets, then you can 'crosscompile' libfreetype to bytecode, and deploy that.

    cheers,
    dalibor topic
  12. Is there a list of products and libraries ported to Axiomatic Multi-Platform C?

    Nebojsa
  13. The ANSI C (1989) libraries have been ported, as well as
    TCP/IP, ODBC, and event-driven graphic libraries. Telekom
    Malaysia uses AMPC to port their network forecasting application to the JVM. There are more than 200 source files in C that have been ported using AMPC for the application.

    The downloadable libraries as well as sample programs are available at:
    http://www.axiomsol.com/hedesu/fm/

    Thanks.

    Napi
  14. Hi

    That's an interesting news for me. I have build a COBOL compiler as an Eclipse plugin that generates also native JVM bytecodes...But, there is a need to relax some constraints on the JVM memory model for taking full advantage of the JVM address space and to add byte compare and byte move instructions for gaining performance...

    FA
  15. This is really a great effort. How you guys do handle pointers to be converted in java byte code? By doing this, you mean to say that we can convert the C code in java and can run on any platform that hold java VM. But there are many native platform specific calls available in C that do require only Microsoft Operating System. Any comments?
  16. AMPC is ANSI C (1989) compliant mostly. OS specific system calls will need to be modified according to the APIs that come with AMPC, that is if something functionally similar exists. This includes graphics APIs, TCP/IP APIs, ODBC APIs, etc.
  17. Support for buffer overflow?[ Go to top ]

    I wonder how this killer feature is going to be supported...
  18. I wonder how this killer feature is going to be supported...

    Buffer overflow may occur within the large array of int that makes up the addressable memory. The large array of int has been created using "newarray int" command and is confined within the JVM's sandbox. In other words, any buffer overflow
    occurrence is within the sandbox which I believe protects
    against external exploits targeting buffer overflows.
  19. If you have multiple security levels, a buffer overflow within this large array of ints may well allow someone with a low security level to view information meant for a higher security level. Any permissions that the C program-compiled-to-bytecode has (database access, file system access, etc.) may be assumed by an attacker in a poorly written program.

    OTOH, they probably don't load classes from the bug array of ints, so it is unlikely that you can overwrite code, or the return stack with a buffer overflow, so you would have to make the attack by trying to overwrite data structures.

    - Erwin
  20. Buffer overflow is a problem of c[ Go to top ]

    Buffer overflow is often caused by the Array bounds in c,but in rarely in java.see here http://www.developerzone.biz/index.php?option=com_content&task=view&id=154&Itemid=36