Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.space.policy > #56960 > unrolled thread

Apollo 11 source code released

Back to article view | Back to sci.space.policy

Contents

  Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-10 12:43 -0400
    Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 20:33 +0300
      Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-10 18:28 -0400
        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-10 21:27 -0400
        Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-11 00:36 -0700
          Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-11 06:44 -0400
            Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-11 16:20 +0300
              Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-11 20:53 -0400
                Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-12 14:36 -0400
                  Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 18:11 -0700
                Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 23:37 +0300
                  Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 18:14 -0700
                    Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 21:01 +0300
                      Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-13 20:06 -0700
                        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-14 06:44 -0400
                          Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 23:54 +0300
                            Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-17 11:49 -0400
                              Re: Apollo 11 source code released William Mook <mokmedical@gmail.com> - 2016-07-17 18:41 -0700
                              Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-18 09:20 +0300
                        Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-14 11:38 -0400
                          Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-16 00:10 +0300
                        Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 22:26 +0300
                          Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-20 10:49 -0700
                Re: Apollo 11 source code released Snidely <snidely.too@gmail.com> - 2016-07-14 09:12 -0700
            Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-11 11:51 -0400
              Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 02:19 +0300
                Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-11 20:58 -0400
                  Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 09:24 +0300
                    Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 10:10 -0700
                      Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 21:07 +0300
                        Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-13 20:08 -0700
                      Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-14 11:25 -0400
                        Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 22:39 +0300
                        Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-20 10:40 -0700
                  Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-12 14:41 -0400
                    Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 23:26 +0300
                    Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-12 21:41 -0400
                      Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 08:54 +0300
                        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-13 06:43 -0400
                          Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-13 21:08 +0300
                      Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-14 11:34 -0400
                        Re: Apollo 11 source code released Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-15 23:06 +0300
                        Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-15 19:48 -0400
                          Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-15 19:59 -0400
                            Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-17 12:00 -0400
                              Re: Apollo 11 source code released Jeff Findley <jfindley@cinci.nospam.rr.com> - 2016-07-17 12:14 -0400
                                Re: Apollo 11 source code released JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-07-17 12:56 -0400
                Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 10:04 -0700
              Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-12 09:43 -0700
            Re: Apollo 11 source code released Alain Fournier <alain245@videotron.ca> - 2016-07-11 19:43 -0400
    Re: Apollo 11 source code released Fred J. McCall <fjmccall@gmail.com> - 2016-07-10 11:39 -0700
    Re: Apollo 11 source code released William Mook <mokmedical@gmail.com> - 2016-07-11 18:28 -0700

Page 1 of 3  [1] 2 3  Next page →

#56960 — Apollo 11 source code released

The source code for many Apollo 11 computers has been released n digital
form on GitHub. (scanned from printed listings at MIT).

https://github.com/chrislgarry/Apollo-11


Question: what computer architecture/instruction set was used for the on
board computers ?

[toc] | [next] | [standalone]

#56961

On 16-07-10 19:43 , JF Mezei wrote:
>
> The source code for many Apollo 11 computers has been released n digital
> form on GitHub. (scanned from printed listings at MIT).
>
> https://github.com/chrislgarry/Apollo-11
>
>
> Question: what computer architecture/instruction set was used for the on
> board computers ?

A custom-made computer:

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

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

[toc] | [prev] | [next] | [standalone]

#56971

On 2016-07-10 13:33, Niklas Holsti wrote:

> A custom-made computer:
> 
> https://en.wikipedia.org/wiki/Apollo_Guidance_Computer


Very interesting read. Thanks.  It mentions it was the first computer
made of integrated circuits. Looks like it was all fixed decimal
notation as opposed to floating point. That would have a big impact on
the heavy math done for guidance and navigation (lots of angles/trig etc).

Was all the code written in assembler or were portions done in higher
level languages ?

[toc] | [prev] | [next] | [standalone]

#56972

