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.

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.

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:

• add a new subscriber
• unsubscribe a current subscriber
• notify subscribers
• make its state known

An input needs to:

• 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

Inputs and Outputs 2: input limitations

It seems obvious that an output can push its charge to any number of inputs. What's less obvious is whether multiple outputs can feed into a single input.

Expanding on our trusty light bulb setup from last time: instead of having 1 power source + switch before the bulb, lets have 2 sets like this in parallel. Now if either switch (or both) are closed then the bulb lights up.







Stand in awe of my mighty illustration skills!

There are a few ways to handle this:

1. The bulb's input can accept from multiple output sources
2. The output sources combine into 1. If either or both sources are charged, the bulb lights up. This is an "OR" relationship. Expanding on that:
3. The sources must enter an OR gate and the single output from that gate will be the bulb's input

These solutions go from most simple to most complex, so why don't we choose the 1st and simplest? Actually, there is a reason and it's largely academic. What we're doing in sHs is an exercise in "sequential logic." That is: using boolean (on/off) values, we're moving in a linear sequence, evaluating as we go. This is a very old idea and there are certain conventions that are used. #3 above follows said convention.

Make no mistake, we are in no way bound by these conventions. There are no teachers standing over our shoulder ready to whack our knuckles for doing our program in an unorthodox or colloquial way. Back in Transistor choice when we were trying to choose whether to use MOSFET+CMOS logic, I had no problem justifying a simpler way of doing things. However, in this case, I'm still going to opt for #3 anyway because it makes sense in my mind.

Regardless of which option you prefer though, we should all agree on one important point: the multiple inputs must resolve to a single collective ON or OFF value before we can determine whether the bulb should light. Any of the 3 above can achieve this.

Inputs and Outputs 1: push or pull?

Pushing vs. Pulling

I made an assumption in the last post: that outputs would give their values to inputs. Why couldn't it be the input's job to get their value from the output? (In programming, this give vs. get distinction is often referred to as pushing vs. pulling.)

The first reason to push is because it's intuitive. Why is it intuitive? Because that's how it works in real life. Why not make our programming metaphor follow reality when we can?

Here's a simple example: Let's say we have a simulation with a power source, an open switch, then a light bulb. Now we'll close the switch.

• Push: when the switch is closed, it pushes its new "on" state to the light bulb and the bulb lights up.
• Pull: when the switch is closed, the light bulb somehow knows to inquire whether the switch's state has changed. If the switch is still open, the bulb stays out, else it lights up.

To me, the pull method seems backwards. How does the light bulb know to inquire? There are actually plenty of common and logical solutions to these kinds of problems, but for now I see no reason why we shouldn't stick with the push method.

Code Downloads!

Downloads of all softHARDsoft code can now be found here: http://downloads.softhardsoft.com/

Reminder: the license I'm releasing the code under is Creative Commons: Attribution-Share Alike 3.0 Unported

The page will remain pretty Spartan but functional. Enjoy!

Zen of a Virtual Circuit

In How to make a machine "think" we considered a basic logic where:

• Any piece's output can be another's input.
• Use only 0 and 1 (boolean: TRUE and FALSE).
  

By meeting our second requirement (ie: by only passing around boolean values), we also satisfy our first requirement. If some items only accepted numbers, some only letters, and if outputs were similarly varied, then we'd have to specialize families of circuits right off the bat. As it is, all inputs and outputs are of the same type: boolean. Need the output of an OR gate to be the input to a transistor? No problem. Any output can go to any input as-is.

We now have the foundation for an infinitely modular system -- Logic LEGOS!*

So what is a circuit?

In a general sense, any piece of logical hardware can be a circuit. Any collection of circuits can also be considered a circuit:

• transistor
• inverter
• full adder
• Pentium processor
  

This is the beauty of our modular, LEGO-like architechture. With "circuit" being such a flexable term, we can build any manner of abstraction, and to us it's still just a circuit. It can still connect with any other circuit irrespective of how work is being done inside each one.

Not that there aren't differences. Never mind the stuff inside. The outsides are very different too. Transistors have 2 inputs and 1 output. Inverters: 1 in, 1 out. Full adders: 3 in, 2 out. The Pentium processor, lots of each. Obviously we won't be able to statically define how many inputs and output a circuit can have. But we do now have some basic definitions for our first interfaces:

Circuit: has some number of inputs and some number of outputs
Input: accepts a boolean value
Output: each emits a boolean value

All of our circuits, no matter how simple or complex, will boil down to this. They'll have some number of inputs, some outputs, and stuff hidden in the middle to turn inputs into outputs.

That's about all there is to say about this layer of the onion. Next we'll dig deeper on how our inputs and outputs need to relate to each other.

CODE: http://downloads.softhardsoft.com/2008-09-11.zip


* From wikipedia: "The word LEGO® is a brand name and is very special to all of us in the LEGO Group Companies. We would sincerely like your help in keeping it special. Please always refer to our bricks as 'LEGO Bricks or Toys' and not 'LEGOS.'"

Yeah, well build a bridge and get over it. I've never met anyone who calls them "LEGO Bricks or Toys." Like it or not, everyone outside of that company calls them "LEGOS." I have nothing but the greatest admiration for these toys, but I have no use for their PR pride.