I was more interested in hardware than software in the late 70s and early 80s. Microcomputers were appearing everywhere, so I couldn't ignore software for long. Like a lot of people, I learned BASIC on an Ohio Scientific Challenger II in high school. That BASIC interpreter was developed in assembly by none other than Bill Gates and Paul Allen. I think they did well with it.

From then on, I had one foot in the hardware world and the other in software. This was the start of a 20 year transition to software. Here's a rough timeline:

• 1980 - learn BASIC
• 1982 - step up to minicomputers
• 1984 - dive into the Macintosh
• 1989 - my first real program
• 1992 - signal processing
• 1995 - download Netscape 2.0 Beta with Java support

My recent interests have turned to compiler optimization and code generation. This was triggered partly by JVM work on the JNode all Java operating system. I've been in the process of developing a lightweight, retargetable, optimizing code generator. So far, I have the following pieces in place:

• SSA construction using dominance frontier computation
• low cost, high value optimizations, e.g. copy/constant propagation
• linear scan register allocation

I am now in the process of developing a retargetable code generator based on bottom up rewrite (BURS) techniques. This is used effectively in the LCC compiler.

What can you do with 8 bits? (1980)

That's what I asked my brother when he tried to explain 6502 assembly language in high school. It took me a while, but I eventually got it.

Idle hands (1982)

As a summer intern at NASA Goddard in the early '80s, I had access to the last of the semi-integrated SSI computers. The Xerox Data Systems Sigma series computers competed with IBM 360 series mainframes. I had a lot of time on my hands, so I read a lot of Xerox manuals. One thing Xerox knew how to do well was produce documentation, well written documentation.

I learned assembly language on my own and wrote a disassembler. Binary images of mose software was statically linked and loaded, so it was relatively easy to reverse engineer. System software was a black art in those days, so I learned mostly from reading disassembled code.

I spent a lot of time trying to break into the system account, with little luck. I read that on bootup, the system password is blank and the first login sets that password. I would wait patiently on Monday mornings for the telltale bling-bling of the terminals. Quickly I would enter the system user name and a blank password. Usually I was too late, but once, and only once, I got in. Not soon after a very terse message was sent from the operators console:

The system operators were in another building, but I was high school kid, I feared for my life! I logged off. I worried someone would have traced the terminal port and come after me. Fortunately, that never happened.

Close scrutiny of the operating system data structures revealed that the user name and privelege was stored a block of protected memory known as the Job Information Table (JIT). I wrote a quick program to jam values into that table only to be rejected by hardware memory protection. I discovered that a program executed from the system account executes with high privelege. I noticed that a stray log file in the system account was writable by everyone. I copied my jam program there and ran it. Nothing happened. My program ran and completed normally. No memory exception trap that usually ocurred. I checked my user information:

I was in! First things first: copy the :USERS file containing all the user/password information. I printed it only to find that the passwords were all hashed! I didn't know much about security in those days, but I learned quickly.

I came up with a sinister scheme to grab passwords, though. After disassembling the login program, I found that the algorithm used to hash passwords lay at the very end of the code page. There were at least a few hundred bytes remaining in the page. That was enough for me to squeeze in a little password logger and put that back into the system account. That was too much for me. Just knowing I could have done it was enough.

I always liked operating system internals, compilers, and other system software. Years later, I would put my interest to work in the real world.

Fun with Turbo C 2.0 (1989)

I worked on ground systems for satellite instrumentation in my first full time job. Testing in the aerospace industry was really boring in those days. Lots of switching this on, checking the voltage and current, writing it down. That wasn't too much tedium for me and my handwriting wasn't that good anyway. I figured that a computer could do a much better job, they have more patience than I do.

The problem was that writing a test procedure wasn't easy on DOS machines in the late 80s. I needed multithreading, dynamic binding, and high reliabilty. All of the features of Java, but wouldn't be public for several years. During the winter holidays, I started writing a lexical analyzer similar to UNIX Lex or Flex. I needed that to build a compiler for my test language.

I built a recursive descent parser that generated P-code, very much like UCSD Pascal or even the Java Virtual Machine (JVM). I built a robust, typesafe runtime environment on top of our ground support software. Now I was able to run automated tests in 20 minutes that sometimes required 3-4 engineers three hours to do by hand. More importantly, it was repeatable and fully logged. I had a lot of fun writing that code. It was the first, significant, real world application I wrote.

Embedded systems (1994)

Years later, I was writing the flight software for yet another satellite instrument. I wrote a multitasking kernel on bare metal. It worked fairly well.

For the ground system, I had the luxury of a Sun Sparcstation 10. We purchased an SBUS to VME bus translator to interface with the satellite instrument. I wrote a custom device driver for Solaris that handled real time interrupts from the VME bus.

Occasionally, I would notice errors in the data stream checksum. This wasn't right. I checked and checked, but I couldn't figure out what was wrong. I speculated there must be some kind of data corruption going on somewhere, but where? I ran a test with smaller telemetry blocks running at high speed. I found that the error rate was very high.

Telemetry data from the flight instrument was transferred through a MIL-STD-1553 bus. The VME-1553 bus interface was manufactured by a company named Ponsor. Like many high speed serial bus interfaces, it used shared memory to transfer data. Often, dual port memory is used, one port on the computer side, the other port on the 1553 side. I noticed the interface board contained only single ported memory, so I speculated there was some kind of timing problem in the bus cycles. I called Ponsor and asked if they knew about a bus contention problem. They said they had suspicions, but no firm evidence and they didn't know much about the board. I asked to speak with the engineer who designed the board and they said that wasn't possible. It turned out the engineer, Mr. Ponsor himself, had died years earlier. Hopefully it wasn't the design that killed him.

I asked if I could get the schematics to the board, Ponsor was hesitant. After some convincing (what was DoD going to do with it?), they sent me the schematic. After a few minutes of scrutiny, I found the problem: bad logic in one of the PALs. I confirmed the error with Ponsor, along with logic analyzer traces and they sent me a new PAL with corrected terms. The interface worked flawlessly after that.

Why did the Ponsor 1553 interface fail in my system when it worked for hundreds or even thousands of other systems? It turned out the SBUS-VME interface was slow, really slow. The bus cycles were 800 ns or more. Mr. Ponsor never expected that, most VME based CPUs of the day had bus cycles of no more than 100 ns, so it worked for 99% of the systems out there. This kind of problem ocurrs all the time in multithreaded software, but it can happen in hardware as well.

A few weeks later, an engineer from another group using the same Ponsor interface came by and asked if I had seen any problems with corruption in the telemetry stream. I just handed her an updated PAL from Ponsor. She had this look on her face like how did you possibly come up with that!. It solved the problem.