Re: LISP implementations on small machines

[Paul Koning via cctalk]

> On Oct 15, 2019, at 8:26 PM, Jay Jaeger via cctalk  
> wrote:
> 
> ...
> FYI there is a Burroughs 5500 simulator out there that runs ALGOL just
> fine.  Let me know if you want a pointer to the developer.

B5500 simulation is part of the current SIMH.

Apart from that, you can of course run ALGOL on a number of other machines, 
including PDP11, CDC Cyber, IBM 360, and others.

paul

Re: LISP implementations on small machines

[Jay Jaeger via cctalk]

On 10/4/2019 6:43 AM, David via cctalk wrote:
> 1976, UCSD. So I was using your Lisp.
> 
> I got a position on the UCSD Pascal project half way through that year 
> (reunion in just 2 weeks). So I’m very familiar with the p-code and how all 
> that works as well.
> 
> In 1978 I discovered Unix on a 780 in the 4th(?) floor lab and made the 
> switch from Pascal to C. Been a hard core Unix developer ever since. As a 
> result my name appears in almost all Apple products in the legal section.
> 
>   David
> 
>> On Oct 3, 2019, at 11:16 PM, Stan Sieler  wrote:
>>
>> David...where did you use Lisp on a B6700?
>>
>> Bill Gord and I wrote the first INTERLISP interpreter for the B6700 back 
>> around
>> 1974-1975, on a DARPA contract, at UCSD.  (At the start, it was to implement 
>> BBNLISP,
>> but the name changed during the project :)
>>
>> DARPA found that researchers using INTERLISP (or others) on Dec PDP10s (and 
>> similar) were hampered by the limited address space (256K virtual memory).  
>> The B6700 offered a significantly larger address space (and many other 
>> features, of course :)
>> (I know our LISP got distributed to other Burroughs sites in those days,
>> just like our STARTREK and Bob Jardine's SOLAR.)
>>
>> Danny Bobrow (with Xerox PARC at the time) came and helped us get started.
>> I met Warren Teitelman ... he had no idea that the cover of the INTERLISP 
>> manual was an homage to his last name.  (See: 
>> http://bitsavers.org/pdf/xerox/interlisp/Interlisp_Reference_Manual_Oct_1974.pdf
>>  
>> 
>>  )
>>
>> We got our system up and running, including DWIM and other packages, and 
>> were told ... oops, DEC figured out how to expand the amount of virtual 
>> memory on the PDP-10, so we don't need to buy Burroughs mainframes now!
>>
>> Our INTERLISP was a full interpreter, and also had a compiler to LISP 
>> p-code, which might have inspired UCSD Pascal's p-code (Ken Bowles was our 
>> boss). 
>>
>> I believe I have the source, in Burroughs ALGOL.
>>
>> As a side bonus, I got to interact with Danny, and people from PARC and BBN 
>> as we were watching other UCSD Computer Center people put the B6700 on the 
>> ARPANET.  (I think we were something like the 25th computer.)
>>
>> Stan Sieler
>>
>>
> 
> 

FYI there is a Burroughs 5500 simulator out there that runs ALGOL just
fine.  Let me know if you want a pointer to the developer.

JRJ

Re: LISP implementations on small machines

[Jay Jaeger via cctalk]

On 10/3/2019 1:04 PM, Guy Sotomayor Jr via cctalk wrote:
> 
> 
>> On Oct 3, 2019, at 10:26 AM, Paul Koning via cctalk  
>> wrote:
>>
>>
>>
>>> On Oct 3, 2019, at 12:39 PM, Chuck Guzis via cctalk  
>>> wrote:
>>>
>>> On 10/3/19 9:01 AM, Noel Chiappa via cctalk wrote:
>>>
 The PDP-6 and KA10 (basically a re-implementation of the PDP-6 
 architecture)
 both had cheapo versions where addresses 0-15 were in main memory, but also
 had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
 Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
 a similar "fast memory option".
