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.

Here's a rough timeline:

  • 1980 - learn BASIC
  • 1982 - step up to minicomputers, mostly assembly language
  • 1984 - dive into the Macintosh, C
  • 1989 - develop complete compiler and runtime system
  • 1992 - signal processing and 3D graphics
  • 1994 - develop custom real time operating systems
  • 1995 - download Netscape 2.0 Beta with Java support
  • 1998 - build many, many web sites and enterprise systems with Java
  • 2011 - hardware monitoring and control with Python
  • 2013 - big data, static code analysis, and machine learning

I've had on ongoing interest in compiler constructions and optimal code generation for many years. Over the years, I have developed several lightweight, compilers and optimizing code generators for many different hardware architectures. These are some of the techniques I have used with good success:

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 instruments in my first full time job. Testing in the aerospace industry was really boring in those days. Lots of switching main bus A, checking the voltage and current, writing it down. That was too tedious for me and my handwriting wasn't very 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 automated testing 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.

High speed 3D graphics (1993)

Fairchild had some really sharp people that had developed high speed, 3D texture mapping techniques. They believed there was a commercial market for lower cost 3D graphics video cards. This was years before NVidea released their first full custom silicon 3D graphics engines. We were using dual floating point DSPs for geometry transformation and texture mapping calculations. The final rendering was done with a custom ASIC. FPGAs just weren't big enough and fast enough in those days.

The critical path in the system were polygon calculations that would be fed into the ASIC. We had no more than a 150 clock cycle budget for that algorithm. In theory, the DSP could do it, but scheduling VLIW instructions to make it happen was a lot harder than was expected. We tried hand coding the algorithm in assembly, but it was just too complex for that. We did some work on optimal code generation, but that kind of thing was still at the bleeding edge of computer science research at the time. Today, that problem could be efficiently solved using modern techniques.

That project was eventually scrapped. The market was definitely there. NVidea did well with their 3D graphics products. Fairchild was a good company in those days. They never completely gave up. Upper management asked "how do we make lemonade?". That's what you do when life hands you lemons. Some of the core technology was used in other projects with good success.

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. 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 this wasn't the design that killed him.

I asked if I could get the schematics to the board, but 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 logic. 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 occurs 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.

Web and Java (1995)

One perk of working in a defense research lab was access to ARPANET. A colleague came running to my lab one day and told me I had to download this really cool software he had just found. "What does it do?", I asked. "You open a page, and it has these links, and when you click on the link, it goes somewhere" he replied. "Where does it go?", I asked. "It goes where ever you clicked!" he answered. It sounded fishy, but I eventually downloaded and compiled NCSA Mosaic. He was right, it was really cool.

I started building my own web pages a few days after that. Netscape released version 2.0 beta of their browser around that time. That was a big. When I saw the sample Java applets and the code behind it, I knew this was really big. I signed an author contract to write my first book and went to work for a promising startup that I had helped co-found years earlier. They had a T1 internet connection, a Cisco router, and SGI servers and workstations. This space age stuff in those days. There was potential to really take off and become a major player in the industry, but it imploded. I started teaching and consulting after that. I worked on many really interesting projects for lots of different industries. It was an exciting time with limitless possibilities.