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.

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.