>>>
>>> A bit more contemporary example might be the low-end PIC
>>> microcontrollers (e.g. the 12F series).   Harvard architecture (14 bit
>>> instructions, 8 bit data), but data is variously described as
>>> "registers" (when used an instruction operand) or "memory" when
>>> addressed indirectly.   That is, the 64 bytes of SRAM can be referred to
>>> as either a memory location or as a register operand.
>>
>> Then again, the PDP-10 has that "two ways to refer to it" as well.  In that 
>> case, you do have dedicated register logic, and what happens is that memory 
>> addresses 0-15 are instead redirected to the register array.  The same 
>> applies to the EL-X8.  The way you can address things doesn't necessarily 
>> tell you what sort of storage mechanism is used for it.
>>
> 
> So does the PDP-11.  The 8 registers are mapped to the top 8 words of memory 
> so you can do some quite interesting things.  It is also possible to run a 
> (small) program in only the registers (e.g. no memory at all).
> 
> TTFN - Guy
> 
> 

FYI, not ALL PDP-11 implementations can do this.  In particular, the J11
(used in PDP-11/73 and others) does not map the registers into memory
locations.  I suspect, but have not verified, that any PDP-11 processor
with multiple register sets (e.g., one for user one for kernel, etc.)
are likely to behave this way.

(One on one reply since the message was quite old.)

JRJ

Re: LISP implementations on small machines

[Eric Smith via cctalk]

I wrote:

> Code can be executed from the MMU PAR registers on processors with
> 22-bit addressing (11/23, 11/24, 11/44, 11/70, and J-11 based systems).
>

On Fri, Oct 4, 2019 at 2:25 PM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> My QBUS machine is apart at the moment, so I can't verify this before
> posting, but I don't think this hack works on the J-11 machines;
>

You're correct, I misremembered. F-11 and TTL machines with 22-bit
addressing can execute out of the PARs, but the J-11 cannot.

Re: LISP implementations on small machines

[Noel Chiappa via cctalk]

> From: Eric Smith

> Code can be executed from the MMU PAR registers on processors with
> 22-bit addressing (11/23, 11/24, 11/44, 11/70, and J-11 based systems). 

My QBUS machine is apart at the moment, so I can't verify this before
posting, but I don't think this hack works on the J-11 machines; I
documented this behaviour here:

  http://gunkies.org/wiki/KDJ11_CPUs#Code_in_PARs

It does work with F-11 processors (/23, etc). Not sure about model A
F-11's, which only have 18-bit QBUS addressing.

Noel

Re: LISP implementations on small machines

[Eric Smith via cctalk]

On Thu, Oct 3, 2019 at 12:04 PM Guy Sotomayor Jr via cctalk <
cctalk@classiccmp.org> wrote:

> So does the PDP-11.  The 8 registers are mapped to the top 8 words of
> memory so you can do some quite interesting things.  It is also possible to
> run a (small) program in only the registers (e.g. no memory at all).
>

That's not an actual PDP-11 architectural feature, and it only works on the
KD-11B CPU (PDP-11/05 and 11/10). No other models can execute code from the
general purpose registers, or access the GPRs via a memory address. When an
instruction word is fetched from a GPR, the PC is only incremented by one,
because the 16-bit registers are at consecutive addresses, rather than
multiples of two as one would expect. The GPRs are not byte-addressable.

On all other Unibus PDP-11 processors made from TTL (i.e., not based on the
F11 or J11), the general-purpose registers can be accessed at the same
addresses from the console, but NOT from software.

Code can be executed from the MMU PAR registers on processors with 22-bit
addressing (11/23, 11/24, 11/44, 11/70, and J-11 based systems). These are
word registers at word addresses, so they don't have the increment-by-one
hack of the 11/05 executing from GPRs.

Re: LISP implementations on small machines

[John Foust via cctalk]

At 06:43 AM 10/4/2019, David via cctalk wrote:
>1976, UCSD. So I was using your Lisp.
>
>I got a position on the UCSD Pascal project half way through that year 
>(reunion in just 2 weeks). So I’m very familiar with the p-code and how all 
>that works as well.

UCSD Pascal reunion, Saturday October 19:

