-1

Possible Duplicate:
Running/Interpreting C on top of the JVM?

By hybrid language I mean one that is compiled by a hybrid compiler (like Java). I understand it would be impracticable, because C is designed to be easily mapped to machine instructions, but I can't tell if there are any reasons why someone couldn't write a hybrid compiler for it.

Community
  • 1
  • 1
epaulson
  • 1

2 Answers2

0

C compilers exist for many architectures. Bytecode that Java uses probably can be simply viewed as just one more instruction set so why should not be possible? Probably pointers would not be a "real pointers" but some internal VM references.

Used to be a commercial compiler provided by axiomsol but all links to it appear dead (404) now.

Compiling C into Java code and then compiling Java is possible but many thinks seem really resolved in suboptimal way. With byte[], you even cannot read an integer in one go. C would probably benefit from its own virtual machine that would be simpler (as no garbage collector required). Or, at least, C must be compiled into bytecode directly. Who knows C well could look into the JamVM project that may provide an interesting start. It is a simple virtual machine to run Java bytecode.

Audrius Meškauskas
  • 20,936
  • 12
  • 75
  • 93
  • Indeed. Though doing it for JVM would probably require making C heap to be a Java `byte[]` array, and pointers would be indexes to this array. Also C variables in stack might need to be done with simulated `byte[]` stack too, since it must be possible to get a pointer to them (compatible with heap pointer). With direct Java refrences, it would be impossible to do pointer arithmetic and integer-pointer casts in C. So C compiled to Java bytecode would be very slow, as Java byte code can not do many C things "natively" with single byte code instructions. – hyde Jan 25 '13 at 07:41
  • @hyde, you should turn this into a separate answer. – s.bandara Jan 25 '13 at 07:48
  • @s.bandara I guess... did so. – hyde Jan 25 '13 at 07:57
0

Creating a custom virtual machine designed for running C would of course work, and work very well, with 1-1 mapping for many byte code instructions to real CPU instructions, and easy and fast JITing as a result too. Actually, LLVM for example is actually very much like this.

Doing C compiler targetting JVM would probably require making C heap to be a Java byte[] array, and pointers would be indexes to this array. Also C variables in stack might need to be done with simulated byte[] stack too, since it must be possible to get a pointer to them (compatible with heap pointer).

This is needed, because with direct Java refrences, it would be impossible to do pointer arithmetic and integer-pointer casts in C. One option to optimize this could be to make C char be 32 bits, which is allowed by C standard, but it would make that C implementation very awkward to use for processing for example text files, or anything really with byte data... Regardless, C compiled to Java bytecode would be very slow, as Java byte code can not do many C things "natively" with single byte code instructions.

hyde
  • 60,639
  • 21
  • 115
  • 176
  • If it was me implementing it, a C pointer would probably be represented by a combination of a reference to a `byte[]` array with an index within that array. That prevents the heap needing to be one massive array: you can use more than one, which means you can add more heap when required. You could still implement pointer -> integer casts and back, you just need to assign a distinct integer value to each array. Perhaps via some external map. – Steve Jessop Jan 25 '13 at 09:28
  • Oh, but actually `intptr_t` and `uintptr_t` are optional types. So you don't have to make integer -> pointer casts do anything worthwhile if you can't be bothered, you can just map all integer values to null pointers :-) Obviously this will break C code that relies on a 1-1 mapping between pointers and integers, but then that code isn't strictly conforming. – Steve Jessop Jan 25 '13 at 09:35