My copy of The Elements of Computing Systems (TECS) arrived in early August and I finished it yesterday (Sept. 29). In just under 2 months, I built a virtual computer from scratch.
Starting with NAND gates and flip-flops, TECS guides the reader through building all combinatorial and sequential chips, building the ALU, memory, CPU, machine and assembly languages, an intermediate language, a high-level language, and a common language library / operating system. This book is a wonder. It teaches very effectively and comes with a small library of extremely useful and easy to use tools. (In contrast, I made very little headway with sHs, mostly because I was starting with building the tools. While this isn't a bad place to start when the tools do not exist, it was very distracting and kept me at a distance from the real design goals.)
TECS realized the sHs dream in every way and much, much more. It is no simple textbook. It is a lab manual for a self-guided study in building every element of a computer.
Wednesday, September 30, 2009
Friday, July 31, 2009
Mockups
To this point, we've had source code with no visualization. Outside of the view of the readership, I have been trying to build tools so we can see some of the code at work. It'd be nice to have some way to view these emerging circuits other than with a debugger.
As mentioned in the last post, due to finding The Elements of Computing Systems: Building a Modern Computer from First Principles, I'm abandoning this these efforts. However, I thought it was worth noting a bit of the process of building these tools -- at least the initial mockup phase.
I've tried mockups about every way imaginable over the years and nothing beats good ol' pen/pencil + paper. When you use anything digital, you spend more time learning the tool than doing the mockup. When the mockup is done, people expect it to be a pixel-perfect rendition of the final product. (Obviously, no one expects this with pencil and paper.) This is to say, mockup software has all the traits that are typical of almost all drawing software: steep learning curve, abusive UIs, they make perfect little boxes with crisp edges, etc. In short, they usually come down to: glorified MS Paint, glorified PowerPoint, or underpowered Photoshop.
Much to my surprise, I heard of one digital tool (via the Stack Overflow podcast) that may have changed the way I do mockups. It's called Balsamiq. Balsamiq does one thing and it does it well: quick, low fidelity mockups. The interface is pretty intuitive also. It directly addresses my biggest problems with doing digital mockups -- no small feat when you consider how antithetical my needs are to most of what most software does best.
My only real gripe about Balsamiq is its price. I'm sure $80 is nothing to a company, but for a solo hobbyist it's prohibitive. Fortunately, there's a limited free version. The lack of being able to save in the free version hurts a bit, but you can't beat the price. (Full disclosure: I'll hopefully get a free license for this blog post but I wouldn't have bothered if I didn't like the product to begin with.)

Check out their demo to see Balsamiq in action.
[Update: A member of Balsamiq read this post and reminded me: "When you use the free version online or the free demo, use export/import to save your work." Great tip!]
While I may or may not ever get back to doing sHs, it likely won't be until after I've learned all I can from The Elements of Computing Systems. After that, I might continue to make my tools behind the scenes (probably using Balsamiq). However, I hesitate to make too many predictions.
As mentioned in the last post, due to finding The Elements of Computing Systems: Building a Modern Computer from First Principles, I'm abandoning this these efforts. However, I thought it was worth noting a bit of the process of building these tools -- at least the initial mockup phase.
I've tried mockups about every way imaginable over the years and nothing beats good ol' pen/pencil + paper. When you use anything digital, you spend more time learning the tool than doing the mockup. When the mockup is done, people expect it to be a pixel-perfect rendition of the final product. (Obviously, no one expects this with pencil and paper.) This is to say, mockup software has all the traits that are typical of almost all drawing software: steep learning curve, abusive UIs, they make perfect little boxes with crisp edges, etc. In short, they usually come down to: glorified MS Paint, glorified PowerPoint, or underpowered Photoshop.
Much to my surprise, I heard of one digital tool (via the Stack Overflow podcast) that may have changed the way I do mockups. It's called Balsamiq. Balsamiq does one thing and it does it well: quick, low fidelity mockups. The interface is pretty intuitive also. It directly addresses my biggest problems with doing digital mockups -- no small feat when you consider how antithetical my needs are to most of what most software does best.My only real gripe about Balsamiq is its price. I'm sure $80 is nothing to a company, but for a solo hobbyist it's prohibitive. Fortunately, there's a limited free version. The lack of being able to save in the free version hurts a bit, but you can't beat the price. (Full disclosure: I'll hopefully get a free license for this blog post but I wouldn't have bothered if I didn't like the product to begin with.)

Check out their demo to see Balsamiq in action.
[Update: A member of Balsamiq read this post and reminded me: "When you use the free version online or the free demo, use export/import to save your work." Great tip!]
While I may or may not ever get back to doing sHs, it likely won't be until after I've learned all I can from The Elements of Computing Systems. After that, I might continue to make my tools behind the scenes (probably using Balsamiq). However, I hesitate to make too many predictions.
Friday, July 17, 2009
The Elements of Computing Systems
I just discovered the book The Elements of Computing Systems:Building a Modern Computer from First Principles by computer gods Noam Nisan and Shimon Schocken. This book achieves everything that I want to do with softHARDsoft plus way more and with superb skill. (The only thing it doesn't do that I was going to was to start from one level down -- at the transistor level instead of at the NAND level.)
Schocken, and his decade of teaching experience, painstakingly detail a 1 semester course that completely builds a computer out of primitive first principles. The only prerequisite is some programming knowledge. Starting with the constant FALSE and a NAND gate, he builds an entire functional computer. Additionally, a fantastic suite of free tools are available on his website (see link below) to facilitate at every step of the way.
The astute reader will notice that, among other things, omitted from this set is a clock. I haven't yet figured out how he compensates for this but my guess is that it's black-boxed in the simulation software.
Since I fear that I haven't many (any?) readers anyway and since this book renders my efforts fairly impotent, I'll abandon sHs. This may be either temporarily or it may be permanently. I suppose it will depend on whether I can't find an appropriate new focus that makes it worthwhile.
In the meantime, I wholeheartedly, albeit jealously, recommend this book. Here are related links:
Website for the book including all PowerPoint slides and software
http://www1.idc.ac.il/tecs/
From Nand to Tetris In 12 Steps (9:26)
http://www.youtube.com/watch?v=JtXvUoPx4Qs
From Nand to Tetris in 12 steps at Google Tech Talks October 10, 2007 (1:01:05)
http://video.google.com/videoplay?docid=7654043762021156507
Now if you'll excuse me, I have a book to start.
Sunday, July 12, 2009
The Machine That Changed the World
Another detour from the creation of our virtual computer:
On waxy.com, Andy Baio has uploaded the series The Machine That Changed the World. This 5 part miniseries from 1992 feels dated for obvious reasons but the history is as relevant as ever. The making of this documentary was particularly well timed -- there are interviews with several computer pioneers -- many of whom passed away within a few years of its filming.
It was digitized from VHS so the image quality leaves something to be desired. However, this is the first time this classic series has been digitized at all and Waxy.com was kind enough to put it online so we can all enjoy it. You can stream the videos online as flash or download the high-quality MP4 files via BitTorrent.
Much thanks to Waxy.com for making this gem accessible to all!
On waxy.com, Andy Baio has uploaded the series The Machine That Changed the World. This 5 part miniseries from 1992 feels dated for obvious reasons but the history is as relevant as ever. The making of this documentary was particularly well timed -- there are interviews with several computer pioneers -- many of whom passed away within a few years of its filming.
It was digitized from VHS so the image quality leaves something to be desired. However, this is the first time this classic series has been digitized at all and Waxy.com was kind enough to put it online so we can all enjoy it. You can stream the videos online as flash or download the high-quality MP4 files via BitTorrent.
Much thanks to Waxy.com for making this gem accessible to all!
Thursday, July 9, 2009
Reckoners
We're examining the base elements of a computer to build a conceptual one of our own. In the post How to make a machine "think" we settled rather easily (too easily?) on the idea of using binary for the basis for our computer's anatomy. There are very good reasons for this but the main one is that we're constructing a modern styled computer and are thus doing stuff like they do it. Is this the only way? Have computers always been this way?
The answer to both questions is a resounding NO.
To see how we got where we are, we simply have to look to our history. The era of the very first digital computers is one place to look. By definition, these machines were built before computer science or such theory. The pioneers had no roadmap to follow. Great ideas, trial and error, and creative minds had to fill in all the gaps without Charles Petzold to be their muse!
Would the pioneers have chosen to use binary? Did the first general purpose computers have memory parts separate from arithmetic parts? Why did some choose binary and some choose decimal? These are not trivial questions. The answers show us where we started, how we got where we are, and why.
Maybe we should totally stop designing a computer for a while and review these innovative decisions. Maybe we should, but we won't. We've had quite enough detours for a while. However, I highly encourage you to read up on the matter.
One excellent (and free) resource is Reckoners by Paul E. Ceruzzi and it's free online. Reckoners looks at the creation and anatomy of some of the worlds first general purpose digital computers. It can be a bit dry at times when it delves into too much detail, but overall it is a fantastic book. If nothing else, it's absolutely worth reading the chapter on the very first completed digital computer. Only a German engineer could possibly have conceived of and then built computer memory units using moving parts -- no transistors (they didn't exist yet), no relays, just machine!
The ancient history of computers is absolutely fascinating. Anyone interested in a grassroots project like softHARDsoft will love reading about the original beasts.
The answer to both questions is a resounding NO.
To see how we got where we are, we simply have to look to our history. The era of the very first digital computers is one place to look. By definition, these machines were built before computer science or such theory. The pioneers had no roadmap to follow. Great ideas, trial and error, and creative minds had to fill in all the gaps without Charles Petzold to be their muse!Would the pioneers have chosen to use binary? Did the first general purpose computers have memory parts separate from arithmetic parts? Why did some choose binary and some choose decimal? These are not trivial questions. The answers show us where we started, how we got where we are, and why.
Maybe we should totally stop designing a computer for a while and review these innovative decisions. Maybe we should, but we won't. We've had quite enough detours for a while. However, I highly encourage you to read up on the matter.
One excellent (and free) resource is Reckoners by Paul E. Ceruzzi and it's free online. Reckoners looks at the creation and anatomy of some of the worlds first general purpose digital computers. It can be a bit dry at times when it delves into too much detail, but overall it is a fantastic book. If nothing else, it's absolutely worth reading the chapter on the very first completed digital computer. Only a German engineer could possibly have conceived of and then built computer memory units using moving parts -- no transistors (they didn't exist yet), no relays, just machine!
The ancient history of computers is absolutely fascinating. Anyone interested in a grassroots project like softHARDsoft will love reading about the original beasts.
Thursday, March 26, 2009
Inputs and Outputs 4: output limitations
We're now clear on the limitations of inputs. What about limitations on outputs?
We actually kinda covered this in the bottom diagram back in Art Imitating Life. This was a diagram of sequential logic.
Notice the output of the left-most element. It splits and gives its value to the inputs of multiple other elements. One could argue that the node where the split occurs is its own element, but I think that's overkill. For our design purposes, let's just say that an output can give its value to any number of inputs. Or to use our new terminology about the observer pattern: a subject (i.e.: an output) can notify any number of subscribed observers (inputs).
Short post this time. Not much to say about this topic but it still needed to be said.
We actually kinda covered this in the bottom diagram back in Art Imitating Life. This was a diagram of sequential logic.
Notice the output of the left-most element. It splits and gives its value to the inputs of multiple other elements. One could argue that the node where the split occurs is its own element, but I think that's overkill. For our design purposes, let's just say that an output can give its value to any number of inputs. Or to use our new terminology about the observer pattern: a subject (i.e.: an output) can notify any number of subscribed observers (inputs).Short post this time. Not much to say about this topic but it still needed to be said.
Wednesday, March 25, 2009
Inputs and Outputs 3: subscriptions
There was a major to-do item from our last code post (9-11-08): how does the input find out about the value of the output? We know from the "push or pull?" post that the outputs will push their value to the inputs -- but how? Whenever an output changes it needs to know who to tell. The input that wants this information needs to tell the output: as soon as you change, tell me. This relationship (as implied by the title of the post) is that of a subscription service (outputs) and subscribers (inputs).
An output needs to provide a way to:
In the programming world, this is not a new problem. There is a time-honored solution to this called the "observer pattern." The pattern describes Subjects and Observers which correlate exactly to our Outputs and Inputs. This problem is so common that in .NET they built in a way to do most of this work for you: .NET, "Events" will give you all of this. Since we're doing this in C# anyway, I'm opting for events. Events have added benefits which we may also take advantage of later.
CODE: http://downloads.softhardsoft.com/2009-03-25.zip
An output needs to provide a way to:
- add a new subscriber
- unsubscribe a current subscriber
- notify subscribers
- make its state known
- be updated when a change occurs
In the programming world, this is not a new problem. There is a time-honored solution to this called the "observer pattern." The pattern describes Subjects and Observers which correlate exactly to our Outputs and Inputs. This problem is so common that in .NET they built in a way to do most of this work for you: .NET, "Events" will give you all of this. Since we're doing this in C# anyway, I'm opting for events. Events have added benefits which we may also take advantage of later.CODE: http://downloads.softhardsoft.com/2009-03-25.zip
Subscribe to:
Posts (Atom)