https://homecoming.ucsd.edu/s/1170/hc19/interior.aspx?sid=1170=1=9890=21379=21379=0=9411=20541
 

- John

Re: LISP implementations on small machines

[David via cctalk]

1976, UCSD. So I was using your Lisp.

I got a position on the UCSD Pascal project half way through that year (reunion 
in just 2 weeks). So I’m very familiar with the p-code and how all that works 
as well.

In 1978 I discovered Unix on a 780 in the 4th(?) floor lab and made the switch 
from Pascal to C. Been a hard core Unix developer ever since. As a result my 
name appears in almost all Apple products in the legal section.

David

> On Oct 3, 2019, at 11:16 PM, Stan Sieler  wrote:
> 
> David...where did you use Lisp on a B6700?
> 
> Bill Gord and I wrote the first INTERLISP interpreter for the B6700 back 
> around
> 1974-1975, on a DARPA contract, at UCSD.  (At the start, it was to implement 
> BBNLISP,
> but the name changed during the project :)
> 
> DARPA found that researchers using INTERLISP (or others) on Dec PDP10s (and 
> similar) were hampered by the limited address space (256K virtual memory).  
> The B6700 offered a significantly larger address space (and many other 
> features, of course :)
> (I know our LISP got distributed to other Burroughs sites in those days,
> just like our STARTREK and Bob Jardine's SOLAR.)
> 
> Danny Bobrow (with Xerox PARC at the time) came and helped us get started.
> I met Warren Teitelman ... he had no idea that the cover of the INTERLISP 
> manual was an homage to his last name.  (See: 
> http://bitsavers.org/pdf/xerox/interlisp/Interlisp_Reference_Manual_Oct_1974.pdf
>  
> 
>  )
> 
> We got our system up and running, including DWIM and other packages, and were 
> told ... oops, DEC figured out how to expand the amount of virtual memory on 
> the PDP-10, so we don't need to buy Burroughs mainframes now!
> 
> Our INTERLISP was a full interpreter, and also had a compiler to LISP p-code, 
> which might have inspired UCSD Pascal's p-code (Ken Bowles was our boss). 
> 
> I believe I have the source, in Burroughs ALGOL.
> 
> As a side bonus, I got to interact with Danny, and people from PARC and BBN 
> as we were watching other UCSD Computer Center people put the B6700 on the 
> ARPANET.  (I think we were something like the 25th computer.)
> 
> Stan Sieler
> 
> 

Re: LISP implementations on small machines

[jim stephens via cctalk]

On 10/1/2019 7:23 PM, Mark Kahrs via cctalk wrote:

The first implementation was done for the 7090 by McCarthy (hence CAR and
CDR --- Contents of Address Register and Contents of Decrement Register).

If you want to see a tiny implementation then look for the PDP-1
implementation done by L Peter Deutsch.  There's a book chapter and then I
found this report:

http://s3data.computerhistory.org/pdp-1/DEC.pdp_1.1964.102650371.pdf
When I was at UMR a couple of students wrote a Lisp interpreter for the 
Micro 1600 running the 1621 firmware.  It had the missing feature that 
there was no garbage collect, and would die when the cells storage ran 
out.  Very quickly.


They then added paging to a 5mb dynex and used the entire space of the 
bottom platter, at 2.5mb and ran a lot longer with paging.


And they then added a firmware assist to do a couple of operations if 
they were recognized, and it supposedly ran a bit faster, but with disk 
paging, hard to tell.


I could try to dig up the source if anyone is interested and share it.  
I've got an emulator which runs the OS and firmware for the 1621 and 
it's on my list of programs to resurrect and get running.


FWIW, I had soaked up enough lisp from this and a version which ran in 
batch on the 360/50 MVT system that I knew it well enough to be 
dangerous on the Multics system at the University of Southwestern 
Louisiana, Lafayette, LA


It of course ran maclisp.  The main thing that was fun to play with 
there was macsyma.  When Professor Jerry Saltzer visited the site was 
grateful to visit with him as he had a lot to do with the system and 
macsyma in particular.


Forget Eliza and such, if you had macsyma in 1975, you'd swear you were 
talking to something out of this world.  I also remembered enough of my 
math to run it thru a lot of problems and it was able to figure them 
out, even with some trickery.


There is a version for the Multics Emulator, but I don't think the 
version I could have saved in 1975 was saved.  I hope to get that 
running at some point (most likely after someone else gets it running, 
as macsyma isn't a program for the faint hearted to try to get running).


thanks
Jim

Re: LISP implementations on small machines

[Stan Sieler via cctalk]

David...where did you use Lisp on a B6700?

Bill Gord and I wrote the first INTERLISP interpreter for the B6700 back
around
1974-1975, on a DARPA contract, at UCSD.  (At the start, it was to
implement BBNLISP,
but the name changed during the project :)

DARPA found that researchers using INTERLISP (or others) on Dec PDP10s (and
similar) were hampered by the limited address space (256K virtual memory).
The B6700 offered a significantly larger address space (and many other
features, of course :)
(I know our LISP got distributed to other Burroughs sites in those days,
just like our STARTREK and Bob Jardine's SOLAR.)

Danny Bobrow (with Xerox PARC at the time) came and helped us get started.
I met Warren Teitelman ... he had no idea that the cover of the
INTERLISP manual was an homage to his last name.  (See:
http://bitsavers.org/pdf/xerox/interlisp/Interlisp_Reference_Manual_Oct_1974.pdf
 )

We got our system up and running, including DWIM and other packages, and
were told ... oops, DEC figured out how to expand the amount of virtual
memory on the PDP-10, so we don't need to buy Burroughs mainframes now!

Our INTERLISP was a full interpreter, and also had a compiler to LISP
p-code, which might have inspired UCSD Pascal's p-code (Ken Bowles was our
boss).

I believe I have the source, in Burroughs ALGOL.

As a side bonus, I got to interact with Danny, and people from PARC and BBN
as we were watching other UCSD Computer Center people put the B6700 on the
ARPANET.  (I think we were something like the 25th computer.)

Stan Sieler

Re: LISP implementations on small machines

[Phil Budne via cctalk]

Noel wrote:
> The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
> both had cheapo versions where addresses 0-15 were in main memory, but also
> had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
> Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
> a similar "fast memory option".

http://www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-HMAA-D%20PDP-10%20KA10%20Central%20Processor%20Maintenance%20Manual%20Volume%20I.pdf
p 1-1 (pdf pg 13) says the CPU options were:

KE10  Extended Order Code (byte instructions)
KT10  Memory Protection and Relocation
KT10A Double Memory Protection and Relocation
KM10  Fast Registers

Elsewhere I have the note the the fast registers had 0.21 microsecond
access time.

Re: LISP implementations on small machines

[Guy Sotomayor Jr via cctalk]

> On Oct 3, 2019, at 10:26 AM, Paul Koning via cctalk  
> wrote:
> 
> 
> 
>> On Oct 3, 2019, at 12:39 PM, Chuck Guzis via cctalk  
>> wrote:
>> 
>> On 10/3/19 9:01 AM, Noel Chiappa via cctalk wrote:
>> 
>>> The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
>>> both had cheapo versions where addresses 0-15 were in main memory, but also
>>> had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
>>> Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
>>> a similar "fast memory option".
>> 
>> A bit more contemporary example might be the low-end PIC
>> microcontrollers (e.g. the 12F series).   Harvard architecture (14 bit
>> instructions, 8 bit data), but data is variously described as
>> "registers" (when used an instruction operand) or "memory" when
>> addressed indirectly.   That is, the 64 bytes of SRAM can be referred to
>> as either a memory location or as a register operand.
> 
> Then again, the PDP-10 has that "two ways to refer to it" as well.  In that 
> case, you do have dedicated register logic, and what happens is that memory 
> addresses 0-15 are instead redirected to the register array.  The same 
> applies to the EL-X8.  The way you can address things doesn't necessarily 
> tell you what sort of storage mechanism is used for it.
> 

So does the PDP-11.  The 8 registers are mapped to the top 8 words of memory so 
you can do some quite interesting things.  It is also possible to run a (small) 
program in only the registers (e.g. no memory at all).

TTFN - Guy

Re: LISP implementations on small machines

[Paul Koning via cctalk]

> On Oct 3, 2019, at 12:39 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 10/3/19 9:01 AM, Noel Chiappa via cctalk wrote:
> 
>> The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
>> both had cheapo versions where addresses 0-15 were in main memory, but also
>> had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
>> Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
>> a similar "fast memory option".
> 
> A bit more contemporary example might be the low-end PIC
> microcontrollers (e.g. the 12F series).   Harvard architecture (14 bit
> instructions, 8 bit data), but data is variously described as
> "registers" (when used an instruction operand) or "memory" when
> addressed indirectly.   That is, the 64 bytes of SRAM can be referred to
> as either a memory location or as a register operand.

Then again, the PDP-10 has that "two ways to refer to it" as well.  In that 
case, you do have dedicated register logic, and what happens is that memory 
addresses 0-15 are instead redirected to the register array.  The same applies 
to the EL-X8.  The way you can address things doesn't necessarily tell you what 
sort of storage mechanism is used for it.

paul

Re: LISP implementations on small machines

[ben via cctalk]

On 10/3/2019 10:01 AM, Noel Chiappa via cctalk wrote:

 > From: Paul Koning

 > Some early machines, the PDP-6 I believe is an example, have
 > "registers" in the ISA but they actually correspond to specific parts
 > of main memory.

The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
both had cheapo versions where addresses 0-15 were in main memory, but also
had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
a similar "fast memory option".

Noel

The PDP-5 how soon theyy forget. The PC was in core memory for sure.
Not sure about the AC how ever.
The IBM 1130 had the index registers in Core at something like  1,2,3.

Today Fast memory is .4 ps. I wonder how the old machines
would compare with today's wonder CPU's assuming the same transistor
speeds.Ben.

Re: LISP implementations on small machines

[Chuck Guzis via cctalk]

On 10/3/19 9:01 AM, Noel Chiappa via cctalk wrote:

> The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
> both had cheapo versions where addresses 0-15 were in main memory, but also
> had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
> Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
> a similar "fast memory option".

A bit more contemporary example might be the low-end PIC
microcontrollers (e.g. the 12F series).   Harvard architecture (14 bit
instructions, 8 bit data), but data is variously described as
"registers" (when used an instruction operand) or "memory" when
addressed indirectly.   That is, the 64 bytes of SRAM can be referred to
as either a memory location or as a register operand.

This isn't unusual--the original STAR-100 had 256 64-bit registers that
could be addressed as register storage or as the first 256 words of
memory.  Eventually, this capability was disabled (the so-called "Rev.
R" ECO) because of conflicts in usage.

--Chuck

Re: LISP implementations on small machines

[Noel Chiappa via cctalk]

> From: Paul Koning

> Some early machines, the PDP-6 I believe is an example, have
> "registers" in the ISA but they actually correspond to specific parts
> of main memory.

The PDP-6 and KA10 (basically a re-implementation of the PDP-6 architecture)
both had cheapo versions where addresses 0-15 were in main memory, but also
had an option for real registers, e.g. in the PDP-6: "The Type 162 Fast
Memory Module contains 16 words with a 0.4 usecond cycle." The KA10 has
a similar "fast memory option".

Noel

Re: LISP implementations on small machines

[Stefan Skoglund via cctalk]

ons 2019-10-02 klockan 19:02 + skrev Rich Alderson via cctalk:
> From: Mark Kahrs
> Sent: Tuesday, October 01, 2019 7:24 PM
> 
> > The first implementation was done for the 7090 by McCarthy (hence
> > CAR and
> > CDR --- Contents of Address Register and Contents of Decrement
> > Register).
> 
> In the 70x series of IBM scientific systems (704, 709, 7040, 7090,
> 7044, 7094),
> the word "register" referred to memory locations rather than to the
> accumulator
> or multiplier/quotient.  Each memory register was 36 bits long, and
> could be
> treated as 4 fields: A 15 bit address, a 15 bit decrement, a 3 bit
> tag, and a
> 3 bit index selector.
> 
> In the earliest implementation of LISP, there were 4 functions which
> returned
> the different parts of a register: CAR, CDR, CTR, and CIR.  These
> were
> abbreviations for "Contents of the {Address, Decrement, Tag, Index}
> PART OF THE
> Register", not "Contents of the {Address, Decrement} Register" as is
> so often
> misstated.
> 
> Rich
> 
> NB: Information from a talk given on the history of Lisp by Herbert
> Stoyan at
> the 1984 ACM Conference on Lisp and Functional Programming Languages,
> and later
> verified by personal inspection of the code.

It seems that simh has prebuilt ibm 70xx machines with lisp installed.
https://simh.trailing-edge.narkive.com/WiVs5570/release-of-a-set-of-simulators-for-ibm-7000-series-mainframes

Re: LISP implementations on small machines

[Paul Koning via cctalk]

> On Oct 2, 2019, at 3:02 PM, Rich Alderson via cctalk  
> wrote:
> 
> From: Mark Kahrs
> Sent: Tuesday, October 01, 2019 7:24 PM
> 
>> The first implementation was done for the 7090 by McCarthy (hence CAR and
>> CDR --- Contents of Address Register and Contents of Decrement Register).
> 
> In the 70x series of IBM scientific systems (704, 709, 7040, 7090, 7044, 
> 7094),
> the word "register" referred to memory locations rather than to the 
> accumulator
> or multiplier/quotient.  Each memory register was 36 bits long, and could be
> treated as 4 fields: A 15 bit address, a 15 bit decrement, a 3 bit tag, and a
> 3 bit index selector.

While we now think of "register" as a specific bit of hardware distinct from 
memory, that isn't necessary.  The term makes perfect sense as a small set of 
storage elements that are treated differently than main memory in the 
instruction set.  For example, the IBM 1620 has no registers (the ISA only 
references main memory).  Some early machines, the PDP-6 I believe is an 
example, have "registers" in the ISA but they actually correspond to specific 
parts of main memory.  Ditto the Philips PR-8000, which has 8 sets of 8 
registers (one set for each interrupt priority level) actually implemented in 
locations 0-63 of main memory.

In a 1948 computer architecture course. Adriaan van Wijngaarden referred to 
"fast memory" for what we now call registers; that document in effect is an 
early discussion of memory hierarchy.

paul

Re: LISP implementations on small machines

[David via cctalk]

Thanks for that bit of historical information. Things always make more sense in 
context. When I learned lisp on a B6700 it was hard to understand and harder to 
program. With this bit of context lisp now makes a lot more sense, and looking 
back if I knew this then I’m sure I would have grasped the language much more 
quickly.

David

> On Oct 2, 2019, at 12:02 PM, Rich Alderson via cctech  
> wrote:
> 
> From: Mark Kahrs
> Sent: Tuesday, October 01, 2019 7:24 PM
> 
>> The first implementation was done for the 7090 by McCarthy (hence CAR and
>> CDR --- Contents of Address Register and Contents of Decrement Register).
> 
> In the 70x series of IBM scientific systems (704, 709, 7040, 7090, 7044, 
> 7094),
> the word "register" referred to memory locations rather than to the 
> accumulator
> or multiplier/quotient.  Each memory register was 36 bits long, and could be
> treated as 4 fields: A 15 bit address, a 15 bit decrement, a 3 bit tag, and a
> 3 bit index selector.
> 
> In the earliest implementation of LISP, there were 4 functions which returned
> the different parts of a register: CAR, CDR, CTR, and CIR.  These were
> abbreviations for "Contents of the {Address, Decrement, Tag, Index} PART OF 
> THE
> Register", not "Contents of the {Address, Decrement} Register" as is so often
> misstated.
> 
>Rich
> 
> NB: Information from a talk given on the history of Lisp by Herbert Stoyan at
> the 1984 ACM Conference on Lisp and Functional Programming Languages, and 
> later
> verified by personal inspection of the code.

RE: LISP implementations on small machines

[Rich Alderson via cctalk]

From: Mark Kahrs
Sent: Tuesday, October 01, 2019 7:24 PM

> The first implementation was done for the 7090 by McCarthy (hence CAR and
> CDR --- Contents of Address Register and Contents of Decrement Register).

In the 70x series of IBM scientific systems (704, 709, 7040, 7090, 7044, 7094),
the word "register" referred to memory locations rather than to the accumulator
or multiplier/quotient.  Each memory register was 36 bits long, and could be
treated as 4 fields: A 15 bit address, a 15 bit decrement, a 3 bit tag, and a
3 bit index selector.

In the earliest implementation of LISP, there were 4 functions which returned
the different parts of a register: CAR, CDR, CTR, and CIR.  These were
abbreviations for "Contents of the {Address, Decrement, Tag, Index} PART OF THE
Register", not "Contents of the {Address, Decrement} Register" as is so often
misstated.

Rich

NB: Information from a talk given on the history of Lisp by Herbert Stoyan at
the 1984 ACM Conference on Lisp and Functional Programming Languages, and later
verified by personal inspection of the code.

Re: LISP implementations on small machines

[Jack Harper via cctalk]

Correction!  IBM 
704!Jack-Jack HarperSecure 
Outcomes Inc2942 Evergreen ParkwaySuite 300Evergreen, Colorado 
80439303.670.8375 Officewww.secureoutcomesinc.com for Product Info.
 Original message From: Jack Harper 
 Date: 10/2/19  13:36  (GMT-07:00) To: Lars 
Brinkhoff , "General Discussion: On-Topic and Off-Topic Posts" 
, Bill Degnan via cctech  Cc: 
Bill Degnan  Subject: Re: LISP implementations on small 
machines Hello List -That jives with a conversation I had with John McCarthy 
before he died.He said that he and friends began the LISP 1.5 (really 1.0) 
implementation on the IBM 709 - and we both agreed that the idea of LISP 
running in an enormous pile of vacuum tubes was and is 
amazing:)Jack-Jack 
HarperSecure Outcomes Inc2942 Evergreen ParkwaySuite 300Evergreen, Colorado 
80439303.670.8375 Officewww.secureoutcomesinc.com for Product Info. 
Original message From: Lars Brinkhoff via cctalk 
 Date: 10/2/19  07:42  (GMT-07:00) To: Bill Degnan via 
cctech  Cc: Bill Degnan  Subject: 
Re: LISP implementations on small machines Bill Degnan wrote:> First full 
version 7090 and then a version was ported tot he PDP-1> that was less 
powerful.  This is straight from the LISP manual on> site.Which LISP manual is 
that?The LISP I Programmer's Manual from 1960 says IBM 704.  It also says 
"aversion of LISP I is being prepared for the IBM 
709".http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf

Re: LISP implementations on small machines

[Jack Harper via cctalk]

Correction!  IBM 
704!Jack-Jack HarperSecure 
Outcomes Inc2942 Evergreen ParkwaySuite 300Evergreen, Colorado 
80439303.670.8375 Officewww.secureoutcomesinc.com for Product Info.
 Original message From: Jack Harper 
 Date: 10/2/19  13:36  (GMT-07:00) To: Lars 
Brinkhoff , "General Discussion: On-Topic and Off-Topic Posts" 
, Bill Degnan via cctech  Cc: 
Bill Degnan  Subject: Re: LISP implementations on small 
machines Hello List -That jives with a conversation I had with John McCarthy 
before he died.He said that he and friends began the LISP 1.5 (really 1.0) 
implementation on the IBM 709 - and we both agreed that the idea of LISP 
running in an enormous pile of vacuum tubes was and is 
amazing:)Jack-Jack 
HarperSecure Outcomes Inc2942 Evergreen ParkwaySuite 300Evergreen, Colorado 
80439303.670.8375 Officewww.secureoutcomesinc.com for Product Info. 
Original message From: Lars Brinkhoff via cctalk 
 Date: 10/2/19  07:42  (GMT-07:00) To: Bill Degnan via 
cctech  Cc: Bill Degnan  Subject: 
Re: LISP implementations on small machines Bill Degnan wrote:> First full 
version 7090 and then a version was ported tot he PDP-1> that was less 
powerful.  This is straight from the LISP manual on> site.Which LISP manual is 
that?The LISP I Programmer's Manual from 1960 says IBM 704.  It also says 
"aversion of LISP I is being prepared for the IBM 
709".http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf

Re: LISP implementations on small machines

[Jack Harper via cctalk]

Hello List -That jives with a conversation I had with John McCarthy before he 
died.He said that he and friends began the LISP 1.5 (really 1.0) implementation 
on the IBM 709 - and we both agreed that the idea of LISP running in an 
enormous pile of vacuum tubes was and is 
amazing:)Jack-Jack 
HarperSecure Outcomes Inc2942 Evergreen ParkwaySuite 300Evergreen, Colorado 
80439303.670.8375 Officewww.secureoutcomesinc.com for Product Info.
 Original message From: Lars Brinkhoff via cctalk 
 Date: 10/2/19  07:42  (GMT-07:00) To: Bill Degnan via 
