[TUHS] Happy birthday, PDP-8!

[TUHS] Happy birthday, PDP-8!

[Dave Horsfall]

OT, but of interest to a few people here :-)

The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on 
the wrong side of the date line).  It was the first computer I ever 
used, back around 1970 (I think I'd just left school and was checking out 
the local University's computer department, with a view to majoring in 
Computer Science (which I did)).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, PDP-8!

[Ron Natalie]

Ah yes, the machine with only 8 instructions (of course not counting all the
multiplexing of OPR).
I was always fond of TAD.    Not particularly reentrant version of
subroutine linkage.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Tuesday, March 21, 2017 5:35 PM
To: The Eunuchs Hysterical Society
Subject: [TUHS] Happy birthday, PDP-8!

OT, but of interest to a few people here :-)

The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on
the wrong side of the date line).  It was the first computer I ever used,
back around 1970 (I think I'd just left school and was checking out the
local University's computer department, with a view to majoring in Computer
Science (which I did)).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."

[TUHS] Happy birthday, PDP-8!

[Dave Horsfall]

On Wed, 22 Mar 2017, Ron Natalie wrote:

> Ah yes, the machine with only 8 instructions (of course not counting all 
> the multiplexing of OPR).
> 
> I was always fond of TAD.  Not particularly reentrant version of 
> subroutine linkage.

Yep, it could add, but not subtract.  Dammit, but I'm trying to think of 
the CADET acronym; it went something like "Can't Add, Didn't Even Try".

And as for subroutine calls on the -8, let's not go there...  As I dimly 
recall, it planted the return address into the first word of the called 
routine and jumped to the second instruction; to return, you did an 
indirect jump to the first word.  Recursion?  What was that?

Somewhere out there (tm), is a huge list of computer acronyms (and yes, I 
know about "Instant Befuddled Mind", and "I've Been Misled" etc).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, PDP-8!

[Paul Winalski]

On 3/26/17, Dave Horsfall <dave at horsfall.org> wrote [regarding the PDP-8]:
> Yep, it could add, but not subtract.  Dammit, but I'm trying to think of
> the CADET acronym; it went something like "Can't Add, Didn't Even Try".
>
CADET was the official IBM internal development code name for the
1620, designed to be a low cost computer for the scientific
marketplace.  Part of the reduced cost was attained by abandoning the
traditional ALU circuitry.  Instead the 1620 did arithmetic by table
lookup.  The joke was made that CADET stood for "Can't Add, Doesn't
Even Try", and that interpretation stuck and became popular with the
machine's user community.

-Paul W.

[TUHS] Happy birthday, PDP-8!

[Greg 'groggy' Lehey]

On Sunday, 26 March 2017 at 16:11:30 -0400, Paul Winalski wrote:
> On 3/26/17, Dave Horsfall <dave at horsfall.org> wrote [regarding the PDP-8]:
>> Yep, it could add, but not subtract.  Dammit, but I'm trying to think of
>> the CADET acronym; it went something like "Can't Add, Didn't Even Try".
>>
> CADET was the official IBM internal development code name for the
> 1620, designed to be a low cost computer for the scientific
> marketplace.  Part of the reduced cost was attained by abandoning the
> traditional ALU circuitry.  Instead the 1620 did arithmetic by table
> lookup.  The joke was made that CADET stood for "Can't Add, Doesn't
> Even Try", and that interpretation stuck and became popular with the
> machine's user community.

I didn't know it was an official name of a project, and I thought it
referred to the 1401, the predecessor of the 1620.  To be fair, they
did arithmetic one byte at a time, so a table lookup made sense.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170327/587d75f7/attachment.sig>

[TUHS] Happy birthday, PDP-8!

[Greg 'groggy' Lehey]

On Monday, 27 March 2017 at  6:49:30 +1100, Dave Horsfall wrote:
>
> And as for subroutine calls on the -8, let's not go there...  As I dimly
> recall, it planted the return address into the first word of the called
> routine and jumped to the second instruction; to return, you did an
> indirect jump to the first word.  Recursion?  What was that?

This was fairly typical of the day.  I've used other machines (UNIVAC,
Control Data) that did the same.  Later models added a second call
method that stored the return address in a register instead, only
marginally easier for recursion.

