Source code from Apollo 11 open-sourced | Hacker News Reader

Source code from Apollo 11 open-sourced

googlecode.blogspot.com

211 pointsmark_h58 comments

We've talked about "software engineering" before. This is it.

From mixmax's fastcompany link: "Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle". That's what's required for real engineering in the end: an engineer to sign off on the plans and to take responsibility if the product fails and people die.

This is alien to most software development, where "software engineering" is, at best, a useful metaphor. This is real software engineering.

It's not really - do anything in avionics or health care and you have to follow similar procedures.

The mistake is to believe that making planes fly through the air and making 140-character text messages fly through the net are the same problem, or thinking that one is "real" engineering and the other is not. I would not want your average Rails developer writing the code that keeps my flight flying. I also would not want your average avionics software developer writing consumer web software.

I've worked on both avionics software and web software, and you're spot-on correct... the procedures and development styles are entirely different. Avionics development is laced with simple, easily-understandable coding techniques shrouded in requirements, verification, and paperwork. And yes, real people do sign off on things. Unlike in the web world, where you can whip out changes every day, it's not uncommon for there to be a delay of months (or even years) between writing a piece of code and deployment. We were working on software for the Boeing 787 about five years ago...

I work on SIL-4 systems for Rail (Transportation, not fancy web framework de-jour) applications .. the code I spent a year slaving over to ensure it is as bug-free as can possibly be rendered, won't ship to our customers until next year, and even they won't be deploying it in field for another year or so after they get done with their own tests. So, I'm looking at having to support that code from a year ago, 3 to 5 years from now.

Thats why, its good code. ;)

Interestingly making 160-char message fly through the air is pretty reliable, because that bit of the system was implemented by real engineers.

Though it can take a long time to get through, as it only uses spare capacity.

" I also would not want your average avionics software developer writing consumer web software."

I am not sure of that part. I think I would like to be able to trust my software just a little more. Not working properly is NOT OK.

There's a cost to software that always works correctly. If one of the avionics software engineers I've worked with tried to write a consumer webapp, he'd work so slowly that by the time the app was done, I wouldn't need it anymore.

When Reddit was young, I sent a couple bug reports and feature requests to spez & kn0thing. Within an hour, they had the code done and up on the live site. The cost of that was that their users did the QA, which is simply not acceptable for avionics. But I'd rather have a feature done in an hour that may or may not work than wait a month for a feature that I know will work, but is probably rendered obsolete by developments elsewhere on the web.

You noticed a bug.

The system failed.

The fact they fixed it quickly is a seperate issue.

He means most people are not willing to pay for their web apps to be as well-specced and thoroughly tested and verified as serious software. That goes both for dotcom companies and end-users who votes with their dollars and simply don't care if a website crashes from time to time.

That's fine for software that I'm not paying for - and how many web apps are worth paying for? I smell a chicken or the egg problem...

Investors in dotcoms very much are paying for software...

It's really not that unusual. There's a lot of machinery that can kill people and it's all run by software.

