ack VS unix-history-repo

Here's the peephole optimiser file for the 68000 on the ACK, showing what kind of optimisations you can do: https://github.com/davidgiven/ack/blob/default/mach/m68020/top/table

The Amsterdam Compiler Kit: https://github.com/davidgiven/ack

Looking at the ACK assembler which dates from the 16-bit era (https://github.com/davidgiven/ack/tree/default/mach/proto/as), it seems to hold a bitfield which tells it whether variable-sized instructions have been shortened or not. Bits are only allocated for instructions which can change length. The downside is that if you have conditionals which turn on and off sections of source based on factors which can change from pass to pass, Very Bad Things happen because it doesn't keep a mapping of which bit corresponds to which instruction. Plus, an instruction can only be shortened once. IME a naive assembler needs multiple relaxation passes to get optimal results.

Here are some that are even older: https://github.com/davidgiven/ack/commits/default/Copyright

It's not strictly bare metal, but you might be interested in this: https://github.com/davidgiven/ack/blob/default/plat/pc86/boot.s It's the startup code for running C (and other languages) from a bootable floppy. It's known at boot time that you get at least 64kB of memory at 0x07c0:0000, so we just use that.

The 8080 is historically interesting, but in my personal opinion kind-of a rotten CPU to develop for... the assembly mnemonics came from a time when they haven't figured out a nice way to write them yet. Also, I don't think the CPU wasn't used in that many machines and it certainly isn't common now, and as a results compilers tend to be commercial and old. (One that is not commercial is the Amsterdam Compiler Kit, but good luck getting that to work, especially if you insist on Windows...) Generally compiled languages also tended not to be used that much around that time, the lingua franca still was assembly.

There is also https://github.com/dspinellis/unix-history-repo (Continuous Unix commit history from 1970 until today)

FWIW, ls in Research-V6 back in 1975 had 10 options. https://github.com/dspinellis/unix-history-repo/blob/Researc...

By BSD 3 in 1980 it had 11 options. https://github.com/dspinellis/unix-history-repo/blob/BSD-3-S...

The thing is, we can see even from the 1970s 'ls' how the Unix model doesn't meet the goal "to chain these simple programs together to create complex behaviors".

There is no option to escape or NUL terminate a filename, making it possible to construct a filename containing a newline which makes the output look like two file entries.

The option for that was added later.

There's also the issue that embedded terminal codes will be interpreted by the terminal.

This is what it looked like about 7-8 years earlier: https://github.com/dspinellis/unix-history-repo/blob/BSD-1/e...

RA92 (1989): 16 ms / 8.3 ms.

Note that the RL02 (and V7) and RA92 mentioned in the article are separated by about a decade.

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...

The earliest version I could find [1] is already written in C.

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...

Here's a 1997 citation for "top cpu processes." It's not as close to the original 1984 release as I would like, but it's better than Wikipedia. https://github.com/dspinellis/unix-history-repo/commit/aee34003d7964653c44c31f5bf6bcf136b32c4f3

> The “why” goes into the PR and more importantly, engineering documentation and inline comments

This just ensures that the “why” is lost when someone comes looking years later.

From experience, SCM metadata is far more durable than just about any other work product we produce. Five decades later and RCS commit info was still available for the Unix sources, and history could be reconstructed: https://github.com/dspinellis/unix-history-repo

I’ve used 35-year-old commit messages to help understand a long-standing issue, decades after all other related organization tooling and data had disappeared.

P.S. I remember I looked into early versions of C (they survived in Unix historic releases) and that, finally, revealed to me why C does something really stupid and conflates arrays and slices (pointers). Initially C had no arrays! Or, rather, what it called arrays were, actually, pointers. “Normal” arrays were added at some point, but because these weird slices/pointers were already there that caused endless confusion. It wasn't resolved before C became popular and after that it was too late. Go repeated that mistake with slices, of course.