Recent

Author Topic: Wiki stub: Make your own compiler, interpreter, parser, or expression analyzer  (Read 7396 times)

Edson

  • Hero Member
  • *****
  • Posts: 1041
In your opinion:
What are the best books about compilers or interpreters or assemblers or linkers?
Is there any new (last five or ten years) good books about compilers or interpreters or assemblers or linkers?

Sorry. I don't read books about compilers a long time ago. I just remember some from Wirth, but nothing special. I read differents pages, documents, articles, and papers from the Web.
Lazarus 1.6 - FPC 3.0.0 - x86_64-win64 on  Windows 7

440bx

  • Hero Member
  • *****
  • Posts: 1089
In your opinion:
What are the best books about compilers or interpreters or assemblers or linkers?
Is there any new (last five or ten years) good books about compilers or interpreters or assemblers or linkers?
My favorite book about compilers is Per Brinch Hansen's "On pascal compilers".  IMO, it's probably the best book ever written on compilers.  It's the one book that truly aims to make the reader understand the techniques used to define and convert a language (usually high level) into a series of instructions.

There is little to nothing in it about assemblers and linkers but, if you want to truly understand how a language is defined (I should say, _one_ way of defining a language/grammar) and the foundation of going from grammar to low level instructions, I don't believe there is a better book.

Unfortunately, at least at this time, the prices people are asking for it are rather steep but, if sometime you can get it for a reasonable amount, I believe you'll be very pleased.

I should also note that it is an introductory text but it opens the door to easily _understand_ (instead of just learning) other techniques presented in more advanced books.

HTH.

using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Trenatos

  • Hero Member
  • *****
  • Posts: 508
  • Software developer - Open source contributor
    • MarcusFernstrom.com
I've started playing with Plex/Pyacc again, I'll start adding pages as I go.

JdeHaan

  • New Member
  • *
  • Posts: 22
For those interested, I published my hobby interpreter project on GitHub:

https://github.com/jdehaan2014/GearLanguage

It is a procedural object-oriented functional language, supporting anonymous functions. I wrote everything I coded from start to finish with explanations and sample Gear code in the accompanying document (pdf).

All comments are welcome.
Cheers!

MarkMLl

  • Jr. Member
  • **
  • Posts: 79
I've just tacked some stuff onto the end which includes a couple of useful links on the history of recursive descent etc. which I hope somebody finds interesting.

I admit that I take some of this rather personally, since at about the same time as I joined Burroughs a document appeared where the author (Richard Waychoff) claimed that he had invented recursive descent and virtual memory. I was very dismissive of this, feeling that it was a company man writing for company men, but 40 years on and with the benefit of various oral histories etc. I think he has a very good claim to precedence on both fronts.

MarkMLl

dtoffe

  • New Member
  • *
  • Posts: 18
For those interested, I published my hobby interpreter project on GitHub:

https://github.com/jdehaan2014/GearLanguage

Hi, looks interesting, a couple questions: What languages influenced your decisions ? Do you plan to add code generation ? Do you have a grammar document ?

Thanks,

Daniel

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 635
I'm also going to make my own Pascal compiler, but it's going to take a completely different approach, as it all has to run on a microcontroller.

Basically, my compile unit is a single statement and my source code unit is a single statement that is terminated by a semicolon. My first goal is to store the source in P-code format, to make it small. Then again, the most compact way to store the source code is probably as a compiled binary, with a limited amount of debug symbols.

So, my parsing will be done while editing the source code, one line at a time. The code generation will initially be JIT, when loading the code into memory. And later, if possible, the editor will use a disassembler to display and edit the source code.

If I finish the project, I'll update the wiki on how to do it.

lucamar

  • Hero Member
  • *****
  • Posts: 1991
My first goal is to store the source in P-code format, to make it small. Then again, the most compact way to store the source code is probably as a compiled binary, with a limited amount of debug symbols.

You do know that P-Code is the compiled code, don't you? It's compiled for a virtual machine but it's compiled code. Like Java and the JVM.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 635
My first goal is to store the source in P-code format, to make it small. Then again, the most compact way to store the source code is probably as a compiled binary, with a limited amount of debug symbols.

You do know that P-Code is the compiled code, don't you? It's compiled for a virtual machine but it's compiled code. Like Java and the JVM.

Source code goes through multiple steps. First you tokenize it, then you parse it into a functional description. That parse tree is then analyzed (and optionally optimized), then code is generated and as the last step all the bits are linked together into an executable file.

The Sinclair computers immediately did the tokenizing. The QL also did some limited parsing and called the resulting format P-code.

Many systems compile to P-code and run that through an interpreter. Which is basically what a JVM does as well.

In short, it depends.
« Last Edit: July 14, 2019, 11:08:24 am by SymbolicFrank »