A little knowledge is dangerous

Paw Prints: Writings of the maddog
From time to time I advocate that every programmer learn at least one assembler language. Not that I would ever advocate writing in assembler language when a higher-level language would do, but because assembler allows you to see how the machine really works, and can help you understand other topics such as operating system architecture and compiler design. In fact, I advocate that programmers learn a little bit about digital logic and how digital gates such as AND and OR gates combine to create registers, memory and other computer structures.
Many years ago I started work for Aetna Life and Casualty as a young programmer.
One of the other programmers had written a program that ran very slowly on an IBM mainframe. Interestingly enough, when his program ran, all of the other programs on the system ran slower, and even all the programs on any system even remotely connected with that system ran slower.
Mystified, my boss asked me to look at his program and see if I could figure out what was wrong.
The first thing I found was that he had written part of the program in Fortran, part in Cobol, part in assembly language, part in PL/1 and part in SNOBOL. It was fortunate that I knew all of those languages, so I waded into the code to see if I could find what was wrong.
After a while I decided to run a profiler on the code, which would show me how much real time each of the modules was taking. I found that the assembly language program was taking the bulk of the processing time. Next I profiled just the assembly language program and found that one machine language instruction was taking about 99% of the wall clock time that the program was using.
I got out the Principals of Operations of the IBM 370 computer, which told how each assembly language instruction worked, and what it did, and found that the instruction that he was using was “read the clock”. Now this would seem like a harmless enough instruction, until you realized how “read the clock” was typically used. It was used to synchronize locks for controlling multiple CPUs. Therefore, before the clock value could be read, all of the I/O had to some to a halt and all of the caches had to be
flushed not only on your system, but every system that was communicating with that mainframe. Then, after the entire machine was quiescent, the clock would be read, assuring that there would be only one value of that clock in the whole system. Then everything started up again, with the caches refilling and the tape and disk drives starting to fill their caches.
And the program was executing that instruction for every tape record the program read, typically millions of them every night.
I asked the programmer why he was using that instruction in his program. “I wanted to find out what day my program was running,” he said. “What DAY?”, I asked. “If that was the goal, couldn't you have just read the value one time and stored it in a variable?”
“Then I would be wasting memory.” he said.
But I made him change his program and instead of taking ten hours a night to run, it ran in only fifteen minutes, and all the other programs executing simultaneously on every other CPU just kept running normally, not slowing down to a crawl when his program ran.
As I put away the profiling charts, I asked him, “Why did you write your program in so many different languages?”
“Oh,” he said, “I was taking a course which compared different languages, so I wrote in whatever language I was studying that week.”
I congratulated him for having a job for life, as nobody at Aetna other than he and I knew all of those languages.
Carpe Diem!
Comments
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

News
-
System76 Releases COSMIC Alpha 7
With scores of bug fixes and a really cool workspaces feature, COSMIC is looking to soon migrate from alpha to beta.
-
OpenMandriva Lx 6.0 Available for Installation
The latest release of OpenMandriva has arrived with a new kernel, an updated Plasma desktop, and a server edition.
-
TrueNAS 25.04 Arrives with Thousands of Changes
One of the most popular Linux-based NAS solutions has rolled out the latest edition, based on Ubuntu 25.04.
-
Fedora 42 Available with Two New Spins
The latest release from the Fedora Project includes the usual updates, a new kernel, an official KDE Plasma spin, and a new System76 spin.
-
So Long, ArcoLinux
The ArcoLinux distribution is the latest Linux distribution to shut down.
-
What Open Source Pros Look for in a Job Role
Learn what professionals in technical and non-technical roles say is most important when seeking a new position.
-
Asahi Linux Runs into Issues with M4 Support
Due to Apple Silicon changes, the Asahi Linux project is at odds with adding support for the M4 chips.
-
Plasma 6.3.4 Now Available
Although not a major release, Plasma 6.3.4 does fix some bugs and offer a subtle change for the Plasma sidebar.
-
Linux Kernel 6.15 First Release Candidate Now Available
Linux Torvalds has announced that the release candidate for the final release of the Linux 6.15 series is now available.
-
Akamai Will Host kernel.org
The organization dedicated to cloud-based solutions has agreed to host kernel.org to deliver long-term stability for the development team.
Assembly language
I couldn't agree more with your recommendation to learn a bit of assembly - by giving you a "glance under the hood" at how the underlying system actually works, the perspective gained can be invaluable.
When I was in high school back in the '70s, our school was hooked up to a regional timesharing system (SETS in Waltham, MA, if you remember them) that ran a DEC PDP-8/i, with a PDP-8/e handling the I/O. After familiarizing myself with the DEC BASIC that was the primary programming language available on the PDP-8s, I sent away to Maynard for the book on the PAL III assembly language that the PDP-8 family used, and wrote a few small programs in that.
I may not have done all that much with the language overall, but merely having been exposed to the concepts involved was all the reward I could have asked for, for the time invested. I cannot count how many times that added perspective has come in handy, on pretty much every platform with which I've worked over the years that followed.
Terrific article, and sage advice.