Hacker News Reader

Comment by PythonicAlpha | Hacker News Reader

When you program with today's tools and all that we have, you forget very fast, how it was in the beginning and how difficult it is to start from scratch.

Today you always have some sort of compiler or cross compiler. Starting totally with nil (not even an assembler) is really not so simple.

This little article shows nicely, how bootstrapping can work. Pulling myself out of the mud on my own hair (like the Baron Muenchhausen from literature).

But don't forget: He still had the operating system not bootstrapped ... so repeating the whole computer history would need some more bootstrapping to do ....

View on HN

Kind of on the contrary I feel like this is a great reminder of how possible doing very complicated things with much more rudimentary tools than we have available now is, and that we're really not so far from the 'ancient' ways than we like to think.

And though the product would be quite limited, if you're willing to rely on the BIOS doing this from a raw kernel implemented in itself wouldn't be that bad (and having a VM to do so faster would help, but booting off a floppy would still be possible). If anything it might make things a little simpler since you wouldn't have to even use a syscall to get memory, if you set up the pagetables to map to physical memory 1:1 you've got free reign.

And that would definitely be an interesting process to try to take this through.

The funny thing is that the EDSAC, one of the first functioning computers (perhaps the first, depending on how you define "functioning" and "computer") had a boot loader (the "initial orders") which was capable of manipulating single-letter address labels in a manner at least reminiscent of HEX2. (Or perhaps the reverse?) And in fact, this "annotated machine code" was how programs were generally written for the machine.

There are a lot of fine paywalled descriptions of the system. One that's generally available is in the documentation for the EDSAC simulator here (Tutorial Guide, chapter 3):

http://www.dcs.warwick.ac.uk/~edsac/ http://www.dcs.warwick.ac.uk/~edsac/Software/EdsacTG.pdf

This is what I as old beard find so bad in many online forums from young developers.

Back then, most of my peers could understand that implementation != language.

And as consequence, before Java became mainstream the majority of memory safe languages (e.g. Modula-2, Mesa, Algol,Oberon,...) actually had native compilers in most systems.

Nowadays most don't understand this, nor how bootstrapping works, a technique any CS student should be comfortable with.

A lot of us today (including myself) are bootstrapping our own CS education and cannot, in fact, build from bare metal. I, for one, learn more and more when people post things like this and I am also very grateful...and on my way to understanding implementation != language.

Something that would help is to do a lot of computer archaeology.

Many old papers and documents are now scattered around the web.

You would get to learn a lot from the days C was UNIX only, there was a lot of choice in programming languages and OSs to chose from.

Specially the whole explosion of home computers diversity and respective development environments.

Thanks for the comments. I am trying to read less HN and more of the C book. Really, I just need more time than 24 hours in a day.

If you're teaching yourself (what I assume you mean from bootstrapping), you ought to take a Coursera or EdX class on computer architecture or at least get a good textbook on the subject. The class should cover microprocessor architecture, assembly language and how the assembler works. My EE course on the subject at UT Austin used the 6800 micro family, and my CS friends at UT took a similar class that used MIPS.

And even if he were to write the operating system from scratch, he would still have "cheated" by not designing the hardware. I wonder how long it would take in man-years to recreate the entire chain all the way up to a simple C-like compiler. Still, fascinating work, and most of all a fascinating perspective. I for one haven't the slightest clue about how to program by directly inputting hexadecimal machine code.

Shouldn't take more than a couple of man-years if you got the right people together. A C compiler is still pretty low down on the toolchain, and there is a whole library of literature explaining how the technology below this level works.

I think the big restriction is how much existing technology you'd be allowed to use, and how functional/scalable the technology would have to be when you're done. I/O is a big hurdle. Do you have to design the graphics hardware yourself? Do you have access to modern photolitography? Are you required to create the monitor/keyboard yourself? Other input devices, like disk drives? Do you need presistent storage at all? Display? Etc.

Here's someone who started with the hardware, although he only ported existing software to it:

http://www.homebrewcpu.com/

He also assumed an editor.

I mused on this topic a few years ago (http://boston.conman.org/2009/11/05.1) only I started without an editor (just a command line on an operating system). But past that, it's neat to see he did something similar to what I proposed.

I'm curious to hear what you think about the various bootstrapping threads linked from my comment at http://www.reddit.com/r/programming/comments/9x15g/programmi.... Several of them were inspired by your blog post.

Reply on news.ycombinator.com