4 ms·

I've actually found CIL to be simpler than JVM bytecode, even with additional capabilities. Simple addition is a good example: JVM: dadd, fadd, iadd, ladd. Add

I've actually found CIL to be simpler than JVM bytecode, even with additional capabilities. Simple addition is a good example: JVM: dadd, fadd, iadd, ladd. Addition for double, float, int, and long data, respectively. CIL: add, add.ovf, add.ovf.un. Addition, signed addition with overflow check, and unsigned addition with overflow check.

kodfodrasz 9y ago
I also prefer the CIL and also the C# language to Java (though I really like Java and its ecosystem), but we have to admit that MS had 5-10 years to learn from the Java design decisions and their effects, and still did not manage to overcome every problematic point :)
- pjmlp 9y ago
  They also had difference purposes driving their design, and we should not forget that. JVM - Bytecodes only for Java CIL - Bytecodes for VB.NET, C#, Managed C++ and the 1.0 SDK contained examples for Lisp, Pascal, Eiffel, Ada, .... Of course, history then took another path for the JVM. EDIT: Forgot that C++/CLI replaced Managed C++, which was the C++ variant on 1.0.
  - shellac 9y ago
    > JVM - Bytecodes only for Java Although it should be mentioned that java language semantics are largely (depending on how you measure them :-) absent from the jvm. (Default methods were a very unusual change in that respect) And, as you say, subsequent history has weirdly inverted the JVM and CIL. The former is a lot less 'J' and the latter is a lot less 'C' ;-)
    - cwyers 9y ago
      I would bet that there's a lot higher rate of .NET users running VB.NET than there are JVM users running Scala/Clojure/Kotlin. They just don't tend to be the sort to post to Hacker News.
      - readittwice 9y ago
        Although this might really be true, I am skeptical that this has something to do with the inherent design of the Java bytecode compared to the CIL.
      - shellac 9y ago
        But there are probably more CPUs running non-java JVM languages ;-) It all depends what you count, as usual. (I was really referring to the healthy non-java jvm language community. JRuby, Scala, and Clojure have lively communities and commercial backing)
bad_user 9y ago
Those bytecodes happened because the JVM bytecode was designed to be easily interpreted, whereas CIL was designed for JIT compilation. So for example CIL's `add` opcode is missing info that needs to come from the context in which it is used and the JVM's `iadd` and variations are easier to interpret. You can see this design choice even today in how the JVM and CLR work. The JVM starts execution in an interpreter mode, then gradually compiles pieces of code as it detects bottlenecks. So the compilation that happens at runtime is very gradual and based on runtime measurements. The CLR on the other hand has done JIT compilation, with the ability to cache the compiled code for faster startup (e.g. Ngen). So it has been oriented towards ahead of time compilation. Different trade-offs.
- jdmichal 9y ago
  Sure. I tried to find information yesterday when I posted that regarding whether / how the `add` code handles differing types. Now since I'm not on my phone, I looked up the ECMA spec and it looks like CIL still only allows like types, with some minor exceptions involving `native int`. So it's just up to the compiler to make sure that actually happens and extend types as necessary.

kodfodrasz 9y ago

I also prefer the CIL and also the C# language to Java (though I really like Java and its ecosystem), but we have to admit that MS had 5-10 years to learn from the Java design decisions and their effects, and still did not manage to overcome every problematic point :)

pjmlp 9y ago
They also had difference purposes driving their design, and we should not forget that. JVM - Bytecodes only for Java CIL - Bytecodes for VB.NET, C#, Managed C++ and the 1.0 SDK contained examples for Lisp, Pascal, Eiffel, Ada, .... Of course, history then took another path for the JVM. EDIT: Forgot that C++/CLI replaced Managed C++, which was the C++ variant on 1.0.
- shellac 9y ago
  > JVM - Bytecodes only for Java Although it should be mentioned that java language semantics are largely (depending on how you measure them :-) absent from the jvm. (Default methods were a very unusual change in that respect) And, as you say, subsequent history has weirdly inverted the JVM and CIL. The former is a lot less 'J' and the latter is a lot less 'C' ;-)
  - cwyers 9y ago
    I would bet that there's a lot higher rate of .NET users running VB.NET than there are JVM users running Scala/Clojure/Kotlin. They just don't tend to be the sort to post to Hacker News.
    - readittwice 9y ago
      Although this might really be true, I am skeptical that this has something to do with the inherent design of the Java bytecode compared to the CIL.
    - shellac 9y ago
      But there are probably more CPUs running non-java JVM languages ;-) It all depends what you count, as usual. (I was really referring to the healthy non-java jvm language community. JRuby, Scala, and Clojure have lively communities and commercial backing)

bad_user 9y ago

Those bytecodes happened because the JVM bytecode was designed to be easily interpreted, whereas CIL was designed for JIT compilation. So for example CIL's `add` opcode is missing info that needs to come from the context in which it is used and the JVM's `iadd` and variations are easier to interpret. You can see this design choice even today in how the JVM and CLR work. The JVM starts execution in an interpreter mode, then gradually compiles pieces of code as it detects bottlenecks. So the compilation that happens at runtime is very gradual and based on runtime measurements. The CLR on the other hand has done JIT compilation, with the ability to cache the compiled code for faster startup (e.g. Ngen). So it has been oriented towards ahead of time compilation. Different trade-offs.

jdmichal 9y ago
Sure. I tried to find information yesterday when I posted that regarding whether / how the `add` code handles differing types. Now since I'm not on my phone, I looked up the ECMA spec and it looks like CIL still only allows like types, with some minor exceptions involving `native int`. So it's just up to the compiler to make sure that actually happens and extend types as necessary.