In article <5782cc04$0$20011$c3e8da3$1cbc7475@news.astraweb.com>, 
jfmezei.spamnot@vaxination.ca says...
> 
> On 2016-07-10 13:33, Niklas Holsti wrote:
> 
> > A custom-made computer:
> > 
> > https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
> 
> 
> Very interesting read. Thanks.  It mentions it was the first computer
> made of integrated circuits. Looks like it was all fixed decimal
> notation as opposed to floating point. That would have a big impact on
> the heavy math done for guidance and navigation (lots of angles/trig etc).
> 
> Was all the code written in assembler or were portions done in higher
> level languages ?

Might be some info in here:

- Chapter Two -
- Computers On Board The Apollo Spacecraft -
The Apollo guidance computer: Hardware
http://history.nasa.gov/computers/Ch2-5.html

If not, I belive there are several books on the subject:

The Apollo Guidance Computer: Architecture and Operation (Springer 
Praxis Books)Jul 12, 2010
by Frank O'Brien

Digital Apollo: Human and Machine in SpaceflightApr 4, 2008
by David A. Mindell
Hardcover

Apollo's Computers (Space Book 5)Jun 28, 2014
by Patrick Stakem

Journey to the Moon: The History of the Apollo Guidance Computer 
(Library of Flight)Sep 1996
by Eldon C. Hall


Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#56977

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

>On 2016-07-10 13:33, Niklas Holsti wrote:
>
>> A custom-made computer:
>> 
>> https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
>
>
>Very interesting read. Thanks.  It mentions it was the first computer
>made of integrated circuits. Looks like it was all fixed decimal
>notation as opposed to floating point. That would have a big impact on
>the heavy math done for guidance and navigation (lots of angles/trig etc).
>
>Was all the code written in assembler or were portions done in higher
>level languages ?
>

No HOL.  Have you looked at the specifications for these things?


-- 
"The reasonable man adapts himself to the world; the unreasonable 
 man persists in trying to adapt the world to himself. Therefore, 
 all progress depends on the unreasonable man."
                                      --George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#56978

In article <p2j6obt05vvmbg0i08afngatpmurap66e6@4ax.com>, 
fjmccall@gmail.com says...
> 
> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> >On 2016-07-10 13:33, Niklas Holsti wrote:
> >
> >> A custom-made computer:
> >> 
> >> https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
> >
> >
> >Very interesting read. Thanks.  It mentions it was the first computer
> >made of integrated circuits. Looks like it was all fixed decimal
> >notation as opposed to floating point. That would have a big impact on
> >the heavy math done for guidance and navigation (lots of angles/trig etc).
> >
> >Was all the code written in assembler or were portions done in higher
> >level languages ?
> >
> 
> No HOL.  Have you looked at the specifications for these things?

The Wikipedia entry clearly says this, "AGC software was written in AGC 
assembly language and stored on rope memory."

By modern standards, we really don't have much to compare with.  Going 
back to the 1980's, the AGC was about twice the speed of my old C-64 but 
with only a tiny fraction of the RAM and a lot more more ROM (since 
there was no other place for program storage like tape or disk).  

Putting it in that perspective, the C-64 programs written commercially 
rarely used languages above assembly language.  You just could not do 
much on a C-64 using a "higher level language" due to the overhead of 
incurred.  Even in the 1980's, compilers, optimizers, and linkers 
delivered code which was very "bloated".  The 1960's would have been 
far, far, worse.

Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#56979

On 16-07-11 13:44 , Jeff Findley wrote:
> In article <p2j6obt05vvmbg0i08afngatpmurap66e6@4ax.com>,
> fjmccall@gmail.com says...
>>
>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>
>>> On 2016-07-10 13:33, Niklas Holsti wrote:
>>>
>>>> A custom-made computer:
>>>>
>>>> https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
>>>
>>>
>>> Very interesting read. Thanks.  It mentions it was the first computer
>>> made of integrated circuits. Looks like it was all fixed decimal
>>> notation as opposed to floating point. That would have a big impact on
>>> the heavy math done for guidance and navigation (lots of angles/trig etc).
>>>
>>> Was all the code written in assembler or were portions done in higher
>>> level languages ?
>>>
>>
>> No HOL.  Have you looked at the specifications for these things?
>
> The Wikipedia entry clearly says this, "AGC software was written in AGC
> assembly language and stored on rope memory."

