Apollo 11 source code released

On 16-07-14 13:44 , Jeff Findley wrote:

We're talking about programming for a primitive computer with
very little RAM.

Using global variables as subroutine copy-in/copy-out arguments uses
*more* RAM than passing the arguments by reference would use. But AIUI
the AGC was not friendly to passing by reference.

You do what you have to do to get the job done with
the memory available to you. Which means you have to hand code all of
this yourself. You can't afford for compiled code to cause the computer
to run out of memory during flight, so you have to manage it yourself.

No you don't. Compilers are used routinely to create code for machines
with tiny or small amounts of RAM. As long as you avoid using the heap
(and, if necessary, tell the compiler not to use the heap implicitly),
and avoid other dynamic memory usage like recursion, the RAM usage can
be computed before flight and the SW will not run out of memory during
flight.

Of course, there are still cases in which compiler-generated code does
not fit into the RAM you have, but manually written assembly-language
code fits. But these cases are very rare today -- compilers for embedded
systems can do astonishing optimizations to save on RAM, things an
assembly-language programmer would almost never dare do because they
would be too difficult to maintain as the SW evolves.

I don't know whether a useful compiler could have been created for the
AGC SW. At that time, assembly-language programming was the default
choice for embedded systems, I believe, so perhaps the question was not
even studied. Moreover, perhaps the AGC architecture was evolving so
rapidly that no compiler developers could have kept up.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

On 16-07-17 18:49 , JF Mezei wrote:
On 2016-07-15 16:54, Niklas Holsti wrote:

No you don't. Compilers are used routinely to create code for machines
with tiny or small amounts of RAM. As long as you avoid using the heap
(and, if necessary, tell the compiler not to use the heap implicitly),

Whether heap is used or not depends on compiler. Older compilers likely
had statically allocated data structures. C did not exist when Apollo
first flew.

The classical languages -- Fortran, Algol, Pascal, Modula, C -- are
designed so that the compiler does not need to use implicit heap
allocation in the generated code. Heap allocation is used only if the
source code says so pretty explicitly.

But you are right that some languages are such that the compiled code is
likely to use, or even required to use heap allocation -- Java comes to
mind. I did not mean to say that no compilers use implicit heap
allocation, so my wording could have been better. But even in Java there
are ways to reduce or avoid heap allocations -- the "real-time" Java
extensions.

code fits. But these cases are very rare today -- compilers for embedded
systems can do astonishing optimizations to save on RAM, things an
assembly-language programmer would almost never dare do because they
would be too difficult to maintain as the SW evolves.

Apart from optimizing variables away (such as a variable used as a loop
counter which ends up being used in a register only), what sort of other
memory saving techniques exist ?

The Keil compiler for the Intel-8051 architecture has the following
feature (which may also exist in other compilers for all I know).

Like the AGC, the basic 8051 is weak at indirect addressing -- general
register-based indirect addressing and the HW stack are available only
in the 128 or 256 byte (yes, byte!) "internal" memory, and the larger
"external" memory can be addressed indirectly only by one dedicated
register. Therefore, compilers for the 8051 typically allocate memory
locations statically for most subroutine parameters and local variables
(assuming that subroutines are not recursive).

The Keil compiler inspects the whole call-tree, finds out which
subroutines cannot be active at the same time, and makes those
subroutines share the same memory locations for their data. For example,
if subroutine A never calls subroutine B, directly or indirectly, and B
never calls A, directly or indirectly, then the parameters and variables
of A and B can be placed in the same memory locations -- when A needs
them, B does not, and vice versa.

But this global knowledge of the call-tree is something that few
programmers could keep in their heads, for largish programs. And the
manual work of either overlaying or separating the data for two
subroutines, as the call-tree changes during program evolution, would be
costly and error-prone.

Also, when you write embedded code with avrous hardware attachements,
you may not want the compiler to optimize away your variables as the
storage may have to be reserved at specific addresses for communications
with devices. (DMA etc).

Languages have features like "volatile" for that. Not a problem.

I don't know whether a useful compiler could have been created for the
AGC SW. At that time, assembly-language programming was the default
choice for embedded systems,

Did programmed embeded devices exist at that time ? or was the moon shot
the catalyst to develop such computers Considering the memory and
performance constraints, Assembler may have been the only solution.

The 1960's was the decade that invented the minicomputer, although the
early ones were only "mini" in comparison with the mainframes. Looking
only at some examples that were available for the public, we have the
Elliot 803 in 1960 (https://en.wikipedia.org/wiki/Elliott_803), the LINC
in 1962 (https://en.wikipedia.org/wiki/LINC), the Bull Gamma M-40 in
1964 (http://www.feb-patrimoine.com/histoi...gamma_m40.htm), and
of course the PDP series with the PDP-8 in 1965
(https://en.wikipedia.org/wiki/PDP-8).

The AGC was remarkable in being small, rugged, and dedicated to a single
application with most of the code in ROM. I would assume that similar
computers were used in military applications, before and after Apollo.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .