5 ms·

people could've really used a higher-level language compiling to optimized AGC(apollo computer) assembly. Is there any reason why they didn't develop one? It se

people could've really used a higher-level language compiling to optimized AGC(apollo computer) assembly. Is there any reason why they didn't develop one? It seems it would've helped tremendously with the productivity and verification (and a lot of the explanations and equations would be readable as code, not as an non-executed comment)

mbrumlow 10y ago
I could be wrong. But I think part of why they did it this way was so they could edit things on the fly if a emergency dictated so. Having to ship a compiler (would have likely been an entire separate computer) would have not been feasible. With things done this way and documented this why they could (fairly sure did) have the pages printed out on paper and such. And if say there was some bug or new routine that needed to be added mid flight they could go to a key board input (no screen) and with the instructions from the ground reprogram a section or add a new jump point or change a value mid flight. Remember, computers were not what they are today. They did not have super powerful laptops and such with fancy tools.
- datenwolf 10y ago
  > I could be wrong. But I think part of why they did it this way was so they could edit things on the fly The AGC code was stored in ROM. Notably a specific kind of ROM called "rope memory".
  - nameless912 10y ago
    Hey, uh, Apollo <n for n > 10 and n < 18>? This is Houston. Could you pull out the ROM banks and flip a couple of bits for us? we made a mistake or two. All you need are some wire cutters and a very steady hand.
  - mbrumlow 10y ago
    "The bulk of the software was on read-only rope memory and thus couldn't be changed in operation, but some key parts of the software were stored in standard read-write magnetic-core memory and could be overwritten by the astronauts using the DSKY interface, as was done on Apollo 14." Seams you were mostly right about not being able to change it. I was only somewhat right because I assumed it would all be editable. I over estimated the technology they had back then. I would gather from that there was for more fixed code than editable. Source: https://en.wikipedia.org/wiki/Apollo_Guidance_Computer https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
    - datenwolf 10y ago
      > "The bulk of the software was on read-only rope memory and thus couldn't be changed in operation, but some key parts of the software were stored in standard read-write magnetic-core memory and could be overwritten by the astronauts using the DSKY interface, as was done on Apollo 14." Ah, yes right, there was something. I've been fascinated by the AGC by some time¹, yet I completely forget about that. Time to hunt down the mission protocols to understand what this patch did. ------ 1: … and the LVDC, which is the computer that controlled the Saturn-V. Because it was based on the computers used in ICBMs still a lot of information about that is classified. A lot of people conjectured that it was a IBM System 360 reshaped, but when actual LVDS board got torn down by electronics nerds over the past couple of years some significant differences to the 360 were discovered.
kps 10y ago
> Is there any reason why they didn't develop one? “Now you have two problems.” Edit: OK, maybe that deserves explanation. First, an optimizing compiler is a much bigger project than the AGC code. Second, current optimization techniques didn't exist in 1969, even assuming NASA had enough budget for machine(s) to run them. Third, you need to verify the binary anyway, and small source changes (in either the guidance code or the compiler) can lead to large binary changes.
- alehander42 10y ago
  I still think it's easier to verify two isolated projects: the compiler(that can be reused) and the apollo code instead of mashing all of the equations code in assembly. I doubt the people were so used to assembly(especially scientists) that they they didn't require a magnitude more time to mentally parse/unparse logic and equations to machine code. (Also the compiler doesn't have to be very high level, even just a glorified macro-assembler with some syntactic sugar for math does seem not hard)
dandrews 10y ago
It was pretty much taken as gospel everywhere at the time that NO compiler could match the speed and size of a well crafted assembly language routine. Back then there were some noble attempts at building optimizing compilers, and probably the more notable one was IBM's ambitious ForTran H. But that's 50-year-old tech now, kids. Remember also that memory was at a terrific premium. I don't have any specific knowledge about the AGC, but there's an interesting story I read once about a memory shortage in another project - Intel's 8080. (If you'll permit me an OT digression...) As the story goes, the program space was so tight in the original microcode for the Intel 8080 microprocessor there wasn't room to spare for a one-byte constant in the code! The architects decided that the AAM and AAD instructions in the 8080 set should have a required operand - 0x0A or 10 - so that the instruction could refer to itself and know that you were operating in base 10! A side effect of this is that the Intel processors could actually execute AAM and AAD instructions in number bases besides 10; Intel had never formally acknowledged that the instructions do this, and so in the NEC V20 or V30 chips - which were supposed to be Intel compatible - you couldn't change the AAM or AAD operand - it had to be 0x0A.
- AstroJetson 10y ago
  This sounds interesting, any link to a second source on this?
nameless912 10y ago
Long story short, in circa 1969 higher-level languages were mostly the purview of academics. No one had a computer powerful enough to run a language compiler/runtime, and programmers were real men(tm) and wrote assembly by hand because that was all they knew how to do. That's not to say that there weren't any advantages to using a higher level language, but in the case of something like the apollo computer, they couldn't risk compiler bugs or slow code gumming up the system and potentially killing the astronauts. Even today, certain ridiculously-high-performance or super low latency tasks (i.e. embedded devices, high frequency trading) drop down to the assembly level because that small bit of overhead the compiler adds (for such modern coddling conveniences as function calls and type safety) are just too much. It's not crazy, it's just what's needed for that particular job.
- kps 10y ago
  There were programming languages in widespread commercial use (e.g. Fortran and COBOL) and many others for niche applications or associated with particular manufacturers.