When I was in school here in Canada, we were told the story of the Therac-25 (http://en.wikipedia.org/wiki/Therac-25). Sadly, we're still dealing with some of the problems that plagued the Therac-25 (e.g., poor error messages, arithmetic overflows, simply assuming that software will run the same on compatible hardware, race conditions, etc.) Sometimes I read workarounds to CPU and other hardware errata in kernel modules/drivers. Given the sort of obscure problems mentioned in that code, I for one would not want to put my John Doe on any sort of certification like this. My hat's off to the guy.

In case "this" is the Apollo 11 source code in the submission:

Don Eyles, a 23-year-old self-described "beatnik" who had just graduated from Boston University and was set the task of programming the software for the Moon landing. http://news.ycombinator.com/item?id=707801

I read somewhere (can't find the link) that Dijkstra said he spoke to Eyles, and asked how he got everything correct. He replied that just a few days before launch, the software simulated the moon's gravity as repulsive, before he fixed it... "so the astronauts were lucky there". Probably apocryphal hearsay, but does chime with the "beatnik" story. EDIT Found it: http://www.reddit.com/r/programming/comments/91vki/don_eyles...

Definately apophycral - from the bbc article linked in the first ycombinator article:

The rope core memories would become know as "LOL memory" after the "little old ladies" who knitted together the software at a factory just outside Boston.

These ladies would sit in pairs with a memory unit between them, threading metres and metres of slender copper wires through and around the cores.

"It's an extremely time-consuming process and it meant that the programs had to be finished and fully tested months in advance," said Mr Eyles.

I got some details wrong, but it's basically right.

Dijkstra spoke to Joel Aron (not Eyles), "head of IBM's Federal Systems Division which had been responsible for the software of the moonshot". It wasn't specifically in the lunar module, but somewhere in the 40,000 LoC. However, the bug was that the moon was repelling; and it was found by accident, 5 days before launch.

See Dijkstra say it in person, at 15:00 in this interview (context starts at 13:40): http://www.cs.utexas.edu/users/EWD/video.html (I haven't linked directly to the 300MB download). Great interview BTW (dutch with subtitles).

In the video of the landing, you can hear Neil ask about error "1202", which I think I found in the source here:

http://www.google.com/codesearch/p?hl=en&sa=N&cd=10&...

Which is talked about here: http://history.nasa.gov/alsj/a11/a11.1201-pa.html

Ok wow, that is a fantastic and lucid explanation of both the error and the real-time capabilities of the system. If only our desktop software was as smart today!

Interesting interview with Allan Klumpp (one of the programmers)

http://www.netjeff.com/humor/item.cgi?file=ApolloComputer

Very interesting link, thanks!

In the interview, he mentioned that the folks at MIT wrote the program in high-level-language called MAC (MIT Algebraic Compiler) and hand-compiled it to the machine language of the actual computer which I take is what we see at google code.

Wouldn't it be great if the MAC source would also be available for us to see? After all, that is the context in which the actual software engineering took place. Looking at the resulting assembly might give a somewhat distorted impression of how the work was done.

The BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.s filename is pretty good, as is the end of the header comments:

# HONI SOIT QUI MAL Y PENSE # NOLI SE TANGERE

http://code.google.com/p/virtualagc/source/browse/trunk/Lumi...

More info about the instruction set: http://en.wikipedia.org/wiki/Apollo_Guidance_Computer

And it's not hack-free:

The Block II AGC also has the mysterious and poorly documented EDRUPT instruction (the name may be a contraction of Ed's Interrupt, after Ed Smally, the programmer who requested it) which is used a total of once in the Apollo software: in the Digital Autopilot of the Lunar Module. At this time, while the general operation of the instruction is understood, the precise details are still hazy, and it is believed to be responsible for problems emulating the LEM AGC

I'm not a hardware guy (so please correct if I'm wrong...seriously), but if it's just that one instruction that has unknown functionality, couldn't they look at the code and the specified functionality (of all the code) and sort of reverse engineer the logic of it? Or find one of the old computers (in a museum or something) and examine the hardware in it?

They'd have to unwrap the instructions (hard-wire, literally) to get to the meat of it, and even then there's no guarantee they'd be able to put it all back together again.

Better that it just remains curious, and that we don't use AGC Version 1.0 for future launch attempts ..

For those in the Bay Area, you can see an actual Apollo guidance computer prototype at the Computer History Museum:

http://www.computerhistory.org/collections/accession/X37.81A

Notice all the wire wrap!

http://archive.computerhistory.org/resources/access/physical...

The docent said that the computer would be potted before an actual launch.

Now the rest of us can see what bugfree code looks like.

http://www.fastcompany.com/magazine/06/writestuff.html?page=...

the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI) a measure of the sophistication and reliability of the way they do their work.

I wouldn't put too much faith in SEI CMM. The last company I worked for set up an offshore software shop and staffed it with fresh graduates. A year later they were SEI CMM Level 5 certified, boasted the company. This, mind, was despite them never having delivered a complete project... And much of their actual work being done by "contractors" (who were people laid off in the UK and rehired there at vast expense).

There are actually more level 5's in operation. The certification process is about having the procedures in place, and so it is conceivable that you could get that without a delivery.

I suppose we could if this was the code for the shuttle. But it's not.

I'm sure the standards are the same though.

It's coded in a really interest dialect. Completely unreadable to me, at least.

I wonder what the Shuttle source looks like. I'd imagine its in a higher level language (C?), and that it's likely been rewritten several times since the 70s. It's amazing to me that people wrote this.

You may find this reference helpful: http://www.ibiblio.org/apollo/assembly_language_manual.html

Found it after following up the http://ibiblio.org/apollo link in a file header. :)

I'd be surprised if it wasn't Ada. Tho' Ada code was responsible for Ariane 5 exploding, so it's not a 'silver bullet'.

Well, Ada usually runs more safely if you don't explicitly disable error handling, which is what they did to the Ariane 5.

The first things I noticed when browsing this code is the quality and quantity of the comments.

I sometimes wish that low percentages of comments would generate a fatal error!

Ah, but in higher-level languages comments are bugs.

Knuth would disagree.

Haskell has a `mode' called Literate Haskell, were everything is a comment, unless you specify otherwise (e.g. enclose it in \begin{code} and \end{code} pairs).

Well, I would say that Knuth doesn't put comments, he puts chapters. His code is quite a pleasure to read.

I don't yet seem to be at that level of evolution yet.

Commenting _too_ much can degrade the quality of code. Be smart when commenting.

There is definitely a balance, but high-level code, when well written, is self-documenting. Comments should justify why something has been coded the way it has, not tell others what the code does (unless it's justifiably unreadable).

Yes comments should be about intent, the implementation (code) should be obvious. Often when maintaining legacy code the most important thing is to understand what the original programmer wanted to do and why. Not that there aren't some complete idiots writing code - but you can't know that this seemingly stupid thing you see in your editor window wasn't the best decision at the time given some constraint that no longer exists now.

Some deep algorithms may require more comments about their inner workings.

# YOU WOULD THINK THEY CAN COMMENT WITHOUT YELLING.

Um, dude, back in the day, all you got were CAPS. (And that was still true ten years later, in 1979, with my Apple II Plus.)

Are you sure? AFAIK the earliest LISP (1958) supported lowercase, PDP-1 (1960) had lowercase, the ancient SAIL keyboards (1960s) even had Greek letters on them.

Anything that was done using punchcards was all uppercase.

Btw, did you know that the 'SAIL' assembler/debugger was called 'FAIL' ?

When you're working in that kind of paradigm they're pretty essential...when you have higher level constructs things are a bit more self explanatory :)

Cool. Now we can do an open source moon mission.

TC BANKCALL # TEMPORARY, I HOPE HOPE HOPE

I laughed quite a bit at that :)

Line 666 of http://code.google.com/p/virtualagc/source/browse/trunk/Lumi...

"GAINBRAK,1 # NUMERO MYSTERIOSO"

The original Lunar Lander.

Looking through this makes me thankful for all of the high-level goodness we get to use today.

Oh lord I would love to work on this.

Great.

Now I just have to get an Apollo to use it. ;-)

Or you can use the AGC emulator linked to in the blog post:

http://www.ibiblio.org/apollo/

What's the fun? No rumble, no smoke, no danger, no smell of fuel... ;-)

i love it

Reply on news.ycombinator.com