• mike domain.invalid (22/22) Feb 11 2011 Hello all! This is the off-topic section, right? ;)
• Damian (3/42) Jul 06 2013 http://en.wikipedia.org/wiki/Dragon_Book
• Cxv (4/43) Jul 07 2013 this historical S.O question is highly related to the topic.
• Ramon (32/32) Aug 27 2013 Hi Mike
• DarenW (38/39) Mar 21 2014 I remember way back, late 1970s, toying with an interpreter from
• Mark Barton (22/33) Dec 22 2014 Since you are the "Assembly guy", you could look at:

mike domain.invalid writes:

Hello all! This is the off-topic section, right? ;)

I may be wrong but it seems to me most of the compilers at least most of the
great ones are written by a very small pool of people. That tells me it's
probably pretty hard to do a good job or everybody would be doing it. Anyway
it's pretty obvious Walter knows what he is doing.

My question is how to get started with compiler writing. My background is
I'm a guy who has written systems software in assembler for a long time on
large IBM systems. I'm not an academic and I'm pretty crappy at math. Do I
really need to understand finite automata (did I even spell that right?!)
and graph theory and technical topics like that to be able to write a
good compiler? I'm fascinated by this topic but know nothing about it. I
haven't been able to find any general, practical guides to writing compilers
that aren't based on x86 and C or Java, all stuff I really don't know about
and honestly am not all that interested in knowing about. I would like to
use the skills I have and write a compiler for the platform I use in my
job. In other words, I'll never be any competition for Walter or the C/C++
market but you already knew that. ;)

Walter, have you written any books on the topic and can you recommend any
practical guides? Would you say a little about your background and how you
got started writing compilers? The whole topic is interesting to me.

Thanks,

Mike

"Damian" <damianday hotmail.co.uk> writes:

On Friday, 11 February 2011 at 10:44:02 UTC, mike domain.invalid 
wrote:
 Hello all! This is the off-topic section, right? ;)

 I may be wrong but it seems to me most of the compilers at 
 least most of the
 great ones are written by a very small pool of people. That 
 tells me it's
 probably pretty hard to do a good job or everybody would be 
 doing it. Anyway
 it's pretty obvious Walter knows what he is doing.

 My question is how to get started with compiler writing. My 
 background is
 I'm a guy who has written systems software in assembler for a 
 long time on
 large IBM systems. I'm not an academic and I'm pretty crappy at 
 math. Do I
 really need to understand finite automata (did I even spell 
 that right?!)
 and graph theory and technical topics like that to be able to 
 write a
 good compiler? I'm fascinated by this topic but know nothing 
 about it. I
 haven't been able to find any general, practical guides to 
 writing compilers
 that aren't based on x86 and C or Java, all stuff I really 
 don't know about
 and honestly am not all that interested in knowing about. I 
 would like to
 use the skills I have and write a compiler for the platform I 
 use in my
 job. In other words, I'll never be any competition for Walter 
 or the C/C++
 market but you already knew that. ;)

 Walter, have you written any books on the topic and can you 
 recommend any
 practical guides? Would you say a little about your background 
 and how you
 got started writing compilers? The whole topic is interesting 
 to me.

 Thanks,

 Mike

http://en.wikipedia.org/wiki/Dragon_Book

"Cxv" <Cxv nowhere.fr> writes:

On Friday, 11 February 2011 at 10:44:02 UTC, mike domain.invalid 
wrote:
 Hello all! This is the off-topic section, right? ;)

 I may be wrong but it seems to me most of the compilers at 
 least most of the
 great ones are written by a very small pool of people. That 
 tells me it's
 probably pretty hard to do a good job or everybody would be 
 doing it. Anyway
 it's pretty obvious Walter knows what he is doing.

 My question is how to get started with compiler writing. My 
 background is
 I'm a guy who has written systems software in assembler for a 
 long time on
 large IBM systems. I'm not an academic and I'm pretty crappy at 
 math. Do I
 really need to understand finite automata (did I even spell 
 that right?!)
 and graph theory and technical topics like that to be able to 
 write a
 good compiler? I'm fascinated by this topic but know nothing 
 about it. I
 haven't been able to find any general, practical guides to 
 writing compilers
 that aren't based on x86 and C or Java, all stuff I really 
 don't know about
 and honestly am not all that interested in knowing about. I 
 would like to
 use the skills I have and write a compiler for the platform I 
 use in my
 job. In other words, I'll never be any competition for Walter 
 or the C/C++
 market but you already knew that. ;)

 Walter, have you written any books on the topic and can you 
 recommend any
 practical guides? Would you say a little about your background 
 and how you
 got started writing compilers? The whole topic is interesting 
 to me.

 Thanks,

 Mike

this historical S.O question is highly related to the topic.

http://stackoverflow.com/questions/1669/learning-to-write-a-compiler

"Ramon" <spam thanks.no> writes:

Hi Mike

