4 ms·

C is a heavyweight intermediary language which brings with it a /lot/ of baggage. There's no valid direct technical reason other than financial resource constra

by pbsdp 13y ago

C is a heavyweight intermediary language which brings with it a /lot/ of baggage. There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode. It's impossible to implement a variety of useful abstractions in portable C -- for example, function trampolines that do not permute register state and do not appear in the callstack after execution.

maaku 13y ago
Oh come now, there are good reasons to compile to JS if you are doing things in a browser.
- pbsdp 13y ago
  Not direct technical reasons, no. The only indirect technical justification is in maintaining compatibility with existing browsers, but that falls over pretty fast when you're a browser maker (Mozilla) and refusing to work with another browser maker (Google) on jumping over that compatibility hurdle.
  - mistercow 13y ago
    Can you explain specifically what you mean by a "direct" vs. an "indirect" technical reason?
    - pbsdp 13y ago
      Direct: Constraints/requirements directly related to implementing a maximally effecient runtime architecture. Indirect: Market constraints that drive technical limitations. When it comes to browsers, Mozilla both creates and exists within market constraints that drive indirect technical reasoning. Lashing your industry to JS for another 10 years as a bytecode target is clearly not an optimal long-term solution as compared to the current state of the art, but it might make sense as a legacy support mechanism given the indirect technical constraints.
      - azakai 13y ago
        > compared to the current state of the art What do you consider the current state of the art?
        pbsdp 13y ago
        JVM, CLR, Mono AOT complation, NaCL/PNaCL. A future in which we wind up with architectural support for NaCL-style sandboxing intrinsics, in the same way we saw them be developed for VT-(x|d). Sticking us with JS for another decade and expecting us to compete against better application runtimes? No.
        azakai 13y ago
        Those examples are all very different. What is your goal - speed? Code size? Portability? Security? Those examples don't all achieve those to the same degree, and I would argue that modern JS VMs are competitive with them in many respects.
        pbsdp 13y ago
        > What is your goal - speed? Code size? Portability? Security? That depends on the target. I selected them because they represent different aspects of the state of the art. > ... and I would argue that modern JS VMs are competitive with them in many respects But not all, and in many places, not even close. JS VMs make trade-offs that we don't need if we abandon JS, and on top of it all, you have Mozilla insisting against shared-state multi-threading supported and exposed by the VM, which discards enormously important optimization opportunities) -- and that's just the tip of the iceberg. Get rid of JS, get rid of Mozilla's self-enforced constraints on the browser, and look very seriously at something like NaCL which blends native execution performance (including being able to drop to SIMD instructions) with security sandboxing. Let language authors target the low-level machine, and target your high-level general purpose bytecode. Once you've built a runtime in which I could implement a JS runtime that's as performant as yours, we will no longer be operating in a two-tier universe in which browser makers think that JS is good enough for everyone but themselves.
  - marshray 13y ago
    "Maintaining compatibility with existing browsers" is like saying "emitting machine code for CPUs that actually exist".
    - pbsdp 13y ago
      Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture. It's a policy decision, not a technical decision.
      - gmac 13y ago
        Replacing JS may not be technically difficult, but practically it's extremely difficult (IE6, anyone?). Plus JS has got so fast, it's becoming hard to see the point anyway.
        pbsdp 13y ago
        > Plus JS has got so fast, it's becoming hard to see the point anyway. Native is faster. A lot faster. And that's what browser apps are competing against.
        klibertp 13y ago
        asm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
        rational_indian 13y ago
        Not fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
      - gnaritas 13y ago
        Getting your bytecode working in shipping in all browsers has proven to be impossible; there's a reason people compile to Javascript, it's the only practical choice.
mistercow 13y ago
>(... or JS, for that matter) I have to disagree with that. There are lots of languages whose purpose is to produce JS. For example, it would be very silly for CoffeeScript to use LLVM IR. It would end up reïmplementing all of the things that it shares with JS (that is, most of JS) with no conceivable benefit. Maybe if/when PNaCl is everywhere, it would make sense for it to do that, but even then it's a hard sell as long as four giant companies are competing their asses off to optimize JS. But I do agree with you if the language doesn't correspond well with JS. In that case, it's probably better to target LLVM and then compile to JS via emscripten.
gngeal 13y ago
There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode. How does one do call/cc in LLVM, or delimited continuations, for that matter?
- pbsdp 13y ago
  The same way you'd do it in any runtime? Adopt an adequate representation model of the machine state, and save that state.
  - gngeal 13y ago
    Why would I save "a representaion model" when I can simply save the process/thread state?
    - pbsdp 13y ago
      You can't do that in portable C as-is. Watch what happens when you try to restore thread state on a different system thread using an OS that instrisically ties system threads to user threads to thread local variables to the stack. And no, getcontext() and setcontext() aren't portable.
      - gngeal 13y ago
        Why would I care if it's portable or not? I've never understood the mentality of "but it's not portable". If something isn't not portable, you put #+ and #- on top of it. I'd rather go for "straight-forward and performant" than for some abstract code transformations to make it runnable on platforms that almost nobody uses to the detriment of everyone else. LLVM is the lowest common denominator. I'm really not fond of lowest common denominators. (Not to mention the fact that it's bloatware in the first place - it's about twice the size of my favourite compiler, and that's before you add the actual language you're trying to compile.)
        13y ago
