Writing a compiler in Python using Lex, Yacc and LLVM

Post by ilkhd2 » Sun, Sep 20, 2009, 3:46 AM UTC

daeken wrote: post #14

ilkhd2 wrote: post #13

Earlier quoted context omitted.

1. No not any. Many cross-compilers do not if the binary formats and pecularities of arithmetic operations maps well between host system and target system - why waste time? Example = x86 and x64, two different platforms, with same binary representation. About performance - not sure if it is negligible - optimisation takes a lot of time in moder compilers. 3. You have not seen ml code I am sure. ML has type inference,…

I've done quite a lot with the ML family, just not OCaml specifically. Type inference helps, but being able to use an Sexp-style representation a-la lisp is a huge, huge benefit in compilation. You cannot do this in any of the ML family. Pattern matching is a great feature, and it's available in all of the languages I mentioned. It's a built-in in Boo, there are many libraries for it in Scheme, and I have my own Sexp…

Post by scott_s » Sun, Sep 20, 2009, 3:51 AM UTC

sketerpot wrote: post #18

viraptor wrote: post #12

Earlier quoted context omitted.

> FP is almost never done in software, it hurts performance big time During the compilation? Would you even see the difference if the compiler did 0.1*0.2 by emulating cpu processing, instead of via one instruction? The cost of register allocation for a simple function will be greater than optimising many constant fp expressions. It simply doesn't matter here. If you have a convenient type, you use it, if you don't,…

Okay, I've been wondering about this for a while: what processor would you possibly want to run a compiler on that has floating-point arithmetic incompatible with IEEE 754? Are we still making cross-compilers that run on a VAX? (Not that this would stop the GNU people. Have you seen the code from bison? They actually emit code for their own reimplementation of memcpy() on some platforms. They are fanatical about comp…

Post by maximilian » Sun, Sep 20, 2009, 5:02 AM UTC

sketerpot wrote: post #19

Inspired by this, I've started writing a compiler for a subset of Matlab. I'm sick of Matlab being an interpreted language year after year, and while I don't hope to change that, I can at least do a proof-of-concept to lend weight to my derision. I've got the lexer and parser done, thanks to Parsec, and some basic C code generation as a sanity check. Now for the runtime LLVM code generation, to make it feel like an i…

Post by anatoly » Sun, Sep 20, 2009, 6:29 AM UTC

maximilian wrote: post #26

sketerpot wrote: post #19

Inspired by this, I've started writing a compiler for a subset of Matlab. I'm sick of Matlab being an interpreted language year after year, and while I don't hope to change that, I can at least do a proof-of-concept to lend weight to my derision. I've got the lexer and parser done, thanks to Parsec, and some basic C code generation as a sanity check. Now for the runtime LLVM code generation, to make it feel like an i…

Could you post a link to Parsec. Quick googling didn't come up with any compiler tools. Thanks!

Post by ilkhd2 » Sun, Sep 20, 2009, 6:37 AM UTC

mahmud wrote: post #24

ilkhd2 wrote: post #7

Earlier quoted context omitted.

if you read carefully what I said, i never said that hig-level languages are bad - I said only this: 1) Compiler written in python, ruby and other "slow" (do not beleive that pyruby is slow?) languages going to take eternity to compile linux kernel. 2) You need to have _precise_ mapping between types in compiler and the language you implement. It is so important that gcc use a software library for floating point comp…

Compiler written in python, ruby and other "slow" .. languages going to take eternity to compile linux kernel. What makes you think everyone is out to write a C compiler?