cctech  Cc: Bill Degnan  Subject: 
Re: LISP implementations on small machines Bill Degnan wrote:> First full 
version 7090 and then a version was ported tot he PDP-1> that was less 
powerful.  This is straight from the LISP manual on> site.Which LISP manual is 
that?The LISP I Programmer's Manual from 1960 says IBM 704.  It also says 
"aversion of LISP I is being prepared for the IBM 
709".http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf

Re: LISP implementations on small machines

[Jack Harper via cctalk]

Hello List -That jives with a conversation I had with John McCarthy before he 
died.He said that he and friends began the LISP 1.5 (really 1.0) implementation 
on the IBM 709 - and we both agreed that the idea of LISP running in an 
enormous pile of vacuum tubes was and is 
amazing:)Jack-Jack 
HarperSecure Outcomes Inc2942 Evergreen ParkwaySuite 300Evergreen, Colorado 
80439303.670.8375 Officewww.secureoutcomesinc.com for Product Info.
 Original message From: Lars Brinkhoff via cctalk 
 Date: 10/2/19  07:42  (GMT-07:00) To: Bill Degnan via 
cctech  Cc: Bill Degnan  Subject: 
Re: LISP implementations on small machines Bill Degnan wrote:> First full 
version 7090 and then a version was ported tot he PDP-1> that was less 
powerful.  This is straight from the LISP manual on> site.Which LISP manual is 
that?The LISP I Programmer's Manual from 1960 says IBM 704.  It also says 
"aversion of LISP I is being prepared for the IBM 
709".http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf

Re: LISP implementations on small machines

[Bill Degnan via cctalk]

On Wed, Oct 2, 2019 at 4:39 AM Lars Brinkhoff via cctech <
cct...@classiccmp.org> wrote:

> Mark Kahrs wrote:
> > The first implementation was done for the 7090 by McCarthy (hence CAR
> > and CDR --- Contents of Address Register and Contents of Decrement
> > Register).
>
> Or was it an IBM 704?
>

First full version 7090 and then a version was ported tot he PDP-1 that was
less powerful.  This is straight from the LISP manual on site.
Bill

Re: LISP implementations on small machines

[Lars Brinkhoff via cctalk]

Bill Degnan wrote:
> First full version 7090 and then a version was ported tot he PDP-1
> that was less powerful.  This is straight from the LISP manual on
> site.

Which LISP manual is that?

The LISP I Programmer's Manual from 1960 says IBM 704.  It also says "a
version of LISP I is being prepared for the IBM 709".

http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf

Re: LISP implementations on small machines

[Lars Brinkhoff via cctalk]

Mark Kahrs wrote:
> The first implementation was done for the 7090 by McCarthy (hence CAR
> and CDR --- Contents of Address Register and Contents of Decrement
> Register).

Or was it an IBM 704?