But the Wikipedia entry also says this:

"The AGC also had a sophisticated software interpreter, developed by the 
MIT Instrumentation Laboratory, that implemented a virtual machine with 
more complex and capable pseudo-instructions than the native AGC. These 
instructions simplified the navigational programs. Interpreted code, 
which featured double precision trigonometric, scalar and vector 
arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction, 
could be mixed with native AGC code. While the execution time of the 
pseudo-instructions was increased (due to the need to interpret these 
instructions at runtime) the interpreter provided many more instructions 
than AGC natively supported and the memory requirements were much lower 
than in the case of adding these instructions to the AGC native language 
which would require additional memory built into the computer (at that 
time the memory capacity was very expensive). The average 
pseudo-instruction required about 24 ms to execute. The assembler and 
version control system, named YUL for an early prototype Christmas 
Computer,[8] enforced proper transitions between native and interpreted 
code."

Reminds me of the SWEET16 VM in the Apple II, 
https://en.wikipedia.org/wiki/SWEET16.

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

[toc] | [prev] | [next] | [standalone]

#56987

In article <duhkokFondfU1@mid.individual.net>, 
niklas.holsti@tidorum.invalid says...
> 
> On 16-07-11 13:44 , Jeff Findley wrote:
> > In article <p2j6obt05vvmbg0i08afngatpmurap66e6@4ax.com>,
> > fjmccall@gmail.com says...
> >>
> >> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> >>
> >>> On 2016-07-10 13:33, Niklas Holsti wrote:
> >>>
> >>>> A custom-made computer:
> >>>>
> >>>> https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
> >>>
> >>>
> >>> Very interesting read. Thanks.  It mentions it was the first computer
> >>> made of integrated circuits. Looks like it was all fixed decimal
> >>> notation as opposed to floating point. That would have a big impact on
> >>> the heavy math done for guidance and navigation (lots of angles/trig etc).
> >>>
> >>> Was all the code written in assembler or were portions done in higher
> >>> level languages ?
> >>>
> >>
> >> No HOL.  Have you looked at the specifications for these things?
> >
> > The Wikipedia entry clearly says this, "AGC software was written in AGC
> > assembly language and stored on rope memory."
> 
> But the Wikipedia entry also says this:
> 
> "The AGC also had a sophisticated software interpreter, developed by the 
> MIT Instrumentation Laboratory, that implemented a virtual machine with 
> more complex and capable pseudo-instructions than the native AGC. These 
> instructions simplified the navigational programs. Interpreted code, 
> which featured double precision trigonometric, scalar and vector 
> arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction, 
> could be mixed with native AGC code. While the execution time of the 
> pseudo-instructions was increased (due to the need to interpret these 
> instructions at runtime) the interpreter provided many more instructions 
> than AGC natively supported and the memory requirements were much lower 
> than in the case of adding these instructions to the AGC native language 
> which would require additional memory built into the computer (at that 
> time the memory capacity was very expensive). The average 
> pseudo-instruction required about 24 ms to execute. The assembler and 
> version control system, named YUL for an early prototype Christmas 
> Computer,[8] enforced proper transitions between native and interpreted 
> code."
> 
> Reminds me of the SWEET16 VM in the Apple II, 
> https://en.wikipedia.org/wiki/SWEET16.

The examples given for functionality of the interpreted code bits sound 
an awful lot like subroutines.  

Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#57002

On 2016-07-11 20:53, Jeff Findley wrote:

> The examples given for functionality of the interpreted code bits sound 
> an awful lot like subroutines.  

