6 ms·

Because there is no sensible mapping from, like, C source to the JVM. C expresses semantics that are not available on the JVM, like most casts, and the JVM is b

Because there is no sensible mapping from, like, C source to the JVM. C expresses semantics that are not available on the JVM, like most casts, and the JVM is built around concepts that don't exist in C or Fortran, like objects and method dispatch. They do exist to some extent in C++ but the semantics, memory model, etc, are completely different. Someone could make up a mapping but it would be a numerological exercise, a flight of fancy forever lacking utility. And anyway there is a practical integration between C and Fortran world and JVM world. The JVM can link to compiled C and Fortran object code, and for those who like suffering, JVM structures can be reached from C source.

warrenm 3y ago
>Because there is no sensible mapping from, like, C source to the JVM Really? C is available on so many hardware sets ... it's practically universal (Arduino, x86, MIPS, 68k, PowerPC, ARM, SPARC, RISCV...) I find it incredibly hard to believe that you couldn't target the JVM (which also runs on SPARC, ARM, RISCV, x86, POWER...) with C as the source language!
- MagicMoonlight 3y ago
  You could… but why would you want to? C can’t use any of the Java features so you’d just be adding pointless inefficiencies
- bastawhiz 3y ago
  The architectures that the code runs on has no bearing on whether it makes sense. What, for instance, do you turn a malloc() call for a number of bytes into? The JVM manages your memory for you and assumes you don't do it yourself. There are no instructions for telling the JVM how to manually fiddle with raw memory. And why would you want that? You already have code that expresses how to fiddle with the memory! The JVM provides functionality that C code already implements manually itself.
  - warrenm 3y ago
    The JVM knows how to handle memory (to some greater or lesser degree ... hence Xmin/Xmax) - https://antipaucity.com/2011/08/08/why-technical-intricacies-matter https://antipaucity.com/2011/08/08/why-technical-intricacies...
    - bastawhiz 3y ago
      That's the point. The JVM deals with objects. Classes. It has a garage collector. You can't make that work (at least not without a huge amount of effort) with a language whose code doesn't have a concept of those things. The abstraction the JVM implements isn't useful to C code.
      - kaba0 3y ago
        That’s nonsense. Ad absurdum every Turing-complete language can emulate every other. And in this particular case it is not even particularly complex.
        deleted 3y ago
        [deleted]
        goatlover 3y ago
        The point is that emulating the JVM abstraction isn't useful to C programmers. Just because it can be done in theory doesn't mean it's practical.
    - w7 3y ago
      I don't think they said otherwise. I believe the point was that JVM bytecode doesn't expose anything for manual memory deallocation at runtime.
      - warrenm 3y ago
        would seem trivial to map free() to a garbage collector call ...
