Slashdot Mirror


MELT, a GCC Compiler Plugin Framework, Reaches 1.0

karijes writes with news that the Middle End Lisp Translator extension for GCC has hit 1.0: "MELT is a high-level domain specific language for extending, customizing and exploring the GNU Compiler Collection. It targets advanced GCC users, giving them ability to hook on almost any GCC stage during compilation or interpretation phases. This release brings a lot of new things." New features include defmacro and changes to the antiquote operator.

58 comments

  1. Also, MetaMELT 0.3 by Thanshin · · Score: 4, Funny

    In other News, MetaMELT's v0.3 was released this last weekend.

    "MetaMELT a meta-level tool for the customization of MELT's dynamic pattern matching paradigm, allowing the refinement of the GCC's internal data management during the pre-hooking phase."

    1. Re:Also, MetaMELT 0.3 by K.+S.+Kyosuke · · Score: 1

      I believe that defmacro already covers that.

      --
      Ezekiel 23:20
    2. Re:Also, MetaMELT 0.3 by Thanshin · · Score: 4, Funny

      I believe that defmacro already covers that.

      Defmacro defines that, but, who defines defmacro?

      Or, as MetaMELT lead designer and "guru" said himself: "Quis definiet ipsos definieentis?"

    3. Re:Also, MetaMELT 0.3 by basiles · · Score: 1, Interesting

      I'm the main author of MELT (the GCC plugin). I am not aware of any related software named MetaMELT. Do you have any references please? Regards.
      Basile STARYNKEVITCH email: basile at starynkevitch dot net

    4. Re:Also, MetaMELT 0.3 by Anonymous Coward · · Score: 0

      > definieentis

      Can you catch that on the internet?

    5. Re:Also, MetaMELT 0.3 by Darinbob · · Score: 1

      I always preferred the defwhopper flavor.

    6. Re:Also, MetaMELT 0.3 by K.+S.+Kyosuke · · Score: 1

      Defmacro defines that, but, who defines defmacro?

      In most Lisp implementations, given that defmacro is a macro, defmacro is - quite naturally! - defined in a defmacro. In ClozureCL, for example, it starts as (defmacro defmacro (name arglist &body body &environment env) <some-convoluted-body> )

      Or, as MetaMELT lead designer and "guru" said himself: "Quis definiet ipsos definieentis?"

      Excavans testudines ad infinitum patentes perspicies.

      --
      Ezekiel 23:20
    7. Re:Also, MetaMELT 0.3 by Anonymous Coward · · Score: 0

      In other news, a Massively Extensive Layer of Trash has been added to the GCC.

    8. Re:Also, MetaMELT 0.3 by maxwell+demon · · Score: 1

      But how can you define defmacro using defmacro before you have defined defmacro? (And afterwards, it wouldn't make sense because it already is defined).

      --
      The Tao of math: The numbers you can count are not the real numbers.
    9. Re:Also, MetaMELT 0.3 by Anonymous Coward · · Score: 0

      Some systems use http://en.wikipedia.org/wiki/Meta-circular_evaluator

      Other bootstrap methods may use the same notation for fully initializing the later stages.

    10. Re:Also, MetaMELT 0.3 by forkazoo · · Score: 1

      Defmacro defines that, but, who defines defmacro?

      Templates.

  2. Too little too late by Anonymous Coward · · Score: 0, Troll

    Among me and my hardcore developer friends GCC is effectively dead in the water. LLVM has eaten its lunch due simply to the fact that LLVM respects developer rights by giving them the FREEDOM to do anything they want with the code. Unless and until GCC dumps the socialistic GPL license idiocy, it will stay dead to everyone that matters.

    1. Re:Too little too late by Mitchell314 · · Score: 1

      Uh, I don't think the GCC license places any restrictions on compiled code.

      --
      I read TFA and all I got was this lousy cookie
    2. Re:Too little too late by Anonymous Coward · · Score: 0

      Among me and my hardcore developer friends

      Obvious troll is obvious.

    3. Re:Too little too late by wiredlogic · · Score: 4, Informative

      Your hipster hardcore developer friends might want to read the GCC license some day which has an explicit exception allowing the runtime code to be incorporated in closed source software without imposing the terms of the GPL.

      --
      I am becoming gerund, destroyer of verbs.
    4. Re:Too little too late by Anonymous Coward · · Score: 1

      you can't build a great IDE for gcc, but with LLVM the license permits the necessary access to libraries.

    5. Re:Too little too late by Anonymous Coward · · Score: 0, Troll

      You need more than that to build a great IDE that provides interactive hints on what is in/how to use those libraries

    6. Re:Too little too late by n1ywb · · Score: 1

      Runtime in that case means the C runtime which implements low level program run time boilerplate functionality. It has nothing to do with hooking into GCC internals to e.g. build an IDE with it.

      --
      -73, de n1ywb
      www.n1ywb.com
    7. Re:Too little too late by Anonymous Coward · · Score: 0

      Clearly you and your "hardcore" developers have never looked at the output of LLVM. Its worse than gcc and neither are all that good.

    8. Re:Too little too late by Anonymous Coward · · Score: 1

      you can't build a great IDE for gcc

      Of course you can.

    9. Re:Too little too late by interval1066 · · Score: 1

      ...dead in the water...

      I don't think so. The gcc & it's toolchain, and the arm cross-compiler, are indispensable where I'm at. The current licensing is little more than an annoyance right now.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    10. Re:Too little too late by basiles · · Score: 3, Informative

      I am not sure of your assessment. Most Linux distributions are currently compiled with GCC, and a lot of embedded systems (or software) are also compiled with GCC. I agree that LLVM/Clang is a healthy competitor, but I won't say that GCC is dead.

    11. Re:Too little too late by Anonymous Coward · · Score: 0

      Whoops! You're replying to the wrong thread. Or you have bad reading comprehension.

    12. Re:Too little too late by Anonymous Coward · · Score: 0

      Your hipster hardcore developer friends might want to read the GCC license some day which has an explicit exception [gnu.org] allowing the runtime code to be incorporated in closed source software without imposing the terms of the GPL.

    13. Re:Too little too late by Anonymous Coward · · Score: 1

      "Most Linux distributions are currently compiled with GCC"

      I said people who *matter*. Game developers, iOS app developers, that kind of thing.

    14. Re:Too little too late by Anonymous Coward · · Score: 0

      people who *matter*

      Game developers

      Pick one.

    15. Re:Too little too late by Anonymous Coward · · Score: 0

      No true Scotsman argument.

    16. Re:Too little too late by Darinbob · · Score: 1

      GCC is indepensible for so many embedded systems. Just because some are starting to move away from in on PC platforms is not all that important. But this is slashdot, things are routinely declared dead here decades before their time.

    17. Re:Too little too late by BasilBrush · · Score: 1

      Among me and my hardcore developer friends GCC is effectively dead in the water. LLVM has eaten its lunch due simply to the fact that LLVM respects developer rights by giving them the FREEDOM to do anything they want with the code. Unless and until GCC dumps the socialistic GPL license idiocy, it will stay dead to everyone that matters.

      You shouldn't have been modded troll. You were making a genuine point. There's also the fact that LLVM is a far superior and more modern compiler engine than GCC. (If anyone needs objective evidence, just look at compile and run times.)

    18. Re:Too little too late by c++0xFF · · Score: 1

      Let me translate. "Great" in this case means "non-GPL" (YMMV, of course). If you want to link into the compiler code itself (rather than just calling the compiler binaries), you've just forced your IDE to use the GPL.

      LLVM, on the other hand, has a more permissive license, so it's a non-issue. And it was built with this sort of IDE-compiler interaction in mind, so there's that, too.

    19. Re:Too little too late by Anonymous Coward · · Score: 0

      So MELTdowns due to to many reference melts follows the letter of the license?

    20. Re:Too little too late by mbkennel · · Score: 1


      Compile times are better in LLVM. Run times are generally a little bit worse in LLVM.

      The commercial Intel compilers (C++/Fortran) offer the highest execution performance on Intel hardware.

    21. Re:Too little too late by Anonymous Coward · · Score: 0

      Try to use .progmem on an AVR chip with GCC (using the assembler and linker to do it). You'll find it next to impossible. At a bare minimum, you'll need to adorn your source with all sorts of GCC crap to make the linker do something reasonable. Following that, you'll need to wade through the default linker script and figure out that it needs even MORE adornment, and still generates incorrect addresses fairly often, requiring what amounts to manual linking.

      Fuck this, I'm using anything else BUT GCC if i can get away with it for an emedded platform. Also, the extra 4.2K of crap to blink an LED is bullshit.

    22. Re:Too little too late by interval1066 · · Score: 1

      Try to use .progmem on an AVR chip...

      Sure, cherry pick an obscure use case with old Atmel hardware. I think I'm ok with the arm stuff for now.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    23. Re:Too little too late by maxwell+demon · · Score: 2

      "Great" in this case means "non-GPL" (YMMV, of course).

      That's a very strange definition of great. Virtually everyone relates that word to features, intuitiveness, absence of annoying bugs, etc. That is, to properties of the IDE.

      And no, that's not a question of mileage, that's a question of proper use of the language.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    24. Re:Too little too late by jeremyp · · Score: 1

      Yes you can as long as you license it with the GPL

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    25. Re:Too little too late by Anonymous Coward · · Score: 0

      No, true sarcasm. Argument!

  3. Interesting to learn about by TheNastyInThePasty · · Score: 1

    Not too long ago, I was looking into various game engines and one feature I saw was the ability to modify semi-constant values during runtime to facilitate rapid development. For example, being able to modify the position of a barrel in a scene to just the right location and then make those changes permanent.

    I wondered why this couldn't be implemented as a standalone library to allow any type of program to do this kind of thing. I envisioned a compiler plugin that would read constant values from some files and, with a compiler flag turned on, allow you to edit the values in said files and instantly see the results. With the compiler flag turned off, the values read from the files would be baked into the executable as static constants, eliminating any run speed downside.

    It seems that this meta-plugin might make such a system a lot easier to implement. Does anyone know of anything similar to what I'm describing?

    --
    The best thing about UDP jokes is I don't care if you get them or not
    1. Re:Interesting to learn about by K.+S.+Kyosuke · · Score: 1

      That sounds like a non-problem. Why don't you simply read the values from a file? Watching the file for changes and reloading it also shouldn't be difficult. Apache httpd and other daemons have been doing this since the last ice age or so.

      --
      Ezekiel 23:20
    2. Re:Interesting to learn about by Anonymous Coward · · Score: 0

      Well, #define works just fine, along with conditional compilation. Whatever constants you need tweakable, #define them either to something that reads a value stored anywhere you want, or to a constant, depending on what kind of build you are doing. I know, a lot less fancy than a compiler plugin.

    3. Re:Interesting to learn about by VortexCortex · · Score: 1

      Uh, that's what 3D modeling tools are for... Using a compiler in place of a level editor is a fool's errand.

    4. Re:Interesting to learn about by Jmc23 · · Score: 1

      It's spelt Lisp.

      --
      Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
    5. Re:Interesting to learn about by Anonymous Coward · · Score: 0

      Lisp is awesome. Every time someone spouts off about how their newfangled language has some awesome new feature, Lisp had it 50-60 years ago. I wish it were more popular.

    6. Re: Interesting to learn about by Anonymous Coward · · Score: 0

      To be honest, most of what you want to do can be achieved with a standard debugger.

    7. Re:Interesting to learn about by ebno-10db · · Score: 1

      Every time someone spouts off about how their newfangled language has some awesome new feature, Lisp had it 50-60 years ago.

      When we build the Museum of Computer Languages we'll be sure and devote an entire wing to the many Lisps. If I were to hop into a time machine and go back 60 years, I'd be sure to program in Lisp. That says nothing though about the best choice of language today. I don't mean this as an anti-Lisp rant; I just want to point out that the "we had it first" argument for Lisp is irrelevant.

    8. Re:Interesting to learn about by Anonymous Coward · · Score: 1

      The "we're still the only ones to have this" argument, however, is still relevant...

      Various types of macros (reader, syntax-aware, hygienic, etc.), same code syntax and capabilities from pre-processing through run-time, generic functions and the rest of CLOS, semantics defined for compilation and interpretation, extensive compiler hinting, etc.

    9. Re:Interesting to learn about by Unknown+Lamer · · Score: 1

      I think you want "Common Lisp".

      --

      HAL 7000, fewer features than the HAL 9000, but just as homicidal!
  4. Don't forget PattyMELT 0.1, iteration 5,875 by Anonymous Coward · · Score: 1

    PattyMELT 0.1, a fine, greasy affair consisting of a hamburger patty, slice of cheddar and sautéed onions on rye, was released at 12:43 PM at Joe's Diner on Route 7 to Bob Jenkins, a local plumber. This was Bob's 483'rd iteration on the project.
    Asked what he thought the requirements might be to get the project up to a 0.2 version, he replied: "mmmrphWha?mnomnom'".
    Asked again where he thought PattyMELT could use some tidying to improve its utility, he said "(gulp) Are you one of them pencil-necks from over at the college? Buzz off, before I lay a pipe wrench alongside your little pansy face. Can't a man eat?"

  5. Lisp syntax is the problem by dwheeler · · Score: 2

    The problem is, in part, Lisp's syntax. Most people don't want to read code written in lisp, because (+ (* 3 4) 5) is a big pain. You might look into http://readable.sourceforge.net/ - it extends Lisp s-expressions with additional abbreviations, making it much easier to read.

    --
    - David A. Wheeler (see my Secure Programming HOWTO)
    1. Re:Lisp syntax is the problem by ebno-10db · · Score: 2

      Isn't that also what Dylan was supposed to do?

  6. Re:Wow, that's incredible! by Anonymous Coward · · Score: 0

    And tell me what piece of software have you written, AC?

  7. so by Anonymous Coward · · Score: 0

    MELT reached 1.0 or was pronounced 1.0 ?

  8. RMS will hate it by shutdown+-p+now · · Score: 2

    As I recall, Stallman has specifically stated that GCC is not extensible this way out of the box, because he didn't want the dirty proprietary plugins piggybacking on top of the GPL'd frontend & backend. He said it's why the entire protocol between front-end and back-end is deliberately not standardized. It's also why the license specifically excludes the intermediate output from the usual "output is not covered by GPL" exemption:

    "Target Code" refers to output from any compiler for a real or virtual
    target processor architecture, in executable form or suitable for
    input to an assembler, loader, linker and/or execution
    phase. Notwithstanding that, Target Code does not include data in any
    format that is used as a compiler intermediate representation, or used
    for producing a compiler intermediate representation.

    The "Compilation Process" transforms code entirely represented in
    non-intermediate languages designed for human-written code, and/or in
    Java Virtual Machine byte code, into Target Code. Thus, for example,
    use of source code generators and preprocessors need not be considered
    part of the Compilation Process, since the Compilation Process can be
    understood as starting with the output of the generators or
    preprocessors.

    A Compilation Process is "Eligible" if it is done using GCC, alone or
    with other GPL-compatible software, or if it is done without using any
    work based on GCC. For example, using non-GPL-compatible Software to
    optimize any GCC intermediate representations would not qualify as an
    Eligible Compilation Process.

    You have permission to propagate a work of Target Code formed by
    combining the Runtime Library with Independent Modules, even if such
    propagation would otherwise violate the terms of GPLv3, provided that
    all Target Code was generated by Eligible Compilation Processes
    . You
    may then convey such a combination under terms of your choice,
    consistent with the licensing of the Independent Modules.

  9. Re:Wow, that's incredible! by Anonymous Coward · · Score: 0

    I wrote Linux. And Javascript. Now suck my dick you little wannabe.