The instruction set contained an almost explicit "call" opcode (which
stores address of next instruction in a register, then branches to
address specified as opcode. Many instructions later, you branch to that
register's address and continue where the "call" left off.

[toc] | [prev] | [next] | [standalone]

#57010

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

>On 2016-07-11 20:53, Jeff Findley wrote:
>
>> The examples given for functionality of the interpreted code bits sound 
>> an awful lot like subroutines.  
>
>The instruction set contained an almost explicit "call" opcode (which
>stores address of next instruction in a register, then branches to
>address specified as opcode. Many instructions later, you branch to that
>register's address and continue where the "call" left off.
>

That's called a 'subroutine'.


-- 
"Some people get lost in thought because it's such unfamiliar
 territory."
                                      --G. Behn

[toc] | [prev] | [next] | [standalone]

#57005

On 16-07-12 03:53 , Jeff Findley wrote:
> In article <duhkokFondfU1@mid.individual.net>,
> niklas.holsti@tidorum.invalid says...
>> But the Wikipedia entry also says this:
>>
>> "The AGC also had a sophisticated software interpreter, developed by the
>> MIT Instrumentation Laboratory, that implemented a virtual machine with
>> more complex and capable pseudo-instructions than the native AGC. These
>> instructions simplified the navigational programs. Interpreted code,
>> which featured double precision trigonometric, scalar and vector
>> arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction,
>> could be mixed with native AGC code. While the execution time of the
>> pseudo-instructions was increased (due to the need to interpret these
>> instructions at runtime) the interpreter provided many more instructions
>> than AGC natively supported and the memory requirements were much lower
>> than in the case of adding these instructions to the AGC native language
>> which would require additional memory built into the computer (at that
>> time the memory capacity was very expensive)...."
>
> The examples given for functionality of the interpreted code bits sound
> an awful lot like subroutines.

Yes, but the basic AGC instruction set seems IMO very unfriendly to 
subroutines -- it is possible to call ("TC", "Transfer Control") a 
subroutine and save the return address, but it would be quite difficult 
or at least cumbersome to pass arguments, as there are no easy 
base+offset addressing modes.

The INDEX instruction can be used to build such addressing modes, but 
one base+index computation would take several instructions and at least 
one temporary memory location if both "base" and "index" are dynamic 
(non-constant) values, as would often be the case for accessing 
subroutine arguments that are vectors or arrays.

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

[toc] | [prev] | [next] | [standalone]

#57011

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

>On 16-07-12 03:53 , Jeff Findley wrote:
>> In article <duhkokFondfU1@mid.individual.net>,
>> niklas.holsti@tidorum.invalid says...
>>> But the Wikipedia entry also says this:
>>>
>>> "The AGC also had a sophisticated software interpreter, developed by the
>>> MIT Instrumentation Laboratory, that implemented a virtual machine with
>>> more complex and capable pseudo-instructions than the native AGC. These
>>> instructions simplified the navigational programs. Interpreted code,
>>> which featured double precision trigonometric, scalar and vector
>>> arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction,
>>> could be mixed with native AGC code. While the execution time of the
>>> pseudo-instructions was increased (due to the need to interpret these
>>> instructions at runtime) the interpreter provided many more instructions
>>> than AGC natively supported and the memory requirements were much lower
>>> than in the case of adding these instructions to the AGC native language
>>> which would require additional memory built into the computer (at that
>>> time the memory capacity was very expensive)...."
>>
>> The examples given for functionality of the interpreted code bits sound
>> an awful lot like subroutines.
>
>Yes, but the basic AGC instruction set seems IMO very unfriendly to 
>subroutines -- it is possible to call ("TC", "Transfer Control") a 
>subroutine and save the return address, but it would be quite difficult 
>or at least cumbersome to pass arguments, as there are no easy 
>base+offset addressing modes.
>
>The INDEX instruction can be used to build such addressing modes, but 
>one base+index computation would take several instructions and at least 
>one temporary memory location if both "base" and "index" are dynamic 
>(non-constant) values, as would often be the case for accessing 
>subroutine arguments that are vectors or arrays.
>

Easy enough to use something like FORTRAN Common to fake this.


-- 
"The reasonable man adapts himself to the world; the unreasonable 
 man persists in trying to adapt the world to himself. Therefore, 
 all progress depends on the unreasonable man."
                                      --George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#57019

On 16-07-13 04:14 , Fred J. McCall wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>
>> On 16-07-12 03:53 , Jeff Findley wrote:
>>> In article <duhkokFondfU1@mid.individual.net>,
>>> niklas.holsti@tidorum.invalid says...
>>>> But the Wikipedia entry also says this:
>>>>
>>>> "The AGC also had a sophisticated software interpreter, developed by the
>>>> MIT Instrumentation Laboratory, that implemented a virtual machine with
>>>> more complex and capable pseudo-instructions than the native AGC. These
>>>> instructions simplified the navigational programs. Interpreted code,
>>>> which featured double precision trigonometric, scalar and vector
>>>> arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction,
>>>> could be mixed with native AGC code. While the execution time of the
>>>> pseudo-instructions was increased (due to the need to interpret these
>>>> instructions at runtime) the interpreter provided many more instructions
>>>> than AGC natively supported and the memory requirements were much lower
>>>> than in the case of adding these instructions to the AGC native language
>>>> which would require additional memory built into the computer (at that
>>>> time the memory capacity was very expensive)...."
>>>
>>> The examples given for functionality of the interpreted code bits sound
>>> an awful lot like subroutines.
>>
>> Yes, but the basic AGC instruction set seems IMO very unfriendly to
>> subroutines -- it is possible to call ("TC", "Transfer Control") a
>> subroutine and save the return address, but it would be quite difficult
>> or at least cumbersome to pass arguments, as there are no easy
>> base+offset addressing modes.
>>
>> The INDEX instruction can be used to build such addressing modes, but
>> one base+index computation would take several instructions and at least
>> one temporary memory location if both "base" and "index" are dynamic
>> (non-constant) values, as would often be the case for accessing
>> subroutine arguments that are vectors or arrays.
>>
>
> Easy enough to use something like FORTRAN Common to fake this.

Fortran Common areas are global variables, not subroutine arguments that 
can point to different variables on each call.

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

[toc] | [prev] | [next] | [standalone]

#57022

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

>On 16-07-13 04:14 , Fred J. McCall wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>>
>>> On 16-07-12 03:53 , Jeff Findley wrote:
>>>> In article <duhkokFondfU1@mid.individual.net>,
>>>> niklas.holsti@tidorum.invalid says...
>>>>> But the Wikipedia entry also says this:
>>>>>
>>>>> "The AGC also had a sophisticated software interpreter, developed by the
>>>>> MIT Instrumentation Laboratory, that implemented a virtual machine with
>>>>> more complex and capable pseudo-instructions than the native AGC. These
>>>>> instructions simplified the navigational programs. Interpreted code,
>>>>> which featured double precision trigonometric, scalar and vector
>>>>> arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction,
>>>>> could be mixed with native AGC code. While the execution time of the
>>>>> pseudo-instructions was increased (due to the need to interpret these
>>>>> instructions at runtime) the interpreter provided many more instructions
>>>>> than AGC natively supported and the memory requirements were much lower
>>>>> than in the case of adding these instructions to the AGC native language
>>>>> which would require additional memory built into the computer (at that
>>>>> time the memory capacity was very expensive)...."
>>>>
>>>> The examples given for functionality of the interpreted code bits sound
>>>> an awful lot like subroutines.
>>>
>>> Yes, but the basic AGC instruction set seems IMO very unfriendly to
>>> subroutines -- it is possible to call ("TC", "Transfer Control") a
>>> subroutine and save the return address, but it would be quite difficult
>>> or at least cumbersome to pass arguments, as there are no easy
>>> base+offset addressing modes.
>>>
>>> The INDEX instruction can be used to build such addressing modes, but
>>> one base+index computation would take several instructions and at least
>>> one temporary memory location if both "base" and "index" are dynamic
>>> (non-constant) values, as would often be the case for accessing
>>> subroutine arguments that are vectors or arrays.
>>>
>>
>> Easy enough to use something like FORTRAN Common to fake this.
>
>Fortran Common areas are global variables, not subroutine arguments that 
>can point to different variables on each call.
>

Yes, I know.  Here's how it would work.  Suppose I have three
parameters, A, B, and C, for a function, X.  You build X to read the
three values from some shared area (those 'global variables').  Right
before a call to X, the caller sets the values of the three parameters
in Common to the values desired.  X reads those values and runs with
them, changes them if that is desire behaviour, writes a functional
return value to Common, whatever.  When X returns, the caller go reads
the values X set and moves on.  Rinse and repeat.  The only difference
is that instead of the compiler managing everything on the stack frame
for you and having rules about whether you're calling by reference or
by value, you do all that manually around the call to X.

This is dirt simple to do.  I shouldn't have to explain it.


-- 
"Adrenaline is like exercise, but without the excessive gym fees."
               -- Professor Walsh, "Buffy the Vampire Slayer"

[toc] | [prev] | [next] | [standalone]

#57024

In article <200eob9fi8bb0fcuct3hg17vepcr910olv@4ax.com>, 
fjmccall@gmail.com says...
> >>> Yes, but the basic AGC instruction set seems IMO very unfriendly to
> >>> subroutines -- it is possible to call ("TC", "Transfer Control") a
> >>> subroutine and save the return address, but it would be quite difficult
> >>> or at least cumbersome to pass arguments, as there are no easy
> >>> base+offset addressing modes.
> >>>
> >>> The INDEX instruction can be used to build such addressing modes, but
> >>> one base+index computation would take several instructions and at least
> >>> one temporary memory location if both "base" and "index" are dynamic
> >>> (non-constant) values, as would often be the case for accessing
> >>> subroutine arguments that are vectors or arrays.
> >>>
> >>
> >> Easy enough to use something like FORTRAN Common to fake this.
> >
> >Fortran Common areas are global variables, not subroutine arguments that 
> >can point to different variables on each call.
> >
> 
> Yes, I know.  Here's how it would work.  Suppose I have three
> parameters, A, B, and C, for a function, X.  You build X to read the
> three values from some shared area (those 'global variables').  Right
> before a call to X, the caller sets the values of the three parameters
> in Common to the values desired.  X reads those values and runs with
> them, changes them if that is desire behaviour, writes a functional
> return value to Common, whatever.  When X returns, the caller go reads
> the values X set and moves on.  Rinse and repeat.  The only difference
> is that instead of the compiler managing everything on the stack frame
> for you and having rules about whether you're calling by reference or
> by value, you do all that manually around the call to X.
> 
> This is dirt simple to do.  I shouldn't have to explain it.
> 

Agreed.  We're talking about programming for a primitive computer with 
very little RAM.  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.

Jeff
-- 
All opinions posted by me on Usenet News are mine, and mine alone.  
These posts do not reflect the opinions of my family, friends, 
employer, or any organization that I am a member of.

[toc] | [prev] | [next] | [standalone]

#57033

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
       .      @       .

[toc] | [prev] | [next] | [standalone]

#57038

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.


> 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 ?

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).

Device X may end up writing at address A, and device Y then reads from
A.  The compiler would think your program never uses the variable at
address A and allocates something else in that location.



> 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.

[toc] | [prev] | [next] | [standalone]

#57044

On Monday, July 18, 2016 at 3:49:27 AM UTC+12, JF Mezei wrote:
> On 2016-07-15 16:54, Niklas Holsti wrote:
> 
>  Older compilers likely
> had statically allocated data structures. 

You got that right!  The program was woven into the computer rope memory.

https://www.youtube.com/watch?v=YIBhPsyYCiM

It took about 10,500 keystrokes to carry out a mission.  

Today, we not only have better computers, we also have better software and better sensors.

https://www.youtube.com/watch?v=7P12e0WpjPQ

https://www.youtube.com/watch?v=cLTwT36l_U4

https://www.youtube.com/watch?v=A03AENwOVNY

https://www.youtube.com/watch?v=ZUY0w34jBIM

It's rather easy to create a system that can navigate seamlessly without a lot of operator intervention.

The problem has always been propulsion.  But advances in that area as well could make a spaceship in every garage possible!  

Micro-rockets

https://www.youtube.com/watch?v=Y7IsyjFROHE

http://www.bu.edu/phpbin/news-cms/news/?dept=1127&id=40897&template=226

Adaptation to assembly, coating, fabrication, separation, etc., etc.  

https://www.youtube.com/watch?v=r6TGvG7RUyo

Useful for self replicating machinery.

https://www.youtube.com/watch?v=BN-FU8VPoOc


A long-duration biosuit with MEMS based life support

http://www.nasa.gov/pdf/617047main_45s_building_future_spacesuit.pdf

Massing only 15 kg and provides 32 days of support - with full recycling of air and water - using only 12.8 kg of dried consumable materials.  

http://www.nss.org/settlement/ColoniesInSpace/fig0903.gif

686 grams of oxygen consumed per day along with 270 grams of hydrocarbons produces 857 grams of CO2 per day and 64 grams of H2O.  

702 cc of water broken down into 624 grams of oxygen and 78 grams of hydrogen each day produces sufficient hydrogen when combined with process hydrogen to combine with the 857 grams of CO2 to produce 312 grams of methane and 702cc of water.  The CH4 is reduced to 234 grams of Carbon black  and 78 grams of hydrogen.  

An additional 64 grams of H2O is broken down into 7 grams of hydrogen and 57 grams of oxygen.  This is added to the oxygen recovered from the CO2 and rebreathed.  

In all 772 cc of water is broken down into 686 grams of oxygen and 86 grams of hydrogen and 312 grams of methane is broken down into 234 grams of carbon black and 78 grams of hydrogen - giving enough hydrogen to absorb 857 grams of CO2 and recycling the oxygen.   The cost?  196 Watts!  With a hyper efficient solar panel, this requires a 5.3 cm diameter disk in space!  A larger collector stays well ahead of the needs for power.  

A biosuit equipped with a hyper efficient solar collecting flexible film, easily produces 1200 Watts of power continuously when exposed to sunlight in space near Earth.  

http://www.powerfilmsolar.com

With 200 Wh/kg of weight, modern super capacitors massing only 5 kg can supply breathable oxygen from a person's breath for five hours. 

http://spectrum.ieee.org/nanoclast/consumer-electronics/portable-devices/holey-graphene-boosts-energy-density-of-supercapacitors

An adult male astronaut will mass on average 90 kg  to 150 kg payload is sufficient to meet the needs of a traveller.

It takes 18 km/sec to go to the moon and return - in about 10 hours each way.   So, the astronaut can sleep in tansit, and spend 10 to 16 hours on the moon, active before returning - in less than two days.  

Using an electrospray rocket with 54 km/sec exhaust speed its easy to see tha 28.35% of the take off weight must be propellant.  Assuming no propellant is added on the lunar surface.  This means that 210 kg is the take off weight, with 60 kg propellant on board moving a 150 kg payload through 18 km/sec. 

To produce 2 gee at lift off requires a thrust of 4119 Newtons (420 kgf).  This requires 76.3 grams of propellant per second at lift off to be ejected at 54 km/sec.  This requires 111 MW of power be applied to the rocket.   This is supplied by a laser beam.

http://lasermotive.com

Which also doubles as a broadband communications system by beam modulation.  The suit is equipped with wings which receive the power, and form a spot 2 meters in diameter.  An emitter 129 meters in diameter on Earth is sufficient to beam a 2 meter diameter spot 384,400 km distant!   Even if only 1/4 of the light is received at the moon, 1/2 gee force can be exerted by the engine - which is 3x that needed to operate in the lunar environment of 1/6 gee.

This is on the order of the OWL Telescope - Overwhelmingly Large Telescope - 

https://en.wikipedia.org/wiki/Overwhelmingly_Large_Telescope

The $1.5 billion construction costs, could be reduced using inflatable optics, and building three of them 120 degrees apart in longitude, in the cloud free regions of the planet.    When not otherwise used for space operations, the transmitter could double as a large optical telescope!  

http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=856162

http://www.hindawi.com/journals/ijp/2015/196186/

Increasing the size of the space receiver increases power levels in the suit from sunlight, as well as reducing the size of the Earth bound mirror.

Two 16 meter diameter inflatable mirrors one on Earth and another carried by the astronaut, achieves an efficient transfer of power from Earth to Moon - when operating at 550 nm.  (green light).   A space based mirror this size also has the capacity to collect 254,868 watts of solar energy!   This is sufficient to produce 1/22nd gee during transit.  A sizeable amount!  Not enough to land, but sufficient amount to navigate without relying upon the terrestrial telescope.  

http://phys.org/news/2011-05-scientists-high-efficiency-ceramic-laser.html
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080007132.pdf
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080007132.pdf

https://www.osapublishing.org/DirectPDFAccess/D3C9C14F-94F6-F6CD-D7F907ED6F07785B_294315/oe-22-13-16386.pdf?da=1&id=294315&seq=0&mobile=no

http://princetonoptronics.com/pdfs/93810B_DL.pdf

200 megawatts of electrical power at each location, drives the laser array.  When not otherwise used, the power is used to support astronomers at each location.  

A 70 m diameter inflatable beam director, on the ground, connecting to a 5 m diameter inflatable receiver in flight - is a nice combination.  

Acceleration directly to lunar transfer velocity, arriving at the moon 10 hours later, which then slows the astronaut for direct landing on the lunar surface.  It takes about 20 minutes to launch, and another 6 minutes to land.  Three an hour - for six hours - projects 18 people to the moon - every day.    About $10,000 worth of power.  Charging enough to make $20 million per day - generates $7.3 billion per year free cash flow.  

One launch laser, one braking laser, and one return laser.  Each located in sunny cloud free regions separated by 120 degrees of longitude.   Atacama or Great American, Gobi or Thar or Gibson, Kalahari or Sahara or Arabian - all are interesting spots.  Mountain tops are also of interest.

Solar power for these sites allow demonstration of important technologies in addition to power beaming.  Sending people to the moon and back and maintaining broadband contact, promote the next step, the creation of a power satellite network along with a communications satellite network delivering power and broadband to wherever its needed.

Putting 300 kg modules into orbit, each one capable of collecting and transmitting 6.6 MW of useful energy from orbit, and operating as a single phased array unit at the optical bands, provides a way to expand the capacity of the terrestrial system.    Increasing to 11 GW from 0.11 GW increases take off weight from 210 kg to 21,000 kg for lunar operations and module power to 660 MW for power satellite operations.  

Swarms of free flying self replicating machines operating on Earth and on the lunar surface, with the ability to refuel on the moon, provide a means to easily move between Earth and moon, and in similar fashion, move around the solar system.

[toc] | [prev] | [next] | [standalone]

#57046

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/histoire/english/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
       .      @       .

[toc] | [prev] | [next] | [standalone]

#57027

>>Fortran Common areas are global variables, not subroutine arguments that 
>>can point to different variables on each call.


One register for the return address. One register contains address of
memory where a list of arguments is stored. So the subroutine looks at
that register and goes out to pick arguments as needed.

Normally, an architecture has a calling standard that defines which
register to use for that. (and which registers to put the return value
before you return control to the calling code.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | sci.space.policy

csiph-web