azakai 13y ago
> C is a heavyweight intermediary language which brings with it a /lot/ of baggage. There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode. 1. In theory. But what is that "more suitable and expressive IR/bytecode"? I would argue such a bytecode should be portable, but LLVM IR is not that. 2. There are lots of reasons to target C. C can be compiled by many compilers, while LLVM IR can only be compiled by LLVM to things LLVM can compile to. For example, game consoles, various new embedded platforms, etc. - they all have C compilers, but LLVM might not support them (and possibly cannot support them).
- pbsdp 13y ago
  > 2. There are lots of reasons to target C. C can be compiled by many compilers, while LLVM IR can only be compiled by LLVM to things LLVM can compile to. For example, game consoles, various new embedded platforms, etc. - they all have C compilers, but LLVM might not support them (and possibly cannot support them). Is the point to produce something optimal for users, or produce something optimal for developers? Most successful game and application platforms trend towards the former, whereas your work on web technologies trends towards the latter.
  - nullc 13y ago
    Vendor lock-in isn't good for users either.
    - zxcdw 13y ago
      No, it is not. But what does it have to do with anything discussed here? I can't see IR being something which locks users or developers to a particular vendor.
- eliben 13y ago
  It's not difficult to restrict LLVM IR to a portable subset, though ;-)
- 13y ago
vidarh 13y ago
LLVM IR is less portable than C. That's a valid direct technical reason. Generating C (or another high level language) also makes integration with tools in that language potentially trivial (depending on the semantics of the language you're compiling), and depending on your preference you may find it far easier to debug the output. As for portability, while you're right that a number of things can't be implemented in portable C, you gain the benefit that C has been ported to far more systems than LLVM - there are C compilers even for the Commodore 64. I agree with you that C is heavyweight, but LLVM is too. Personally I prefer to build code generators directly - the LLVM infrastructure may be great, but I much prefer to write compiler that are self contained and bootstrapped in the language they are intended to compile. Then again I might just be difficult.

by pbsdp 13y ago

maaku 13y ago

Oh come now, there are good reasons to compile to JS if you are doing things in a browser.

pbsdp 13y ago
Not direct technical reasons, no. The only indirect technical justification is in maintaining compatibility with existing browsers, but that falls over pretty fast when you're a browser maker (Mozilla) and refusing to work with another browser maker (Google) on jumping over that compatibility hurdle.
- mistercow 13y ago
  Can you explain specifically what you mean by a "direct" vs. an "indirect" technical reason?
  - pbsdp 13y ago
    Direct: Constraints/requirements directly related to implementing a maximally effecient runtime architecture. Indirect: Market constraints that drive technical limitations. When it comes to browsers, Mozilla both creates and exists within market constraints that drive indirect technical reasoning. Lashing your industry to JS for another 10 years as a bytecode target is clearly not an optimal long-term solution as compared to the current state of the art, but it might make sense as a legacy support mechanism given the indirect technical constraints.
    - azakai 13y ago
      > compared to the current state of the art What do you consider the current state of the art?
      - pbsdp 13y ago
        JVM, CLR, Mono AOT complation, NaCL/PNaCL. A future in which we wind up with architectural support for NaCL-style sandboxing intrinsics, in the same way we saw them be developed for VT-(x|d). Sticking us with JS for another decade and expecting us to compete against better application runtimes? No.
        azakai 13y ago
        Those examples are all very different. What is your goal - speed? Code size? Portability? Security? Those examples don't all achieve those to the same degree, and I would argue that modern JS VMs are competitive with them in many respects.
        pbsdp 13y ago
        > What is your goal - speed? Code size? Portability? Security? That depends on the target. I selected them because they represent different aspects of the state of the art. > ... and I would argue that modern JS VMs are competitive with them in many respects But not all, and in many places, not even close. JS VMs make trade-offs that we don't need if we abandon JS, and on top of it all, you have Mozilla insisting against shared-state multi-threading supported and exposed by the VM, which discards enormously important optimization opportunities) -- and that's just the tip of the iceberg. Get rid of JS, get rid of Mozilla's self-enforced constraints on the browser, and look very seriously at something like NaCL which blends native execution performance (including being able to drop to SIMD instructions) with security sandboxing. Let language authors target the low-level machine, and target your high-level general purpose bytecode. Once you've built a runtime in which I could implement a JS runtime that's as performant as yours, we will no longer be operating in a two-tier universe in which browser makers think that JS is good enough for everyone but themselves.