At Uni I was given a relatively simple task to do in PDP-8 assembler:
a triple precision routine (36 bits!) to clip a value to ensure it
stayed between two limits.  Simple, eh?  Not on the PDP-8.  Three
parameters, each three words long. only one register, no index
registers.  I didn't finish it.  Revisiting now, I still don't know
how to do it elegantly.  How *did* the PDP-8 pass parameters?

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170327/f5420a37/attachment.sig>

[TUHS] Happy birthday, PDP-8!

[George Michaelson]

I briefly, at the age of 7 had a dual-processor cardboard pdp-8.

IFIP68 was held in edinburgh, and my dad was on the organizing
committee. So I got to go to the trade show alongside, and Dec had
cardboard 8's they handed out as a promotional freebie to anyone who
signed up.

I got two. But I'd had the wooden crate a PDP-1 came in for a backyard
tank before that so I was kinda- downsizing.

-G

On Wed, Mar 21, 2018 at 9:52 PM, Dave Horsfall <dave at horsfall.org> wrote:
> Let's see how much this thread can drift...
>
> The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on
> the wrong side of the date line).  It was the first computer I ever used,
> back around 1970 (I think I'd just left school and was checking out the
> local University's computer department, and played with BASIC and FOCAL).
>
> And (hopefully) coincidentally the Pentium first shipped in 1993; the
> infamous FDIV defect was discovered a year later (and it turned out that
> Intel was made aware of it by a post-grad student a bit earlier), and what
> followed next was an utter farce, with some dealers refusing to accept the
> results of a widely-distributed program as evidence of a faulty FPU.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."

[TUHS] Happy birthday, PDP-8!

[Dave Horsfall]

Let's see how much this thread can drift...

The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on 
the wrong side of the date line).  It was the first computer I ever used, 
back around 1970 (I think I'd just left school and was checking out the 
local University's computer department, and played with BASIC and FOCAL).

And (hopefully) coincidentally the Pentium first shipped in 1993; the 
infamous FDIV defect was discovered a year later (and it turned out that 
Intel was made aware of it by a post-grad student a bit earlier), and what 
followed next was an utter farce, with some dealers refusing to accept the 
results of a widely-distributed program as evidence of a faulty FPU.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, PDP-8!

[Johnny Billquist]

On 2017-03-28 09:37, jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>
>     > From: Johnny Billquist
>
>     > the PDP-11 have the means of doing this as well....  If anyone ever
>     > wondered about the strangeness of the JSR instruction of the PDP-11, it
>     > is precisely because of this.
>     > ...
>     > I doubt Unix ever used this, but maybe someone know of some obscure
>     > inner kernel code that do. :-)
>
> Actually Unix does use JSR with a non-PC register to hold the return address
> very extensively; but it also uses the 'saved PC points to the argument'
> technique; although only in a limited way. (Well, there may have been some
> user-mode commands that were not in C that used it, I don't know about that.)
>
> First, the 'PC points to arguments': the device interrrupts use that. All
> device interrupt vectors point to code that looks like:
>
> 	jsr r0, _call
> 	_iservice
>
> where iservice() is the interrupt service routine. call: is a common
> assembler-language routine that calls iservice(); the return from there goes
> to later down in call:, which does the return from interrupt.

Ah. Thanks for that. I hadn't dug into those parts, but that's the kind 
of place where I might have suspected it might have been, if anywhere.

> Use of a non-PC return address register is used in every C routine; to save
> space, there is only one copy of the linkage code that sets up the stack
> frame; PDP-11 C, by convention, uses R5 for the frame pointer. So that common
> code (csv) is called with a:
>
>      jsr r5, csv
>
> which saves the old FP on the stack; CSV does the rest of the work, and jumps
> back to the calling routine, at the address in R5 when csv: is entered. (There's
> a similar routine, cret:, to discard the frame, but it's 'called' with a plain
> jmp.)

Hah! Thinking about it, I actually knew that calling style, but didn't 
reflect on it, as you're not passing any arguments in the instruction 
stream in that situation.
But it's indeed not using the PC as the register in the call, so I guess 
it should count in some way. :-)

	Johnny

[TUHS] Happy birthday, PDP-8!

[Noel Chiappa]

    > From: Johnny Billquist

    > the PDP-11 have the means of doing this as well....  If anyone ever
    > wondered about the strangeness of the JSR instruction of the PDP-11, it
    > is precisely because of this.
    > ...
    > I doubt Unix ever used this, but maybe someone know of some obscure 
    > inner kernel code that do. :-)

