Hi, I haven't read the purple dragon book, but I read everywhere that it's the "bible" for compilers.
I've read "Compiler Construction" by Kenneth Louden and I enjoyed it (my edition is in Spanish, but a google search pointed me to http://www.cs.sjsu.edu/~louden/cmptext/, which is the original English edition). I was not really trying to build a compiler but rather understanding how compilers work, i.e. how a program converts text to something that will eventually be executed by some machine (machine code, virtual machine, etc). My goal was more modest: building a tool to convert actionscript assembly (as produced by the ABCDump utility in the Tamarin project) to something _closer_ to actionscript code. Not actually compilable, but something with higher level constructs like assignments, conditionals, loops, etc, instead of jumps and registers. That is, something you can read and make sense of it without having to mentally representing the stack state (which is almost humanly impossible when the stack has a depth of, say, 10 elements!). That book helped me a lot to figure out things. Another source you could look up, besides mtasc and haxe, is the Flex SDK compiler (mxmlc). It's java, so maybe you already know the language or at least, knowing actiosncript, java will be easy to follow. Learning Ocaml should be cool and functional languages are all the rage these days, but perhaps you already have a lot stuff going on, so at least that's one thing less to tackle right now. I have no experience in this, but maybe producing the machine code itself could be a too ambicious goal right know. I don't know what language you're trying to compile (or if you're making your own language), but maybe you can take a look a GCC. My understanding is that you can write a front-end, to do the parsing, lexing, etc, and delegate the machine code generation to the GCC compiler backend. (You could take a look at this for an intro to writting a front-end: http://tldp.org/HOWTO/GCC-Frontend-HOWTO.html). Later, when you have a front-end working and more experience, you could try to build your own back-end. Cheers Juan Pablo Califano 2009/8/5 Anthony Pace <[email protected]> > Thanks to Paul, Ian , and Kerry for your responses. > > I absolutely require additional knowledge of assembly and machine code > for me to compile the final result and to take advantage of the > different types of hardware the way I want/need to. I know I am a long > way away, even with my books; yet, the final result even if it takes > years, (although I doubt it should take that long once I have exhausted > the documentation, as I learn pretty quickly) it will be worth it. > > The purple dragon is what I am reading now, and the compiler design > handbook is what I will be reading next. I am pretty sure I should be > able to make my way through them in a few months; yet, I am very > interested in what small-c has to offer too. > > I will definitely take a look at the haxe source when I am ready to > learn ocaml. > > Any other advice about books, lists, or trends is appreciated. > > Thanks, > Anthony > > Ian Thomas wrote: > > You could do worse than take a look at the sources for both MTASC and > haXe. > > > > MTASC is a compiler for AS2. > > http://mtasc.org/ > > > > haXe is a compiler for... uh... haXe. But haXe is a very AS3-like > > language (it has its roots in AS). > > http://haxe.org/ > > > > Both are written by Nicolas Cannasse. > > > > Both are written in the functional programming language OCAML and are > > lightning fast. A lot of people swear by functional languages for > > compiler-writing these days; BNF-style rule-based parsing maps on to > > functional languages much more naturally than on to OOP/procedural > > languages. > > > > HTH, > > Ian > > > > On Mon, Aug 3, 2009 at 4:37 PM, Kerry Thompson<[email protected]> > wrote: > > > >> Anthony Pace wrote: > >> > >> > >>> Can anyone recommend a good mailing list for compiler design for > newbies? > >>> > >>> I have books on it, and I know the basics of how to perform > tokenization > >>> and lexical analysis; yet, even with study and practise, I am most > >>> likely going to be considering myself a newbie in the compiler design > >>> realm for at least a few years. Keep in mind that my assembly is very > >>> rudimentary, and my machine code is even worse > >>> > >> I did some compiler work for Borland, but that was 15 years ago or more. > >> Anybody remember Borland's Fortran compiler? No? I thought not. > >> > >> I don't know of compiler mailing lists, but I can tell you that you > probably > >> don't need assembly or machine code. We did the Fortran compiler in C > (not > >> C++), with very little inline assembly code. I don't know of anybody who > has > >> done machine code for 20 years or more. It is truly obsolete unless > you're > >> writing for some proprietary hardware. > >> > >> There is a school of thought that you ought to be able to write a > compiler > >> in its own language. I.e., if you're writing a C++ compiler, you would > write > >> it in C++. I don't know if that would apply so well to ActionScript, > though, > >> because of its speed. I would probably choose a language that compiles > to > >> machine code, like C++, rather than a tokenized language--you want that > >> extra speed boost in your primary tool. > >> > >> Cordially, > >> > >> Kerry Thompson > >> > >> _______________________________________________ > >> Flashcoders mailing list > >> [email protected] > >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > >> > >> > > > > _______________________________________________ > > Flashcoders mailing list > > [email protected] > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