First, there are some basic questions like "Do you mean a 
'compiler' or something that translates source code and let's you 
execute it (e.g. interpreter)?", "Is your focus on creating a 
language and somehow run programs in it or is your focus on 
writing a compiler (for whatever language, maybe pascal)?", or 
"What is the platform that it should run on?" and others.

Brutally simplifying it, there are two major aspects. First, 
"reading the source code" (of your language) and creating an 
abstract representation, typically an AST tree. Second would be 
the generation of some kind of code. Depending on what you 
want/need you might get away without a lot of math.

If it's just for the fun of giving in to a fascination you might 
prefer to go for an interpreter, possibly using an existing VM.

If you're dead serious you might have a look at the LLVM project. 
They have a lot to offer, e.g. a very well designed "meta 
assembler language" that their engine groks and then, another big 
plus, your language can be both compiled and interpreted on a 
(increasingly large) variety of architectures.

Walking the whole chain all alone will quite probably not worth 
it unless one has (like Walter Bright) loads and loads of know 
how and experience and wants to create a full fledged product for 
a competitive environment (Which, btw, does not mean LLVM is just 
for hobbyists; it's definitely not).

One hint I'd like to give is that you shouldn't enthusiastically 
come up with a lot of desirables for your language but always 
keep in mind that - and how - those can be implemented and what 
trade offs are involved.

If you can and want to describe in more detail what you have in 
mind, you might get more, more concrete and more useful tips.

Good luck

A+ - R

"DarenW" <darenw darenscotwilson.com> writes:

On Friday, 11 February 2011 at 10:44:02 UTC, mike wrote:

 My question is how to get started with compiler writing.


I remember  way back, late 1970s, toying with an interpreter from 
scratch based on a short article in Byte.  Might have been early 
1980s. I don't recall what it was called.  It was probably in a 
regular section of the magazine called Programming Quickies.  
Google isn't coming up with much, but there is this index to old 
Byte issues:  
http://www.devili.iki.fi/library/publication/10.en.html

This, I think is different, but also a very tiny interpreter - 
WADUZITDO appearing in Byte in 1978. Someone put it up on a 
website - http://waduzitdo.org/

Working with tiny languages and tiny compilers or interpreters is 
a great way to start, to figure out the fundamental workings.  
Then add on new features.

When it grows and gets messy, it's time to read the famous Dragon 
Book http://en.wikipedia.org/wiki/Principles_of_Compiler_Design  
or study source for a compiler for any language that isn't C++.  
Languages that don't make a big deal about Objects, and don't try 
very hard to be cross-platform, so you can concentrate on the 
compiler workings of language parsing and code generation.  
Oberon is good, Modula-2 or Modula-3, Pascal, and other languages 
which typically aren't popular today.   Peek into Java or Ruby if 
you want OO - these have nicer compiler innards than gcc or clang 
or python, but do note there are big differences between 
languages with just runtime libraries (like C) and those with 
complete runtime engines like .net, java's JVM.  Hoo boy, that's 
a whole 'nother nest of complexity to become familiar with.

An interpreted language with a very simple working principle is 
TCL. It gains power through modules or extension or whatever - 
it's been a while. But the inner core is very clean and simple. 
(Or was in older versions.)

One other language that's worth mentioning and studying to learn 
about interpreters, old but still in use in a sense: Forth.  It 
has a unique way of working. Though different most most other 
languages, it's educational for understanding interpreters in 
general. Byte had a great special issue covering it.  Forth 
itself isn't seen much these days, but it's the basis of 
Postscript, and therefore used by PDF documents.

"Mark Barton" <mbvvb22 tpg.com.au> writes:

On Friday, 11 February 2011 at 10:44:02 UTC, mike wrote:
 Hello all! This is the off-topic section, right? ;)

 I may be wrong but it seems to me most of the compilers at 
 least most of the
 great ones are written by a very small pool of people. That 
 tells me it's
 probably pretty hard to do a good job or everybody would be 
 doing it. Anyway
 it's pretty obvious Walter knows what he is doing.

 My question is how to get started with compiler writing. My 
 background is

.....
 Mike

Since you are the "Assembly guy", you could look at:
http://www.nand2tetris.org/course.php

Their projects:
High-Level Language Project 9
Compiler I: Syntax Analysis Project 10
Compiler II: Code Generation Project 11
could be of interest as they cover it from the ground up.

Also, being "close to the metal" you could learn Forth which has
an interpreter and assembler and these fit in under 8k RAM i.e.
very small and very tightly coupled to the underlying hardware.

JonesForth.S and JonesForth.F are very well documented text files
(which you could assemble for a working system or just read and
understand them).

Download locations are various (google search), eg:
http://www.eecs.wsu.edu/~hauser/teaching/Arch-F07/handouts/jonesforth.s.txt
and for Jonesforth.F
https://code.google.com/p/subtle-stack/downloads/detail?name=jonesforth.f.txt
will do.

Happy compiler writing,
Mark Barton