Actually Unix does use JSR with a non-PC register to hold the return address
very extensively; but it also uses the 'saved PC points to the argument'
technique; although only in a limited way. (Well, there may have been some
user-mode commands that were not in C that used it, I don't know about that.)

First, the 'PC points to arguments': the device interrrupts use that. All
device interrupt vectors point to code that looks like:

	jsr r0, _call
	_iservice

where iservice() is the interrupt service routine. call: is a common
assembler-language routine that calls iservice(); the return from there goes
to later down in call:, which does the return from interrupt.

Use of a non-PC return address register is used in every C routine; to save
space, there is only one copy of the linkage code that sets up the stack
frame; PDP-11 C, by convention, uses R5 for the frame pointer. So that common
code (csv) is called with a:

     jsr r5, csv

which saves the old FP on the stack; CSV does the rest of the work, and jumps
back to the calling routine, at the address in R5 when csv: is entered. (There's
a similar routine, cret:, to discard the frame, but it's 'called' with a plain
jmp.)

	Noel

[TUHS] Happy birthday, PDP-8!

[Johnny Billquist]

And, as usual I have to correct myself a little, but I'll also tie in a 
bit with (almost) Unix in doing so. :-)

On 2017-03-28 01:33, Steve Nickolas wrote:
> On Tue, 28 Mar 2017, Johnny Billquist wrote:
>

[...]

>> The routine:
>>
>> COUNT,  0
>>        CIA
>>        DCA    CHR        / Save the negative of the word to search for.
>>        CMA
>>        TAD I  COUNT
>>        DCA    PTR        / Setup pointer to the address before the
>> buffer.
>>        ISZ    COUNT      / Point to next argument.
>>        TAD I  COUNT
>>        CIA
>>        DCA    CNT        / Save negative value of size.
>>        DCA    RESULT     / Clear out result counter.
>> LOOP,   TAD I  PTR        / Get next word in buffer.
>>        TAD    CHR        / Compare to searched for word.
>>        SNA               / Skip if they are not equal.

I knew I felt that something wasn't right, but it wasn't until I looked 
at your reply, Steve, that I found what it was.
This SNA should have been SNA CLA...

>>        ISZ    RESULT     / Equal. Increment result counter.
>>        ISZ    CNT        / Increment loop counter.
>>        JMP    LOOP       / Repeat unless end of buffer.
>>        CLA               / All done. Get result.

and CLA should not have been there.

>>        TAD    RESULT
>>        JMP I  COUNT      / Done.
>>
>> PTR=10
>> CNT=20
>> CHR=21
>> RESULT=22
>>
>>
>> Addresses 10-17 are the index registers, so the TAD I PTR instruction
>> will autoincrement the pointer everytime, and the increment happens
>> before the defer, which is why the initial value should be one less
>> than the buffer pointer.
>>
>> Hopefully this gives enough of an idea, but unless you know the PDP-8
>> well, you might be a little confused by the mnemonics.
>>
>> As you can see, the return address at the start is used for more than
>> just doing a return. It's also your argument pointer.
>>
>>  Johnny
>>
>>
>
> Actually, that reminds me of ProDOS-8 on the Apple ][, which uses a
> similar mechanism to pass parameters.

Interesting. Since the Apple ][ used the 6502, I would have assumed it 
used the stack, but I've never used the 6502 much, so I don't know if it 
possibly can make sense to write code this way on that processor.

Speaking of which, when the PDP-11 was introduced, it wasn't obvious 
that this style of coding wasn't sometimes appropriate, so the PDP-11 
have the means of doing this as well.
If anyone ever wondered about the strangeness of the JSR instruction of 
the PDP-11, it is precisely because of this.
What it does is that it pushes the argument register on the stack, loads 
the PC into the argument register, and then sets the new PC.
So, if you use some other register than R7 as the argument to JSR, that 
register then points to the word following the JSR, where you can have 
your arguments. And you fetch them with indirect autoincrement, and at 
the end you do an RTS with that same register, which at that point 
points beyond the arguments you had. And the register used for the 
argument pointer is restored by the RTS.

I've used it once or twice on a PDP-11, but this whole scheme only works 
if I-space and D-space are the same, so there are limitations.

I doubt Unix ever used this, but maybe someone know of some obscure 
inner kernel code that do. :-)

	Johnny