caf 10y ago
The guidance and navigation functions were actually programmed in a slightly higher level language called "Interpretive".
NEDM64 10y ago
Because writing control routines is not a big deal in assembly. Specially in these CISC processors.

mbrumlow 10y ago

I could be wrong. But I think part of why they did it this way was so they could edit things on the fly if a emergency dictated so. Having to ship a compiler (would have likely been an entire separate computer) would have not been feasible. With things done this way and documented this why they could (fairly sure did) have the pages printed out on paper and such. And if say there was some bug or new routine that needed to be added mid flight they could go to a key board input (no screen) and with the instructions from the ground reprogram a section or add a new jump point or change a value mid flight. Remember, computers were not what they are today. They did not have super powerful laptops and such with fancy tools.

datenwolf 10y ago
> I could be wrong. But I think part of why they did it this way was so they could edit things on the fly The AGC code was stored in ROM. Notably a specific kind of ROM called "rope memory".
- nameless912 10y ago
  Hey, uh, Apollo <n for n > 10 and n < 18>? This is Houston. Could you pull out the ROM banks and flip a couple of bits for us? we made a mistake or two. All you need are some wire cutters and a very steady hand.
- mbrumlow 10y ago
  "The bulk of the software was on read-only rope memory and thus couldn't be changed in operation, but some key parts of the software were stored in standard read-write magnetic-core memory and could be overwritten by the astronauts using the DSKY interface, as was done on Apollo 14." Seams you were mostly right about not being able to change it. I was only somewhat right because I assumed it would all be editable. I over estimated the technology they had back then. I would gather from that there was for more fixed code than editable. Source: https://en.wikipedia.org/wiki/Apollo_Guidance_Computer https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
  - datenwolf 10y ago
    > "The bulk of the software was on read-only rope memory and thus couldn't be changed in operation, but some key parts of the software were stored in standard read-write magnetic-core memory and could be overwritten by the astronauts using the DSKY interface, as was done on Apollo 14." Ah, yes right, there was something. I've been fascinated by the AGC by some time¹, yet I completely forget about that. Time to hunt down the mission protocols to understand what this patch did. ------ 1: … and the LVDC, which is the computer that controlled the Saturn-V. Because it was based on the computers used in ICBMs still a lot of information about that is classified. A lot of people conjectured that it was a IBM System 360 reshaped, but when actual LVDS board got torn down by electronics nerds over the past couple of years some significant differences to the 360 were discovered.

kps 10y ago

> Is there any reason why they didn't develop one? “Now you have two problems.” Edit: OK, maybe that deserves explanation. First, an optimizing compiler is a much bigger project than the AGC code. Second, current optimization techniques didn't exist in 1969, even assuming NASA had enough budget for machine(s) to run them. Third, you need to verify the binary anyway, and small source changes (in either the guidance code or the compiler) can lead to large binary changes.

alehander42 10y ago
I still think it's easier to verify two isolated projects: the compiler(that can be reused) and the apollo code instead of mashing all of the equations code in assembly. I doubt the people were so used to assembly(especially scientists) that they they didn't require a magnitude more time to mentally parse/unparse logic and equations to machine code. (Also the compiler doesn't have to be very high level, even just a glorified macro-assembler with some syntactic sugar for math does seem not hard)

dandrews 10y ago

It was pretty much taken as gospel everywhere at the time that NO compiler could match the speed and size of a well crafted assembly language routine. Back then there were some noble attempts at building optimizing compilers, and probably the more notable one was IBM's ambitious ForTran H. But that's 50-year-old tech now, kids. Remember also that memory was at a terrific premium. I don't have any specific knowledge about the AGC, but there's an interesting story I read once about a memory shortage in another project - Intel's 8080. (If you'll permit me an OT digression...) As the story goes, the program space was so tight in the original microcode for the Intel 8080 microprocessor there wasn't room to spare for a one-byte constant in the code! The architects decided that the AAM and AAD instructions in the 8080 set should have a required operand - 0x0A or 10 - so that the instruction could refer to itself and know that you were operating in base 10! A side effect of this is that the Intel processors could actually execute AAM and AAD instructions in number bases besides 10; Intel had never formally acknowledged that the instructions do this, and so in the NEC V20 or V30 chips - which were supposed to be Intel compatible - you couldn't change the AAM or AAD operand - it had to be 0x0A.

AstroJetson 10y ago
This sounds interesting, any link to a second source on this?

nameless912 10y ago

Long story short, in circa 1969 higher-level languages were mostly the purview of academics. No one had a computer powerful enough to run a language compiler/runtime, and programmers were real men(tm) and wrote assembly by hand because that was all they knew how to do. That's not to say that there weren't any advantages to using a higher level language, but in the case of something like the apollo computer, they couldn't risk compiler bugs or slow code gumming up the system and potentially killing the astronauts. Even today, certain ridiculously-high-performance or super low latency tasks (i.e. embedded devices, high frequency trading) drop down to the assembly level because that small bit of overhead the compiler adds (for such modern coddling conveniences as function calls and type safety) are just too much. It's not crazy, it's just what's needed for that particular job.

kps 10y ago
There were programming languages in widespread commercial use (e.g. Fortran and COBOL) and many others for niche applications or associated with particular manufacturers.

caf 10y ago

The guidance and navigation functions were actually programmed in a slightly higher level language called "Interpretive".

NEDM64 10y ago

Because writing control routines is not a big deal in assembly. Specially in these CISC processors.