United States - Flag United States

Please confirm your currency selection:

Bench Talk for Design Engineers

Bench Talk

rss

Bench Talk for Design Engineers | The Official Blog of Mouser Electronics


Tools Bridge The Chasm Between Hardware and Software Arden Henderson

 

Suppose some hardware folks somewhere invent a machine made of hardware that does something when it carries out a series of instructions. The instructions will be in a language the machine understands.

Instructions for the machine are written in the "machine language" of the hardware, sometimes called "machine code." The machine language is the final low-level language in the journey from high level language to low-level language, resulting in correct instructions that do something useful; it is the language the machine understands.

Usually (though not in every case), the machine language is designed with only the machine in mind, not the human. Or mostly with the machine in mind, the people writing software for the machine a mere afterthought. If a person was to write instructions for the hardware using the machine's own language, it would be a tedious task of writing out the machine instructions as they actually exist inside the machine.

Why might it be tedious? In a digital machine that can execute instructions, the instructions, and memory and anything else, are all represented as digital information. (Unless it's an analog machine. That's a different department -- two doors down on the right.)

Back to the tedium: In the (digital) machine, instructions will be represented digitally. Ultimately, everything "digital" sooner or later means "binary." Think of it as simply off or on, usually represented in (human) writing as 0 and 1. To give the machine instructions, one could write out the instructions in binary representation and somehow get those instructions into the hardware. As typed (by a human in a some blog on some website) one such machine instruction might look like this: 00101111011011101

Simple, right? Readable and easy to remember, not so much. If the instruction 00101111011011101 actually meant something and was executed in some machine that understood the instruction, it might make the machine do something (or not). The hardware designers could, say, design a machine to quack like a duck when the instruction (machine code, remember) 00101111011011101 was executed in the machine.

Wait. We should probably talk about what "executed" means here. It simply means the instruction is invoked, made to happen, kicked into gear, fired up. The machine does what the instruction says to do when the instruction is "executed." Same thing as the instruction "wash the dishes" results in (eventually, usually) clean dishes. "Load and start the dishwasher" could be an instruction as well, with the same results.

In the early days, hardware (a machine that executed instructions) which ran software (a list of instructions) was programmed in just that way, in machine language, the language that the machine understands, by laboriously entering instructions written in machine language one-by-one. (By the way, "software" is an overloaded word; as noted above, here we mean a list of instructions.)

A high rate of turnover of software developers (called "programmers") soon became apparent, back in those ancient days of programming machines with instructions in machine language. Programmers often ran screaming from their cubicles to work in jobs less painful than writing and testing software in machine language, such as sorting small rocks by shape, color, and texture for landscapers or counting bird seed to ensure exact counts in bird seed packages.

What happened next? How might things be made easier than writing binary instructions in the machine's specific language? Just like all the humans before them, the people responsible for getting the early programmable digital machines to do something useful, or at least amusing, began to invent tools to make their jobs easier. (I see a show of hands. No, no. Hexadecimal notation is just another way to represent digital information. It is not a tool. Not like what we're fixin' to discuss.)

Anyway, what was (and still is) really cool, after some tools were invented, those tools were used to build more tools. And so on. We'll talk about that and more in the next installment.



« Back


Arden Henderson spent at least part of his life toolsmithing in dark, steam-powered workshops of software tool forges long gone, drenched in blood, sweat, and code under the glare of cathode ray tubes, striving for the perfect line of self-modifying software and the holy grail of all things codecraft: The perfectly rendered pixel. These days, when not working on his 1964 Flux Blend time machine (which he inadvertently wrecked before it was built after a particularly deep recursive loop), Mr. Henderson works in part-time castle elf and groundskeeper jobs, chatting with singularities spawned from code gone mad in vast labyrinths of vacuum tubes, patch cords, and electro-mechanical relays. Mr. Henderson earned a B.S.C.S. late in life at Texas A&M. Over the hundreds of years gone by before then and after, he has worked in various realms ranging from petrochemical wonderlands spread across the flat Gulf Coast saltgrass plains, as far as the eye can see, to silicon bastions deep in the heart of Central Texas.

All Authors

Show More Show More
View Blogs by Date

Archives