[TUHS] Happy birthday, PDP-8!

[Steve Nickolas]

On Tue, 28 Mar 2017, Johnny Billquist wrote:

> Essentially, you pass parameters in memory, as a part of the code stream. 
> Also, the PDP-8 certainly do have index registers.
>
> The first thing one must do is stop thinking of the AC as a register. The 
> accumulator is the accumulator. Memory is registers.
>
> Some memory locations autoincrement when used indirectly, they are called 
> index registers.
>
> That said, then. A simple example of a routine passing two parameters (well, 
> three):
>
> First the calling:
>
>        CLA
>        TAD   (42        / Setup AC with the value 42.
>        JMS   COUNT
>        BUFPTR
>        BUFSIZ
>        .                / Next instruction executed, with AC holding number 
> of matching words in buffer.
>        .
>
> Now, this routine is expected to count the number of occurances of a specific 
> word in a memory buffer with a specific size.
> At calling, AC will contain the word to search for, while the address 
> following the JMS holds the address, and the following address holds the 
> size.
>
> The routine:
>
> COUNT,  0
>        CIA
>        DCA    CHR        / Save the negative of the word to search for.
>        CMA
>        TAD I  COUNT
>        DCA    PTR        / Setup pointer to the address before the buffer.
>        ISZ    COUNT      / Point to next argument.
>        TAD I  COUNT
>        CIA
>        DCA    CNT        / Save negative value of size.
>        DCA    RESULT     / Clear out result counter.
> LOOP,   TAD I  PTR        / Get next word in buffer.
>        TAD    CHR        / Compare to searched for word.
>        SNA               / Skip if they are not equal.
>        ISZ    RESULT     / Equal. Increment result counter.
>        ISZ    CNT        / Increment loop counter.
>        JMP    LOOP       / Repeat unless end of buffer.
>        CLA               / All done. Get result.
>        TAD    RESULT
>        JMP I  COUNT      / Done.
>
> PTR=10
> CNT=20
> CHR=21
> RESULT=22
>
>
> Addresses 10-17 are the index registers, so the TAD I PTR instruction will 
> autoincrement the pointer everytime, and the increment happens before the 
> defer, which is why the initial value should be one less than the buffer 
> pointer.
>
> Hopefully this gives enough of an idea, but unless you know the PDP-8 well, 
> you might be a little confused by the mnemonics.
>
> As you can see, the return address at the start is used for more than just 
> doing a return. It's also your argument pointer.
>
>  Johnny
>
>

Actually, that reminds me of ProDOS-8 on the Apple ][, which uses a 
similar mechanism to pass parameters.

-uso.

[TUHS] Happy birthday, PDP-8!

[Johnny Billquist]

On 2017-03-27 04:00, Greg 'groggy' Lehey <grog at lemis.com> wrote:

 > On Monday, 27 March 2017 at  6:49:30 +1100, Dave Horsfall wrote:
 >> And as for subroutine calls on the -8, let's not go there...  As I dimly
 >> recall, it planted the return address into the first word of the called
 >> routine and jumped to the second instruction; to return, you did an
 >> indirect jump to the first word.  Recursion?  What was that?
 > This was fairly typical of the day.  I've used other machines (UNIVAC,
 > Control Data) that did the same.  Later models added a second call
 > method that stored the return address in a register instead, only
 > marginally easier for recursion.
 >
 > At Uni I was given a relatively simple task to do in PDP-8 assembler:
 > a triple precision routine (36 bits!) to clip a value to ensure it
 > stayed between two limits.  Simple, eh?  Not on the PDP-8.  Three
 > parameters, each three words long. only one register, no index
 > registers.  I didn't finish it.  Revisiting now, I still don't know
 > how to do it elegantly.  How *did* the PDP-8 pass parameters?

This is probably extremely off-topic, so I'll keep it short.

This is actually very simple and straight forward on a PDP-8, but it 
might seem strange to people used to todays computers.

Essentially, you pass parameters in memory, as a part of the code 
stream. Also, the PDP-8 certainly do have index registers.

The first thing one must do is stop thinking of the AC as a register. 
The accumulator is the accumulator. Memory is registers.

Some memory locations autoincrement when used indirectly, they are 
called index registers.

That said, then. A simple example of a routine passing two parameters 
(well, three):