- marshray 13y ago
  "Maintaining compatibility with existing browsers" is like saying "emitting machine code for CPUs that actually exist".
  - pbsdp 13y ago
    Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture. It's a policy decision, not a technical decision.
    - gmac 13y ago
      Replacing JS may not be technically difficult, but practically it's extremely difficult (IE6, anyone?). Plus JS has got so fast, it's becoming hard to see the point anyway.
      - pbsdp 13y ago
        > Plus JS has got so fast, it's becoming hard to see the point anyway. Native is faster. A lot faster. And that's what browser apps are competing against.
        klibertp 13y ago
        asm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
        rational_indian 13y ago
        Not fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
    - gnaritas 13y ago
      Getting your bytecode working in shipping in all browsers has proven to be impossible; there's a reason people compile to Javascript, it's the only practical choice.

mistercow 13y ago

>(... or JS, for that matter) I have to disagree with that. There are lots of languages whose purpose is to produce JS. For example, it would be very silly for CoffeeScript to use LLVM IR. It would end up reïmplementing all of the things that it shares with JS (that is, most of JS) with no conceivable benefit. Maybe if/when PNaCl is everywhere, it would make sense for it to do that, but even then it's a hard sell as long as four giant companies are competing their asses off to optimize JS. But I do agree with you if the language doesn't correspond well with JS. In that case, it's probably better to target LLVM and then compile to JS via emscripten.

gngeal 13y ago

There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode. How does one do call/cc in LLVM, or delimited continuations, for that matter?

pbsdp 13y ago
The same way you'd do it in any runtime? Adopt an adequate representation model of the machine state, and save that state.
- gngeal 13y ago
  Why would I save "a representaion model" when I can simply save the process/thread state?
  - pbsdp 13y ago
    You can't do that in portable C as-is. Watch what happens when you try to restore thread state on a different system thread using an OS that instrisically ties system threads to user threads to thread local variables to the stack. And no, getcontext() and setcontext() aren't portable.
    - gngeal 13y ago
      Why would I care if it's portable or not? I've never understood the mentality of "but it's not portable". If something isn't not portable, you put #+ and #- on top of it. I'd rather go for "straight-forward and performant" than for some abstract code transformations to make it runnable on platforms that almost nobody uses to the detriment of everyone else. LLVM is the lowest common denominator. I'm really not fond of lowest common denominators. (Not to mention the fact that it's bloatware in the first place - it's about twice the size of my favourite compiler, and that's before you add the actual language you're trying to compile.)
      - 13y ago

azakai 13y ago

> C is a heavyweight intermediary language which brings with it a /lot/ of baggage. There's no valid direct technical reason other than financial resource constraints to justify compiling to C (... or JS, for that matter) instead of a more suitable and expressive IR/bytecode. 1. In theory. But what is that "more suitable and expressive IR/bytecode"? I would argue such a bytecode should be portable, but LLVM IR is not that. 2. There are lots of reasons to target C. C can be compiled by many compilers, while LLVM IR can only be compiled by LLVM to things LLVM can compile to. For example, game consoles, various new embedded platforms, etc. - they all have C compilers, but LLVM might not support them (and possibly cannot support them).

pbsdp 13y ago
> 2. There are lots of reasons to target C. C can be compiled by many compilers, while LLVM IR can only be compiled by LLVM to things LLVM can compile to. For example, game consoles, various new embedded platforms, etc. - they all have C compilers, but LLVM might not support them (and possibly cannot support them). Is the point to produce something optimal for users, or produce something optimal for developers? Most successful game and application platforms trend towards the former, whereas your work on web technologies trends towards the latter.
- nullc 13y ago
  Vendor lock-in isn't good for users either.
  - zxcdw 13y ago
    No, it is not. But what does it have to do with anything discussed here? I can't see IR being something which locks users or developers to a particular vendor.
eliben 13y ago
It's not difficult to restrict LLVM IR to a portable subset, though ;-)
13y ago

vidarh 13y ago

LLVM IR is less portable than C. That's a valid direct technical reason. Generating C (or another high level language) also makes integration with tools in that language potentially trivial (depending on the semantics of the language you're compiling), and depending on your preference you may find it far easier to debug the output. As for portability, while you're right that a number of things can't be implemented in portable C, you gain the benefit that C has been ported to far more systems than LLVM - there are C compilers even for the Commodore 64. I agree with you that C is heavyweight, but LLVM is too. Personally I prefer to build code generators directly - the LLVM infrastructure may be great, but I much prefer to write compiler that are self contained and bootstrapped in the language they are intended to compile. Then again I might just be difficult.