- whizzter 3y ago
  There has been multiple C compilers targetting the JVM, however they've all also had bad performance penalties since the JVM has no notion of references and pointers so it becomes "emulated", best case you write one that works on ByteBuffer objects (Like early Asm.JS before WASM used a WebGL TypedArray objects before they became part of JavaScript proper) but once you go that route it becomes frustrating to interface with the rest of the Java ecosystem (and you kinda loose the entire point of a JVM targeting C compiler). Even Sun/Oracle recognized the mismatch and that's why GraalVM is a thing (and why Graal isn't entirely meshable with classic Java runtimes even if I hope they have a merge-strategy for the long-term).
  - warrenm 3y ago
    Java understands "references" and "pointers" (or, at least did in the 1.6 (and before) era...does it not any more?)
    - Someone 3y ago
      Java doesn’t have pointers in the C sense. Code such as while(*dst++=*src++); or char buf[100]; char *p = buf+13; p[-3] = p[1]; doesn’t map well to the JVM. As others said, you’d have to (almost) emulate memory in a byte array or byte buffer to fully support C.
    - Thiez 3y ago
      Not like C. They are not comparable. You get a reference to something you allocate on the heap, and you can have primitives on the stack. But you cannot take a reference to a primitive, or a reference to another reference, or a reference to the second element of an array. To run C on the JVM you are really swimming uphill.
      - kaba0 3y ago
        You see &variable in a function body, you allocate a stackframe for that in the heap abstraction and return that’s address.
- talkingtab 3y ago
  The "mapping" is from concept to concept. For example if there is no concept of collective objects in a spoken language- no way to talk about books for example only a book. Then mapping "we (plural) like books on all subjects" gets to be very hard. The hardware (people) is the same but the conceptual frame works are just too different. Not sure if that was what you were talking about...
- lloydatkinson 3y ago
  Arduino is not a chip. It's either AVR or ARM depending on which Arduino board you buy.
- lolinder 3y ago
  You're making the mistake of assuming transitivity in targets—because C targets all these architectures and the JVM runs on all these architectures, therefore C should target the JVM. The whole point of the JVM is to abstract away the underlying machine, so which architectures it runs on is irrelevant to whether its instruction set is a good semantic fit for C! I can write a Lisp to target any of those architectures as well, but I wouldn't suggest you should compile C to it. The big problem is that C assumes a low-level target language, which all these architectures provide but the JVM does not. A C runtime on the JVM would have to re-implement things like direct memory access on top of JVM arrays, which, while possible, would introduce performance penalties that would completely negate the purpose of writing C.
kaba0 3y ago
That’s absolutely not true. C only needs a huge array, and you can do anything you want with that in any language. That’s pretty much what WASM does as well. I’m sure there are some other ways as well, but a supported one is through the Graal project, which can run LLVM bitcode (and thus any of C, C++, Rust, etc) natively. Hell, it can interop with regular Java code, or that of other Truffle languages, and even optimize across language barriers!
- cultofmetatron 3y ago
  while technically true in the sense that any turing machine can simulate another turing machine, it probably wouldn't be efficient enough to be worth it.
- w7 3y ago
  Yes, but at that point you've implemented abstractions on the JVM's abstractions, or used platform/implementation dependent code. What's the point, just to say you did it? It's not impossible, it's just not worth the ROI time wise for most people with the desire to make a C/C++ standard compliant compiler to do so-- and even if they do, the amount of traction it'll gain will be minimal because developers can make an educated choice not to use it when native C/C++ compilers are available, or alternative JVM languages like Kotlin. Which is why you have a bunch of attempts at this that stopped development in 2009/2015.
- goatlover 3y ago
  What would be the point of doing that?
kjeetgill 3y ago
I don't know if it counts, but you could compile it down to llvm bitcode and run it on sulong as a part of graalvm. I imagine it comes with caveats but it's used for real stuff.

warrenm 3y ago

>Because there is no sensible mapping from, like, C source to the JVM Really? C is available on so many hardware sets ... it's practically universal (Arduino, x86, MIPS, 68k, PowerPC, ARM, SPARC, RISCV...) I find it incredibly hard to believe that you couldn't target the JVM (which also runs on SPARC, ARM, RISCV, x86, POWER...) with C as the source language!

MagicMoonlight 3y ago
You could… but why would you want to? C can’t use any of the Java features so you’d just be adding pointless inefficiencies
bastawhiz 3y ago
The architectures that the code runs on has no bearing on whether it makes sense. What, for instance, do you turn a malloc() call for a number of bytes into? The JVM manages your memory for you and assumes you don't do it yourself. There are no instructions for telling the JVM how to manually fiddle with raw memory. And why would you want that? You already have code that expresses how to fiddle with the memory! The JVM provides functionality that C code already implements manually itself.
- warrenm 3y ago
  The JVM knows how to handle memory (to some greater or lesser degree ... hence Xmin/Xmax) - https://antipaucity.com/2011/08/08/why-technical-intricacies-matter https://antipaucity.com/2011/08/08/why-technical-intricacies...
  - bastawhiz 3y ago
    That's the point. The JVM deals with objects. Classes. It has a garage collector. You can't make that work (at least not without a huge amount of effort) with a language whose code doesn't have a concept of those things. The abstraction the JVM implements isn't useful to C code.
    - kaba0 3y ago
      That’s nonsense. Ad absurdum every Turing-complete language can emulate every other. And in this particular case it is not even particularly complex.
      - deleted 3y ago
        [deleted]
      - goatlover 3y ago
        The point is that emulating the JVM abstraction isn't useful to C programmers. Just because it can be done in theory doesn't mean it's practical.
  - w7 3y ago
    I don't think they said otherwise. I believe the point was that JVM bytecode doesn't expose anything for manual memory deallocation at runtime.
    - warrenm 3y ago
      would seem trivial to map free() to a garbage collector call ...
whizzter 3y ago
There has been multiple C compilers targetting the JVM, however they've all also had bad performance penalties since the JVM has no notion of references and pointers so it becomes "emulated", best case you write one that works on ByteBuffer objects (Like early Asm.JS before WASM used a WebGL TypedArray objects before they became part of JavaScript proper) but once you go that route it becomes frustrating to interface with the rest of the Java ecosystem (and you kinda loose the entire point of a JVM targeting C compiler). Even Sun/Oracle recognized the mismatch and that's why GraalVM is a thing (and why Graal isn't entirely meshable with classic Java runtimes even if I hope they have a merge-strategy for the long-term).
- warrenm 3y ago
  Java understands "references" and "pointers" (or, at least did in the 1.6 (and before) era...does it not any more?)
  - Someone 3y ago
    Java doesn’t have pointers in the C sense. Code such as while(*dst++=*src++); or char buf[100]; char *p = buf+13; p[-3] = p[1]; doesn’t map well to the JVM. As others said, you’d have to (almost) emulate memory in a byte array or byte buffer to fully support C.
  - Thiez 3y ago
    Not like C. They are not comparable. You get a reference to something you allocate on the heap, and you can have primitives on the stack. But you cannot take a reference to a primitive, or a reference to another reference, or a reference to the second element of an array. To run C on the JVM you are really swimming uphill.
    - kaba0 3y ago
      You see &variable in a function body, you allocate a stackframe for that in the heap abstraction and return that’s address.
talkingtab 3y ago
The "mapping" is from concept to concept. For example if there is no concept of collective objects in a spoken language- no way to talk about books for example only a book. Then mapping "we (plural) like books on all subjects" gets to be very hard. The hardware (people) is the same but the conceptual frame works are just too different. Not sure if that was what you were talking about...
lloydatkinson 3y ago
Arduino is not a chip. It's either AVR or ARM depending on which Arduino board you buy.
lolinder 3y ago
You're making the mistake of assuming transitivity in targets—because C targets all these architectures and the JVM runs on all these architectures, therefore C should target the JVM. The whole point of the JVM is to abstract away the underlying machine, so which architectures it runs on is irrelevant to whether its instruction set is a good semantic fit for C! I can write a Lisp to target any of those architectures as well, but I wouldn't suggest you should compile C to it. The big problem is that C assumes a low-level target language, which all these architectures provide but the JVM does not. A C runtime on the JVM would have to re-implement things like direct memory access on top of JVM arrays, which, while possible, would introduce performance penalties that would completely negate the purpose of writing C.

kaba0 3y ago

That’s absolutely not true. C only needs a huge array, and you can do anything you want with that in any language. That’s pretty much what WASM does as well. I’m sure there are some other ways as well, but a supported one is through the Graal project, which can run LLVM bitcode (and thus any of C, C++, Rust, etc) natively. Hell, it can interop with regular Java code, or that of other Truffle languages, and even optimize across language barriers!

cultofmetatron 3y ago
while technically true in the sense that any turing machine can simulate another turing machine, it probably wouldn't be efficient enough to be worth it.
w7 3y ago
Yes, but at that point you've implemented abstractions on the JVM's abstractions, or used platform/implementation dependent code. What's the point, just to say you did it? It's not impossible, it's just not worth the ROI time wise for most people with the desire to make a C/C++ standard compliant compiler to do so-- and even if they do, the amount of traction it'll gain will be minimal because developers can make an educated choice not to use it when native C/C++ compilers are available, or alternative JVM languages like Kotlin. Which is why you have a bunch of attempts at this that stopped development in 2009/2015.
goatlover 3y ago
What would be the point of doing that?

kjeetgill 3y ago

I don't know if it counts, but you could compile it down to llvm bitcode and run it on sulong as a part of graalvm. I imagine it comes with caveats but it's used for real stuff.