First the calling:

         CLA
         TAD   (42        / Setup AC with the value 42.
         JMS   COUNT
         BUFPTR
         BUFSIZ
         .                / Next instruction executed, with AC holding 
number of matching words in buffer.
         .

Now, this routine is expected to count the number of occurances of a 
specific word in a memory buffer with a specific size.
At calling, AC will contain the word to search for, while the address 
following the JMS holds the address, and the following address holds the 
size.

The routine:

COUNT,  0
         CIA
         DCA    CHR        / Save the negative of the word to search for.
         CMA
         TAD I  COUNT
         DCA    PTR        / Setup pointer to the address before the buffer.
         ISZ    COUNT      / Point to next argument.
         TAD I  COUNT
         CIA
         DCA    CNT        / Save negative value of size.
         DCA    RESULT     / Clear out result counter.
LOOP,   TAD I  PTR        / Get next word in buffer.
         TAD    CHR        / Compare to searched for word.
         SNA               / Skip if they are not equal.
         ISZ    RESULT     / Equal. Increment result counter.
         ISZ    CNT        / Increment loop counter.
         JMP    LOOP       / Repeat unless end of buffer.
         CLA               / All done. Get result.
         TAD    RESULT
         JMP I  COUNT      / Done.

PTR=10
CNT=20
CHR=21
RESULT=22


Addresses 10-17 are the index registers, so the TAD I PTR instruction 
will autoincrement the pointer everytime, and the increment happens 
before the defer, which is why the initial value should be one less than 
the buffer pointer.

Hopefully this gives enough of an idea, but unless you know the PDP-8 
well, you might be a little confused by the mnemonics.

As you can see, the return address at the start is used for more than 
just doing a return. It's also your argument pointer.

   Johnny

[TUHS] Happy birthday, PDP-8!

[Terry Smith]

We had a PDP 8E and an 8I at Humber College back in the day. I used to 
play chess against Chekmo2 on it on paper tape.


On 2017-03-27 08:05 AM, Tim Bradshaw wrote:
> On 27 Mar 2017, at 01:31, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>>
>> That style of subroutine call goes back a _long_ way. IIRC, Whirlwind used
>> that kind of linkage (alas, I've misplaced my copy of the Whirlwind
>> instruction manual, sigh - a real tresure).
> This is how subroutines worked on EDSAC.  It might go back further than this, but it can't go back much further..
>

[TUHS] Happy birthday, PDP-8!

[Arthur Krewat]

And how is that different than the Intel line of CPU's? Backward 
compatibility, while adding features as it progressed.

The KA10, KI10, KL10, KS10 all added something to the mix that their 
predecessors did not have.

To call something a "clone" infers a second party making as close of a 
copy as possible to the original. The KA10 was not a "clone" of a PDP-6.

http://www.ultimate.com/phil/pdp10/pdp6-vs-ka10



On 3/26/2017 9:24 PM, Noel Chiappa wrote:
>      > From: Arthur Krewat
>
>      >> The PDP-6 (of which the PDP-10 was a clone)
>
>      > Um. More like a natural progression.
>      > Like 8086->80186->80286->80386->80486->...
>
> No, the PDP-6 and PDP-10 have identical instruction sets, and in general, a
> program that will run on one, will run on the other. See "decsystem10 System
> Reference Manual" (DEC-10-XSRMA-A=D", pg. 2-72., which provides a 7-instruction
> code fragment which allows a program to work out if it's running on a PDP-6, a
> KA10, or a KI10.
>
> The KA10 is a re-implementation (using mostly B-series Flip Chips) of the
> PDP-6 (which was built out of System Modules - the predecessor to Flip Chips).
>
>         Noel
>

[TUHS] Happy birthday, PDP-8!

[Tony Finch]

Tim Bradshaw <tfb at tfeb.org> wrote:
>
> This is how subroutines worked on EDSAC.  It might go back further than
> this, but it can't go back much further.

I found this rather good survey of early subroutine linkage:
https://people.cs.clemson.edu/~mark/subroutines.html

Turing designed a stack-based linkage for the ACE, a few years before
Wheeler invented the EDSAC subroutine linkage.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: East, veering south later, 4 or 5. Smooth or slight, occasionally
moderate later in south. Showers later. Good.

[TUHS] Happy birthday, PDP-8!

[Tim Bradshaw]

On 27 Mar 2017, at 01:31, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> 
> That style of subroutine call goes back a _long_ way. IIRC, Whirlwind used
> that kind of linkage (alas, I've misplaced my copy of the Whirlwind
> instruction manual, sigh - a real tresure).

This is how subroutines worked on EDSAC.  It might go back further than this, but it can't go back much further.

[TUHS] Happy birthday, PDP-8!

[Noel Chiappa]

    > From: Arthur Krewat

    >> The PDP-6 (of which the PDP-10 was a clone)

    > Um. More like a natural progression.
    > Like 8086->80186->80286->80386->80486->...

No, the PDP-6 and PDP-10 have identical instruction sets, and in general, a
program that will run on one, will run on the other. See "decsystem10 System
Reference Manual" (DEC-10-XSRMA-A=D", pg. 2-72., which provides a 7-instruction
code fragment which allows a program to work out if it's running on a PDP-6, a
KA10, or a KI10.

The KA10 is a re-implementation (using mostly B-series Flip Chips) of the
PDP-6 (which was built out of System Modules - the predecessor to Flip Chips).

       Noel

[TUHS] Happy birthday, PDP-8!

[Arthur Krewat]

Um. More like a natural progression.

Like 8086->80186->80286->80386->80486->...

On 3/26/2017 8:31 PM, Noel Chiappa wrote:
> The PDP-6 (of which the PDP-10 was a clone)

[TUHS] Happy birthday, PDP-8!

[Noel Chiappa]

    > From: Dave Horsfall

    > And as for subroutine calls on the -8, let's not go there...  As I dimly
    > recall, it planted the return address into the first word of the called
    > routine and jumped to the second instruction; to return, you did an
    > indirect jump to the first word.

That do be correct.

That style of subroutine call goes back a _long_ way. IIRC, Whirlwind used
that kind of linkage (alas, I've misplaced my copy of the Whirlwind
instruction manual, sigh - a real tresure).

ISTVR there was something about the way Whirlwind did it that made it clear
how it came to be the way it was - IIRC, the last instruction in the
subroutine was normally a 'jump to literal' (i.e. a constant, in the
instruction), and the Whirlwind 'jump to subroutine' stored the return address
in a register; there was a special instruction (normally the first one in any
subroutine) that stored the low-order N bits of that register in the literal
field of the last instruction: i.e. self-modifying code.

The PDP-6 (of which the PDP-10 was a clone) was on the border of that period;
it had both types of subroutine linkage (store the return in the destination,
and jump to dest+1; and also push the return on the stack).

	Noel

[TUHS] Happy birthday, PDP-8!

[Atindra Chaturvedi]

Brings back memories...
Back in early 1981 I worked for a shipping line in Cranford NJ in their IT department. The company had just ordered 4 new super-wide cargo ships that just fit the Panama Canal and the Chief Marine Architect came to the IT department to ask for assistance in programming a PDP-8 to write a load distribution check program so that the ship would not keel over, or break in the middle - when being loaded 12 stack high containers. Had to take into account stress and strain - mathematical algorithms. My boss called me in to talk to him and he asked " if I knew how to determine the area under a curve..." - I knew my engineering math - Simpson's rule and also FORTRAN IV and was immediately drafted. What was needed also was a graphical way of entering the data, and displaying the results optionally graphically on the screen (tty ?). My friend Wayne Rawls knew BASIC - he wrote the front end - passed me the input on a large floppy - my FORTRAN IV program ran and did the stress/strain analysis for the ship - and I passed the output back to him on the floppy that he then displayed on-screen.
A lot of grinding of the floppy drives for the FORTRAN compiler - no spinning hard disks as the PDP-8 would be installed on-board ship - and in those days of A/C computer rooms would be a non-starter.
It all worked well - Wayne took the PDP-8 on a ship to Norfolk to get it checked out and the company used it for many years !

Atindra.


-----Original Message-----
>From: Dave Horsfall <dave at horsfall.org>
>Sent: Mar 21, 2017 5:34 PM
>To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
>Subject: [TUHS] Happy birthday, PDP-8!
>
>OT, but of interest to a few people here :-)
>
>The venerable PDP-8 was introduced in 1965 today (or tomorrow if you're on 
>the wrong side of the date line).  It was the first computer I ever 
>used, back around 1970 (I think I'd just left school and was checking out 
>the local University's computer department, with a view to majoring in 
>Computer Science (which I did)).
>
>-- 
>Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."