There are some comments to show the instructions corresponding to machine code!

If you want to to understand the compiler, I would suggest to start reading main, then binary and then stmt (these two functions parse & compile expressions and statements). If you are more interested into the ELF handling code, everything is in elfgen function (btw, I discovered it is a very nicely engineered file format).

Well, I program alone too (mostly, though), and my code looks nothing like that... This kind of brain-twisted abusal of programming concepts seems to be reserved for lispers and perliots. :\

Plus you are looking at the 32bit version I think. Check out the 64bit version.

Yeah, src64 was it. And holy shit, this stuff is just plain evil.
It kind of reminds me of GNU's CIL runtime (before Mono got popular), and apparently the author loved LISP so much, that half the codebase was full of macros that somehow emulate LISP syntax. GCC even barfed on it (producing the most cryptic error messages I've ever seen - No, C++ template errors are nothing compared to that).

Ah, well. I started with manual labour (read: terminal + g++) and worked my way up from there. QtCreator is the only IDE i'd use if I would use an IDE.

KDE's Kate editor does a pretty decent enough job though, to be honest. I just never saw any good reason for using an IDE. Especially since the selection is rather poor and/or very platform- and compiler-limited.

I just use Konsole, or Kate's builtin terminal (still sometimes quite a chore, because there don't seem to be any hotkeys to switch from the textarea to the terminal and vice versa, but otherwise a-ok).

Before I used KDE, I was using GNOME2, but ever since Canonical decided to go full retard with Unity, I switched to KDE and never looked back. KDE is, in my opinion, how a good desktop should be. Just my personal opinion of course, experience may differ for other people.

The last perl script I wrote is this one here: http://codepad.org/m2B9J2Ib (it searches a given directory for executable files. I wrote that before I found out about find . -type x :P) - I guess it's not the worst one out there.

And yeah, I do have a github account, though I hardly use it. Currently writing a smaller version of Boost, but the concepts are far from finished, so it'll likely take some time until I can actually safely publish it on github.
Do you have one too? :P

Backup is pretty close to what I usually use github for, too; The fact that most of my published code just so happens to be reusable under a very liberal license (MIT / BSD / zlib license) is just a side product. ;D

Anyway, I used to maintain CGI frameworks for a mess of languages, including Lua (yikes, never gonna use that one again), Go (syntax-wise: shudder) and C++ (was a mess, and finally got rid of it). Those are just the more nameworthy ones, but only the Lua one exists, but I'm not even sure if it even still works. Last time I checked it had major problems handling multipart data (i.e., POST) correctly. :|

I was about to thank you, as I internally re-structured my spelling of grammar forever... but then I thought to double check. Looks like "grammar" is correct, unless this is some Americanization (seems a 'z' is appropriate in this case ;) ) and my browser is translating the Internet for me.

It would just complicate it to use lex/yacc. And it would make it longer and require several source files. Moreover, not using them shows that a lot can be done using simple stupid recursive descent parsing, too few people know this (see binary for instance).

Having one source file makes it easy to distribute and people are less afraid to dive into it; even more if this source file is very short!

Yep, exactly. And even worse, it is obfuscated.
This compiler is based on the very same architecture as Bellard's compiler (which is: dump machine code as you go through the syntax).

While Bellard's compiler can work on a real subset of C, this one still has some glitches because of the additional complexity that on amd64, pointers are 64 bits wide while integers are only 32 bits wide.

It's bytecode compiled. Their compiler is notorious for intermixing the tokenizing and parsing and emitting bytecode from that unholy mess - resulting in the need for some "interesting" hacks. I'm not sure whether the bytecode is interpreted or some JITting is done nowadays though.

So not completely like PHP as PHP dumps bytecode as it goes through the syntax instead of machine code.

TempleOS' MiniCompiler is a good example of the technique used and in some regards it is much more readable than otcc, this is why it is quoted. Except for the parser which is a bit esoteric (and uselessly complicated) it is exactly the same compilation technique used in qcc (i.e. compile C expressions into a stack based machine language).

Of course I did not learn this compilation scheme from TempleOS' compiler, this is something I might have learned in K&R when I was young with their stack based calculator. I just provide the link so people can see that it is actually not very complicated to stupidly compile arithmetic expressions. And once you've done expressions, statements are easy. The binary function is like the MiniCompiler (expressed much more shortly).

The compilation scheme is dumb but the devil is in the details: think about lvalues, break, && and ||, dynamic linking, forward references, ELF file format, etc. This was very interesting to do, and contrary to the usual approach much more rewarding because I could see machine code getting out very early in the writing process! Machine code is the real deal IMO.

Pretty impressive nonetheless! And I honestly never thought I'd see TempleOS being used as reference, because I feel like the majority of the code of TempleOS is a hopeless mess (not to mention that the only few files one gets are htmlified, and seem to be unrelated to eachother).