My personal perspective is that computing has become much more complicated than necessary in the past decades. Of course abstraction will always create complexity, and some of that can hardly be avoided, but in computing these days complexity is really off the charts.

So for this book I chose a platform that is easy to understand and does not make you wade through tons of abstractions that are only loosely related to compiler construction (e.g. ELF object file format).

Here's one way to avoid going into detail on ELF: https://news.ycombinator.com/item?id=38592000

"(nearly) constant" means you can pick either (a) a constant blob, at the cost of a fixed image size, à la COM, or (b) patch up length (one or two places, iirc) if you're feeling fancy.

In one of my other compiler books (http://t3x.org/t3x/book.html) I just use a template for the ELF header, but I still think it adds too much complexity. One reader complained about it.

found it: elfheader() in https://t3x.org/t3x/t.t.html

fwiw, I think you commented it very nicely; de gustibus!

Did you come up with if vs. ie ... else ... independently or inherit it from BCPL?

> fwiw, I think you commented it very nicely;

Thanks, I thought so, too, but I can also understand that the comments are not very helpful, if you know nothing about linkers, paging, and object files.

I think I adopted IE/ELSE from BCPL, but thought that IE is nicer than TEST, because it is itself short for If/Else and because it looks almost like IF.

> de gustibus!

Funny, I just started to brush up my Latin! :)

Having very much enjoyed LFN, I think your taste in where to simplify suits me, at least.

I doubt I'll ever get around to it but I'm sort of tempted to see if I can remember enough arm26 assembler to try and get it to compile to that (arm26 does have multiply but not divide, I'd have to dig out the 'standard' fast division asm block that was passed around amongst Archimedes authors back when that was my primary platform).

Just bought a copy so I should at least get as far as "I've read the book but not got around to the arm26 part" though :D

What is ARM26? I know ARMv6, and a T3X/0 back end for the ARMv6 would be seriously cool. So cool in fact that I might write it myself. :) Here is an unsigned divide for the ARMv6 that I borrowed for the SubC compiler: http://me.henri.net/fp-div.html In fact the sources for the SubC compiler might serve as a pretty good foundation for porting T3X/0 to the ARMv6.

The ARM 2 chip in the early Archimedes machines was a 32-bit chip with 26-bit addressing so it got referred to as arm26 assembler (I'm not sure if that's technically -correct-, but I'm pretty sure it was in the title of the book I learned from and there's a directory in linux kernels that support that arch called asm-arm26 at least, so my memory isn't -just- making it up ;).

I would align with this philosophy as it relates to learning. Complexity is a likely a necessity of technological advancement, but a hinderance to 'from-scratch' learning. Abstractions hide many details that may not be needed to operate, but are needed to understand.

The entire retro-computing field is interesting and a bit surprising in it's strength. I would not have guessed that in 2023 an IMSAI 8080 would be selling for ~$3-5k, and that there would be such an active community of people doing things in CP/M. Nor would I guess that I would be working on either of these!

One of the most enjoyable personal projects that I have worked on was the creation and implementation of a CPU, starting with the concept ISA and building the microarchitecture, making lots of cool mistakes that require rework, and eventually having a booting CPU running code in an assembly language of my own. While the performance of a CPU like this is closer to the computational power of my coffee maker, it is still an excellent experience.

I ordered my copy of your book and am looking forward to reading it!

Newer compilers or other low level programs have become extremely complex. There a loads of features or optimizations which are not strictly necessary but still add a lot of complexity Attemptting to explain how modern compilers work would most likely result in lots of confusion.

For me the interest in retro computing is that the computer is so much simpler that it is indeed possible to understand. The set of assembly instructions is small enough that a person can understand every opcode fairly easily, the amount of memory is limited, and the list of things that that your installed ROM can do is relatively accessible. Contrast that to modern machines and operating systems, and no mere mortal can understand everything that is happening in the machine.

Another thing to love about retro computers is how transferrable the knowledge is to modern machines. Once you know the essence of assembly language on a retro computer, you have a good basis for learning RISC-V or something else modern.

Depending on where your son is at, he might enjoy this video where I explain the essence of assembly language-- it's the video I wished someone had shown to me when I was a kid and thought I wasn't smart enough to learn it.

https://www.youtube.com/watch?v=ep7gcyrbutA

Its sort of like how in a lot of universities when taking a computer architecture course, the focus is usually on MIPS or RISCV or LC-3 and not something like a modern x86_64 processor. Tons of books exists to teach computer architecture in these architectures. They are also small, compact, and straight forward. You can understand every thing in 6502 or simple MIPS processor from logic gates, instruction set and how pipelining instructions work and branch prediction. I could be wrong, but if I had to guess, not even an engineer at Intel can break down their current processors and have all of that fit into their head.

Retro stuff also presents a challenge. There is a guy who writes some crazy software for I believe the Mac-II. It can be a great test of skill to take an old machine have it capable of doing modern things, because it requires getting knee deep in the weeds on optimization and such. One issue I think we have in software is, modern machines are really powerful. To the point of even shitty un-optimized code in average use cases can run decently well. Targeting these kinds of machines can help build those skills in learning how to optimize because, well, you would actually have to optimize to get these older machines to do modern things.