Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » The Subroutine Call
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
The Subroutine Call [message #86341] Tue, 18 June 2013 15:59 Go to next message
jsavard is currently offline  jsavard
Messages: 53
Registered: June 2013
Karma: 0
Member
I have added the following page to my site:

http://www.quadibloc.com/comp/cp0310.htm

where I discuss one particular type of instruction that changes quite a
bit from one computer architecture to another.

The subroutine call.

I note that many old computers called subroutines the way the PDP-8 did;
others did so the way the IBM 704 did, storing the return address in an
index register.

But I also mention the PDP-11 and the IBM 360, as well as the modern
practice of letting the stack do it.

But while the ICL 1900 followed the IBM 704 more or less, I left that
one out for now.

John Savard
http://www.quadibloc.com/index.html
Re: The Subroutine Call [message #86353 is a reply to message #86341] Tue, 18 June 2013 17:35 Go to previous messageGo to next message
Walter Banks is currently offline  Walter Banks
Messages: 1000
Registered: July 2012
Karma: 0
Senior Member
John Savard wrote:

> I have added the following page to my site:

>

> http://www.quadibloc.com/comp/cp0310.htm

>

> where I discuss one particular type of instruction that changes quite a

> bit from one computer architecture to another.

>

> The subroutine call.

>

> I note that many old computers called subroutines the way the PDP-8 did;

> others did so the way the IBM 704 did, storing the return address in an

> index register.

>

> But I also mention the PDP-11 and the IBM 360, as well as the modern

> practice of letting the stack do it.

>

> But while the ICL 1900 followed the IBM 704 more or less, I left that

> one out for now.

>

> John Savard

> http://www.quadibloc.com/index.html


Thanks for posting that.

In the embedded system world although many processors use a
stack for the return address this is still far from universal. The stack
on many embedded applications is seen as insecure, especially
with automotive applications running in a bad physical and
electrical environment where repeated pushing on the stack
by a run away process can overwrite data information, better
that watchdog timers restart where some of the data is recoverable.

Many of the processors used in these applications have a return
address register that is saved in nested subroutines. This approach
is used by several processors that I have been a part of developing
over the last couple decades.

The other approach used by some embedded processors is to
have a circular limited subroutine return stack of 2,4,or 8 levels.

From a code generation point of view in applications or tools
subroutine call and return really doesn't matter.

w..
Re: The Subroutine Call [message #86362 is a reply to message #86341] Tue, 18 June 2013 18:42 Go to previous messageGo to next message
Bill Findlay is currently offline  Bill Findlay
Messages: 286
Registered: January 2012
Karma: 0
Senior Member
On 18/06/2013 20:59, in article 51c0bb8a.6750546@news.eternal-september.org,
"John Savard" <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote:

> I have added the following page to my site:

>

> http://www.quadibloc.com/comp/cp0310.htm

>

> where I discuss one particular type of instruction that changes quite a

> bit from one computer architecture to another.

>

> The subroutine call.

>

> I note that many old computers called subroutines the way the PDP-8 did;

> others did so the way the IBM 704 did, storing the return address in an

> index register.

>

> But I also mention the PDP-11 and the IBM 360, as well as the modern

> practice of letting the stack do it.


Using a stack of return addresses was invented by Turing and described in
his 1945-46 paper on the ACE. The ACE design is excellently summarised
here:

http://www.cs.auckland.ac.nz/~brian/ACE2012-BEC-RWD.pdf

> But while the ICL 1900 followed the IBM 704 more or less, I left that

> one out for now.


The 1900 mixed-language programming API (supporting PLAN, Algol 60, FORTRAN
and COBOL) requires the use of X1 for the link.

A subroutine with actual parameters a1, a2, ... aN is invoked by, e.g.:

CALL 1 subr
LDN 3 a1
. . .
LDN 3 aN

Within the subroutine, actual parameter N is obtained by the instruction

OBEY (p-1)(1)

I.e., execute the single instruction at [X1] + (p - 1)

This instruction loads X3 with the value/address of actual parameter p.

This nicely supports eager evalaution ("call by value"), lazy evaluation and
normal-order evalution ("call by name") with the same simple mechanism.

Return is effected by:

EXIT 1 N

which returns to the order at [X1} + N

--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;
Re: The Subroutine Call [message #86381 is a reply to message #86362] Tue, 18 June 2013 22:13 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
>> But I also mention the PDP-11 and the IBM 360, as well as the modern

>> practice of letting the stack do it.


The description of the PDP-11 subroutine call somewhat misses the point.

If you do

JSR Rn,subr

the return address is saved in Rn, which allows you to put pointers to
parameters in-line after the JSR instruction and pick them up using

MOV @(Rn)+,Rx

When you're done,

RTS Rn

returns, assuming that the subroutine has advanced Rn over the parameters.

As a special but very common case,

JSR R7,subr

just saves the return address on the stack and jumps, since R7 is the
program counter.

A hack beloved of PDP-11 aficionados was the coroutine call:

JSR R7,@(SP)+

which swapped the PC with the top element on the stack. So if you
had two coroutines CR1 and CR2, you'd do

MOV #CR2,-(SP) ; set start address of CR2
JMP CR1

then each JSR R7,@(SP)+ would switch between the coroutines. When done:

TST (SP)+

to get rid of the last saved coroutine PC.


You might also want to mention the PDP-6/10/20 which provided all
known forms of subroutine call, save in a register, save in memory,
save in register with prior register in memory, and save on stack.

--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
Re: The Subroutine Call [message #87303 is a reply to message #86353] Wed, 19 June 2013 10:28 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <51C0D2AC.29DC9C8@bytecraft.com>, on 06/18/2013
at 05:35 PM, Walter Banks <walter@bytecraft.com> said:

> The other approach used by some embedded processors is to have a

> circular limited subroutine return stack of 2,4,or 8 levels.


Sounds lioke the old Burroughs D825.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #87304 is a reply to message #86381] Wed, 19 June 2013 10:48 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <kpr447$1eq8$1@leila.iecc.com>, on 06/19/2013
at 02:13 AM, John Levine <johnl@iecc.com> said:

> You might also want to mention the PDP-6/10/20


DEC had stopped using the PDP designation for new products by the time
the 20 came out. The new nomenclature was DECsystem-10 and
DECSYSTEM-20.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #87337 is a reply to message #86353] Wed, 19 June 2013 14:51 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com
(Walter Banks) writes:

> In the embedded system world although many processors use a

> stack for the return address this is still far from universal.

> The stack on many embedded applications is seen as insecure,

> especially with automotive applications running in a bad physical

> and electrical environment where repeated pushing on the stack

> by a run away process can overwrite data information, better

> that watchdog timers restart where some of the data is recoverable.


Did any processor ever implement a stack limit register? I always
thought it would be nice if the hardware could trap a stack overflow.

--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Re: The Subroutine Call [message #87353 is a reply to message #87337] Wed, 19 June 2013 15:26 Go to previous messageGo to next message
Walter Banks is currently offline  Walter Banks
Messages: 1000
Registered: July 2012
Karma: 0
Senior Member
Charlie Gibbs wrote:

> In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com

> (Walter Banks) writes:

>

>> In the embedded system world although many processors use a

>> stack for the return address this is still far from universal.

>> The stack on many embedded applications is seen as insecure,

>> especially with automotive applications running in a bad physical

>> and electrical environment where repeated pushing on the stack

>> by a run away process can overwrite data information, better

>> that watchdog timers restart where some of the data is recoverable.

>

> Did any processor ever implement a stack limit register? I always

> thought it would be nice if the hardware could trap a stack overflow.


Some of the embedded processors have stack overflow detection,
for example SPLIM (Stack Pointer Limit) in the Microchip PIC24.
It causes a trap when the stack limit is crossed.

w..
Re: The Subroutine Call [message #87355 is a reply to message #87337] Wed, 19 June 2013 15:32 Go to previous messageGo to next message
Rich Alderson is currently offline  Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
Senior Member
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:

> Did any processor ever implement a stack limit register? I always

> thought it would be nice if the hardware could trap a stack overflow.


Hmm. On the PDP-10, stack overflow causes a trap. Any AC ("general purpose
register") other than 0 can be used as a stack pointer. An in-section pointer
is initialized to -<stack depth>,,<top of stack>, e.g. MOVE 17,[-100,,PDL].
Any PUSH or PUSHJ (subroutine call) that takes the pointer positive causes a
stack overflow trap; any POP or POPJ (subroutine return) causes an underflow
trap.

That what you're looking for?

--
Rich Alderson news@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
Re: The Subroutine Call [message #87357 is a reply to message #87304] Wed, 19 June 2013 15:38 Go to previous messageGo to next message
Rich Alderson is currently offline  Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
Senior Member
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:

> In <kpr447$1eq8$1@leila.iecc.com>, on 06/19/2013

> at 02:13 AM, John Levine <johnl@iecc.com> said:


>> You might also want to mention the PDP-6/10/20


> DEC had stopped using the PDP designation for new products by the time

> the 20 came out. The new nomenclature was DECsystem-10 and

> DECSYSTEM-20.


Not quite. The PDP-12 (12 bit), PDP-15 (18 bit) and PDP-14 and PDP-16 (serial
devices) post-date the DECsystem-10 (KI10 processor).

I used to argue that there was never a PDP-20, but I have been shown at least
one document from Digital which used that nomenclature for the DECSYSTEM-20.
(Urk.) I'm sorry that I do not remember which one it is.

--
Rich Alderson news@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
Re: The Subroutine Call [message #87358 is a reply to message #87353] Wed, 19 June 2013 15:42 Go to previous messageGo to next message
Walter Banks is currently offline  Walter Banks
Messages: 1000
Registered: July 2012
Karma: 0
Senior Member
Walter Banks wrote:

> Charlie Gibbs wrote:

>

>> In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com

>> (Walter Banks) writes:

>>

>>> In the embedded system world although many processors use a

>>> stack for the return address this is still far from universal.

>>> The stack on many embedded applications is seen as insecure,

>>> especially with automotive applications running in a bad physical

>>> and electrical environment where repeated pushing on the stack

>>> by a run away process can overwrite data information, better

>>> that watchdog timers restart where some of the data is recoverable.

>>

>> Did any processor ever implement a stack limit register? I always

>> thought it would be nice if the hardware could trap a stack overflow.

>

> Some of the embedded processors have stack overflow detection,

> for example SPLIM (Stack Pointer Limit) in the Microchip PIC24.

> It causes a trap when the stack limit is crossed.

>

> w..


The SPLIM is a writable register. Some of the processors have
registers like SPLIM that can only be written within the first few
cycles after reset so that "bad" software cannot change them.
(Some of Nationals COP8 series are an example of this)

w..
Re: The Subroutine Call [message #87361 is a reply to message #87337] Wed, 19 June 2013 16:14 Go to previous messageGo to next message
Andrew Swallow is currently offline  Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
Senior Member
On 19/06/2013 19:51, Charlie Gibbs wrote:
> In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com

> (Walter Banks) writes:

>

>> In the embedded system world although many processors use a

>> stack for the return address this is still far from universal.

>> The stack on many embedded applications is seen as insecure,

>> especially with automotive applications running in a bad physical

>> and electrical environment where repeated pushing on the stack

>> by a run away process can overwrite data information, better

>> that watchdog timers restart where some of the data is recoverable.

>

> Did any processor ever implement a stack limit register? I always

> thought it would be nice if the hardware could trap a stack overflow.

>


The Plessey S250 could. It could also trap running off the end of a
subroutine. Unfortunately all this error checking made it very slow.

Andrew Swallow
Re: The Subroutine Call [message #87365 is a reply to message #86341] Wed, 19 June 2013 16:41 Go to previous messageGo to next message
Charles Richmond is currently offline  Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
Senior Member
"John Savard" <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote in message
news:51c0bb8a.6750546@news.eternal-september.org...
> I have added the following page to my site:

>

> http://www.quadibloc.com/comp/cp0310.htm

>

> where I discuss one particular type of instruction that changes quite a

> bit from one computer architecture to another.

>

> The subroutine call.

>


You must mean the "Wheeler jump"...

--

numerist at aquaporin4 dot com
Re: The Subroutine Call [message #87646 is a reply to message #87337] Wed, 19 June 2013 19:56 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
On 6/19/2013 2:51 PM, Charlie Gibbs wrote:
> In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com

> (Walter Banks) writes:

>

>> In the embedded system world although many processors use a

>> stack for the return address this is still far from universal.

>> The stack on many embedded applications is seen as insecure,

>> especially with automotive applications running in a bad physical

>> and electrical environment where repeated pushing on the stack

>> by a run away process can overwrite data information, better

>> that watchdog timers restart where some of the data is recoverable.

>

> Did any processor ever implement a stack limit register? I always

> thought it would be nice if the hardware could trap a stack overflow.

>


Any of the x86s. OS/2, and presumably windoze, but not (AFAIK) Linux
creates a stack segment entry which enforces the limit. OS/2 uses a
"guard page" that raises a special exception if the program tries to
write to it. Te user has the option of trapping the exception and
growing the stack if possible.

--
Pete
Re: The Subroutine Call [message #87734 is a reply to message #87361] Wed, 19 June 2013 19:30 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <Md-dnTwy3oqQjF_MnZ2dnUVZ7oOdnZ2d@bt.com>, on 06/19/2013
at 09:14 PM, Andrew Swallow <am.swallow@btinternet.com> said:

> The Plessey S250 could. It could also trap running off the end of

> a subroutine. Unfortunately all this error checking made it very

> slow.


Was it the error checking that made it slow or the capability-based
architecture?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #87738 is a reply to message #87337] Wed, 19 June 2013 19:09 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <933.953T2305T6515778@kltpzyxm.invalid>, on 06/19/2013
at 10:51 AM, "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> said:

> Did any processor ever implement a stack limit register?


Sure, starting with the B5000.

Unfortunately, once "stack" became a buzz word, a lot of vendors had
half-assed stack designs. But even on a machine without stack limits
you may be able to get the same effect with guard pages.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #87745 is a reply to message #87734] Wed, 19 June 2013 23:32 Go to previous messageGo to next message
Andrew Swallow is currently offline  Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
Senior Member
On 20/06/2013 00:30, Shmuel (Seymour J.) Metz wrote:
> In <Md-dnTwy3oqQjF_MnZ2dnUVZ7oOdnZ2d@bt.com>, on 06/19/2013

> at 09:14 PM, Andrew Swallow <am.swallow@btinternet.com> said:

>

>> The Plessey S250 could. It could also trap running off the end of

>> a subroutine. Unfortunately all this error checking made it very

>> slow.

>

> Was it the error checking that made it slow or the capability-based

> architecture?

>


Both. The capabilities did the error checking. Every read, write and
instruction fetch had to perform a range check. Loading the capability
registers was also slow.

Andrew Swallow
Re: The Subroutine Call [message #87757 is a reply to message #86341] Thu, 20 June 2013 02:31 Go to previous messageGo to next message
James Dow Allen is currently offline  James Dow Allen
Messages: 33
Registered: January 2013
Karma: 0
Member
Don't forget the CDC 6600 et al with an RJ instruction that saved the
return address by writing it, inside a Jump instruction, into the core
memory location immediately prior to the called subroutine.

It does seem odd that the designer(s) were unaware of the convenience of
*recursive* calls.

James Dow Allen
Re: The Subroutine Call [message #87766 is a reply to message #87757] Thu, 20 June 2013 06:26 Go to previous messageGo to next message
Walter Banks is currently offline  Walter Banks
Messages: 1000
Registered: July 2012
Karma: 0
Senior Member
James Dow Allen wrote:

> Don't forget the CDC 6600 et al with an RJ instruction that saved the

> return address by writing it, inside a Jump instruction, into the core

> memory location immediately prior to the called subroutine.

>

> It does seem odd that the designer(s) were unaware of the convenience of

> *recursive* calls.


This was the same as the PDP-8. I think that it was assumed that
most cases recursion could be implemented or re-written to be tail
end recursion. Minimizing implementation gate count had to be a factor.

w..
Re: The Subroutine Call [message #87967 is a reply to message #87745] Thu, 20 June 2013 08:15 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
On 6/19/2013 11:32 PM, Andrew Swallow wrote:
> On 20/06/2013 00:30, Shmuel (Seymour J.) Metz wrote:

>> In <Md-dnTwy3oqQjF_MnZ2dnUVZ7oOdnZ2d@bt.com>, on 06/19/2013

>> at 09:14 PM, Andrew Swallow <am.swallow@btinternet.com> said:

>>

>>> The Plessey S250 could. It could also trap running off the end of

>>> a subroutine. Unfortunately all this error checking made it very

>>> slow.

>>

>> Was it the error checking that made it slow or the capability-based

>> architecture?

>>

>

> Both. The capabilities did the error checking. Every read, write and

> instruction fetch had to perform a range check. Loading the capability

> registers was also slow.

>



This is always used as a knock on capability-based systems, but if the
industry put half as much effort into optimizing such things in hardware
as they have into other areas, the speed differential probably wouldn't
be significant.

--
Pete
Re: The Subroutine Call [message #87969 is a reply to message #87757] Thu, 20 June 2013 08:08 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <XnsA1E58990FE1BEjamesdowallen@178.63.61.175>, on 06/20/2013
at 06:31 AM, James Dow Allen <gmail@jamesdowallen.nospam> said:

> Don't forget the CDC 6600 et al with an RJ instruction that saved the

> return address by writing it, inside a Jump instruction, into the

> core memory location immediately prior to the called subroutine.


That falls into the category of "the way the PDP-8 did"[1]. although
the PDP-8 came later. Return Jump and its ilk were bog common in the
1960's; I believe that they originated in the 1950's. Certainly the
CDC 924 and 1604 had RJ.

> It does seem odd that the designer(s) were unaware of the

> convenience of *recursive* calls.


Seymour Cray was a hardware guy who was obsessed with speed and wasn't
much concerned either with error checking or with software. A genius,
but one with tunnel vision.


[1] Message-ID: <51c0bb8a.6750546@news.eternal-september.org>

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #87973 is a reply to message #87967] Thu, 20 June 2013 09:20 Go to previous messageGo to next message
jsavard is currently offline  jsavard
Messages: 53
Registered: June 2013
Karma: 0
Member
On Thu, 20 Jun 2013 08:15:18 -0400, Peter Flass <Peter_Flass@Yahoo.com>
wrote, in part:

> This is always used as a knock on capability-based systems, but if the

> industry put half as much effort into optimizing such things in hardware

> as they have into other areas, the speed differential probably wouldn't

> be significant.


It's true enough that if you have a pipelined design, then the fact that
doing something extra instead of doing nothing isn't likely to add less
than one cycle to instructions could still be insignificant - as that
would now only add to latency.

The real problem is that it would still add transistors - and, if the
_benefits_ of an architecture like that of the Burroughs machines aren't
considered worth paying for, then it's a non-starter.

It doesn't help that the Burroughs machines, the only fully-realized
model that's well known of this type of architecture, omitted hardware
based security, depending on the compilers respecting security. That's
not feasible for computers connecting to the Internet.

John Savard
http://www.quadibloc.com/index.html
Re: The Subroutine Call [message #87980 is a reply to message #87969] Thu, 20 June 2013 09:21 Go to previous messageGo to next message
Walter Bushell is currently offline  Walter Bushell
Messages: 1834
Registered: December 2011
Karma: 0
Senior Member
In article <51c2f0b1$38$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
wrote:

> Seymour Cray was a hardware guy who was obsessed with speed and wasn't

> much concerned either with error checking or with software. A genius,

> but one with tunnel vision.

>


Frequently the case. A human can have only so much grey matter and if
a lot is dedicated in one area the others must suffer.

--
Gambling with Other People's Money is the meth of the fiscal industry.
me -- in the spirit of Karl and Groucho Marx
Re: The Subroutine Call [message #87982 is a reply to message #87357] Thu, 20 June 2013 09:22 Go to previous messageGo to next message
jmfbahciv is currently offline  jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
Senior Member
Rich Alderson wrote:
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:

>

>> In <kpr447$1eq8$1@leila.iecc.com>, on 06/19/2013

>> at 02:13 AM, John Levine <johnl@iecc.com> said:

>

>>> You might also want to mention the PDP-6/10/20

>

>> DEC had stopped using the PDP designation for new products by the time

>> the 20 came out. The new nomenclature was DECsystem-10 and

>> DECSYSTEM-20.

>

> Not quite. The PDP-12 (12 bit), PDP-15 (18 bit) and PDP-14 and PDP-16

(serial
> devices) post-date the DECsystem-10 (KI10 processor).

>

> I used to argue that there was never a PDP-20, but I have been shown at

least
> one document from Digital which used that nomenclature for the DECSYSTEM-20.

> (Urk.) I'm sorry that I do not remember which one it is.

>


That PDP-20 nomenclature was squelched ASAP. The DECsystem and DECSYSTEM
terms were used to refer to an entire system which included the hardware
and the software.

If you bought a second or third CPU, you did not buy another DECsystem-10;
you bought another PDP-10.

/BAH
Re: The Subroutine Call [message #87984 is a reply to message #87337] Thu, 20 June 2013 09:50 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:

> Did any processor ever implement a stack limit register? I always

> thought it would be nice if the hardware could trap a stack overflow.


The Burroughs medium systems Omega architecture added stack overflow
checking. The ASP (Adjust Stack Pointer) would ensure that the stack
had at least 500 digits (enough for a fault frame) beyond the current
stack pointer, and if not, would fault to the MCP which would then
extend the memory area containing the stack.

http://vseries.lurndal.org/doku.php?id=instructions:asp
Re: The Subroutine Call [message #87985 is a reply to message #87646] Thu, 20 June 2013 09:55 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Peter Flass <Peter_Flass@Yahoo.com> writes:
> On 6/19/2013 2:51 PM, Charlie Gibbs wrote:

>> In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com

>> (Walter Banks) writes:

>>

>>> In the embedded system world although many processors use a

>>> stack for the return address this is still far from universal.

>>> The stack on many embedded applications is seen as insecure,

>>> especially with automotive applications running in a bad physical

>>> and electrical environment where repeated pushing on the stack

>>> by a run away process can overwrite data information, better

>>> that watchdog timers restart where some of the data is recoverable.

>>

>> Did any processor ever implement a stack limit register? I always

>> thought it would be nice if the hardware could trap a stack overflow.

>>

>

> Any of the x86s. OS/2, and presumably windoze, but not (AFAIK) Linux

> creates a stack segment entry which enforces the limit.


x86 stack segment isn't used by any 32-bit or 64-bit operating system
on x86 machines. Too inefficient. Linux will create a hole in the
virtual address space at the 'top' of the stack such that accesses
beyond the extent of the stack (up to a point) will cause a page not
present fault to prevent short overruns. A large overrun may extended
the stack into a different memory area.

> OS/2 uses a

> "guard page" that raises a special exception if the program tries to

> write to it. Te user has the option of trapping the exception and

> growing the stack if possible.


scott
Re: The Subroutine Call [message #87987 is a reply to message #87967] Thu, 20 June 2013 10:13 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
Senior Member
Peter Flass <Peter_Flass@Yahoo.com> writes:
> This is always used as a knock on capability-based systems, but if the

> industry put half as much effort into optimizing such things in

> hardware as they have into other areas, the speed differential

> probably wouldn't be significant.


GNOSIS was capability based system for ibm 370, by one of the virtual
machine based commercial online service companies. part of it was
designed to be platform for 3rd party offerings ... a dbms or
application could be offered and gnosis would not only accurately
account for all resources by users ... for charging purposes ... but
also accurately account by specific resource to enable remittance to 3rd
parties (calls not only checked domain crossing and checking
capabilities but had significant pathlength for resource accounting)

In the 80s, M/D bought the company and spun off several units (its telco
front-end sold to BT) ... and gnosis is spun off into KeyKOS (I'm
brought in to audit gnosis as part of the spin-off). For KeyKOS all the
accounting pathlength is stripped away and they have benchmarks that
show capability based applications beating throughput of TPF (besides
edfficient pathlength, they claim that higher-level abstractions
allowing optimization that can't be done in the extremely low-level TPF
environment).

tymshare
http://en.wikipedia.org/wiki/Tymshare

GNOSIS
http://en.wikipedia.org/wiki/GNOSIS
KeyKOS
http://en.wikipedia.org/wiki/KeyKOS
documents and references
http://en.wikipedia.org/wiki/GNOSIS

and spawns

EROS
http://en.wikipedia.org/wiki/Extremely_Reliable_Operating_Sy stem
CapROS
http://en.wikipedia.org/wiki/CapROS
Coyotos
http://en.wikipedia.org/wiki/Coyotos

IBM's high-performance transaction processing facility, originated for
the airline industry as ACP ... but rebranded 1979 as TPF when financial
and other reservation industries were using it
http://en.wikipedia.org/wiki/Transaction_Processing_Facility

recent posts mentioning GNOSIS
http://www.garlic.com/~lynn/2013c.html#80 Still not convinced about the superiority of mainframe security vs distributed?
http://www.garlic.com/~lynn/2013d.html#55 Arthur C. Clarke Predicts the Internet, 1974
http://www.garlic.com/~lynn/2013f.html#33 Delay between idea and implementation

past posts mentioning virtual machine based online services
http://www.garlic.com/~lynn/submain.html#timeshare

--
virtualization experience starting Jan1968, online at home since Mar1970
Re: The Subroutine Call [message #88055 is a reply to message #87969] Thu, 20 June 2013 11:37 Go to previous messageGo to next message
jsavard is currently offline  jsavard
Messages: 53
Registered: June 2013
Karma: 0
Member
On Thu, 20 Jun 2013 08:08:17 -0400, Shmuel (Seymour J.) Metz
<spamtrap@library.lspace.org.invalid> wrote, in part:
> In <XnsA1E58990FE1BEjamesdowallen@178.63.61.175>, on 06/20/2013

> at 06:31 AM, James Dow Allen <gmail@jamesdowallen.nospam> said:


>> It does seem odd that the designer(s) were unaware of the

>> convenience of *recursive* calls.

>

> Seymour Cray was a hardware guy who was obsessed with speed and wasn't

> much concerned either with error checking or with software. A genius,

> but one with tunnel vision.


It might be noted that some machines (the IBM 701, the RCA 110) came
without any kind of subroutine call instruction at all. But one could
still call subroutines:

LDA K_RET just get a constant containing the return address
STA RETURN and store it where the subroutine needs it
JMP SUBR then just jump
RET ...


K_RET DC RET


SUBR ...

JMP I RETURN

RETURN DS 1

and so one can do a subroutine call "by hand" and make up for
deficiencies in the normal subroutine call instruction when required.

Seymour Cray was naturally concerned with his customers, who used
FORTRAN, not ALGOL, and who typically didn't use fancy techniques like
recursion when attempting to crunch numbers as efficiently as possible.
It is not to be condemned that he avoided worrying about, say,
implementing LISP, because his machines were designed to promote the
coding style that would show they were delivering what they promised:
making every CPU cycle count for people doing bleeding-edge
supercomputing.

John Savard
http://www.quadibloc.com/index.html
Re: The Subroutine Call [message #88057 is a reply to message #87757] Thu, 20 June 2013 11:56 Go to previous messageGo to next message
Joe Pfeiffer is currently offline  Joe Pfeiffer
Messages: 764
Registered: January 2012
Karma: 0
Senior Member
James Dow Allen <gmail@jamesdowallen.nospam> writes:

> Don't forget the CDC 6600 et al with an RJ instruction that saved the

> return address by writing it, inside a Jump instruction, into the core

> memory location immediately prior to the called subroutine.

>

> It does seem odd that the designer(s) were unaware of the convenience of

> *recursive* calls.


It was designed very specifically for heavy-duty number-crunching in
FORTRAN. No recursion there!
Re: The Subroutine Call [message #88062 is a reply to message #87973] Thu, 20 June 2013 12:27 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <51c3003d.1356718@news.eternal-september.org>, on 06/20/2013
at 01:20 PM, jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) said:

> It doesn't help that the Burroughs machines, the only fully-realized

> model that's well known of this type of architecture, omitted

> hardware based security, depending on the compilers respecting

> security.


They cleaned a lot of that up on the B6500, although there were still
some issues. Was it still true on the B6900 and Unisys versions?

What about the S/38?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #88065 is a reply to message #87969] Thu, 20 June 2013 13:20 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
>> It does seem odd that the designer(s) were unaware of the

>> convenience of *recursive* calls.


I expect they were, but they were also aware of the cost of a stack
pointer register and associated hardware to increment and decrement
it, back in the days when each flip-flop cost real money. Saving the
return address at the beginning of the subroutine was easy, and also
made it easy to fetch arguments using indirect addressing.

You could do a lot of useful programming with no recursion and if you
really wanted recursion, you could program your own stack and copy the
return addresses there.

--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
Re: The Subroutine Call [message #88190 is a reply to message #87967] Thu, 20 June 2013 15:38 Go to previous messageGo to next message
Andrew Swallow is currently offline  Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
Senior Member
On 20/06/2013 13:15, Peter Flass wrote:
> On 6/19/2013 11:32 PM, Andrew Swallow wrote:

>> On 20/06/2013 00:30, Shmuel (Seymour J.) Metz wrote:

>>> In <Md-dnTwy3oqQjF_MnZ2dnUVZ7oOdnZ2d@bt.com>, on 06/19/2013

>>> at 09:14 PM, Andrew Swallow <am.swallow@btinternet.com> said:

>>>

>>>> The Plessey S250 could. It could also trap running off the end of

>>>> a subroutine. Unfortunately all this error checking made it very

>>>> slow.

>>>

>>> Was it the error checking that made it slow or the capability-based

>>> architecture?

>>>

>>

>> Both. The capabilities did the error checking. Every read, write and

>> instruction fetch had to perform a range check. Loading the capability

>> registers was also slow.

>>

>

>

> This is always used as a knock on capability-based systems, but if the

> industry put half as much effort into optimizing such things in hardware

> as they have into other areas, the speed differential probably wouldn't

> be significant.

>


Yes, the capability hardware needs its own adder to do the range
checking in less than a single clock cycle. Virtual memory also needs
to be attached to the capability system. Applications software needs
the ability to create and destroy capabilities - not just the compilers.

Andrew Swallow
Re: The Subroutine Call [message #88195 is a reply to message #87985] Thu, 20 June 2013 16:26 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
On 6/20/2013 9:55 AM, Scott Lurndal wrote:
> Peter Flass <Peter_Flass@Yahoo.com> writes:

>> On 6/19/2013 2:51 PM, Charlie Gibbs wrote:

>>> In article <51C0D2AC.29DC9C8@bytecraft.com>, walter@bytecraft.com

>>> (Walter Banks) writes:

>>>

>>>> In the embedded system world although many processors use a

>>>> stack for the return address this is still far from universal.

>>>> The stack on many embedded applications is seen as insecure,

>>>> especially with automotive applications running in a bad physical

>>>> and electrical environment where repeated pushing on the stack

>>>> by a run away process can overwrite data information, better

>>>> that watchdog timers restart where some of the data is recoverable.

>>>

>>> Did any processor ever implement a stack limit register? I always

>>> thought it would be nice if the hardware could trap a stack overflow.

>>>

>>

>> Any of the x86s. OS/2, and presumably windoze, but not (AFAIK) Linux

>> creates a stack segment entry which enforces the limit.

>

> x86 stack segment isn't used by any 32-bit or 64-bit operating system

> on x86 machines.


Any *other* operating system maybe.

--
Pete
Re: The Subroutine Call [message #88315 is a reply to message #88057] Thu, 20 June 2013 12:37 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <1bwqpolqsp.fsf@snowball.wb.pfeifferfamily.net>, on 06/20/2013
at 09:56 AM, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> said:

> It was designed very specifically for heavy-duty number-crunching in

> FORTRAN. No recursion there!


Yet CDC provided an Algol-60 compiler.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #88669 is a reply to message #88195] Fri, 21 June 2013 09:45 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Peter Flass <Peter_Flass@Yahoo.com> writes:
> On 6/20/2013 9:55 AM, Scott Lurndal wrote:

>> Peter Flass <Peter_Flass@Yahoo.com> writes:


>>> Any of the x86s. OS/2, and presumably windoze, but not (AFAIK) Linux

>>> creates a stack segment entry which enforces the limit.

>>

>> x86 stack segment isn't used by any 32-bit or 64-bit operating system

>> on x86 machines.

>

> Any *other* operating system maybe.


If you mean other than OS/2, which hasn't been relevent for over 15 years,
it is indeed the case that the X86 hardware stack segment is _not_ used by
any current generation operating system (including vmware) for intel architecture
boxen. Most of that was dropped in AMD64, so it's not even available to 64-bit
OS's.
Re: The Subroutine Call [message #88672 is a reply to message #88315] Fri, 21 June 2013 10:47 Go to previous messageGo to next message
Joe Pfeiffer is currently offline  Joe Pfeiffer
Messages: 764
Registered: January 2012
Karma: 0
Senior Member
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:

> In <1bwqpolqsp.fsf@snowball.wb.pfeifferfamily.net>, on 06/20/2013

> at 09:56 AM, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> said:

>

>> It was designed very specifically for heavy-duty number-crunching in

>> FORTRAN. No recursion there!

>

> Yet CDC provided an Algol-60 compiler.


Was that an actual CDC product? It sure wasn't a major concern.
Re: The Subroutine Call [message #88706 is a reply to message #88057] Fri, 21 June 2013 14:10 Go to previous messageGo to next message
Charles Richmond is currently offline  Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
Senior Member
"Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message
news:1bwqpolqsp.fsf@snowball.wb.pfeifferfamily.net...
> James Dow Allen <gmail@jamesdowallen.nospam> writes:

>

>> Don't forget the CDC 6600 et al with an RJ instruction that saved the

>> return address by writing it, inside a Jump instruction, into the core

>> memory location immediately prior to the called subroutine.

>>

>> It does seem odd that the designer(s) were unaware of the convenience of

>> *recursive* calls.

>

> It was designed very specifically for heavy-duty number-crunching in

> FORTRAN. No recursion there!


But now... *today*... FORTRAN can handle recursion quite nicely, thank you
very much!!!

--

numerist at aquaporin4 dot com
Re: The Subroutine Call [message #88707 is a reply to message #88706] Fri, 21 June 2013 15:08 Go to previous messageGo to next message
Walter Bushell is currently offline  Walter Bushell
Messages: 1834
Registered: December 2011
Karma: 0
Senior Member
In article <kq24lf$q49$1@dont-email.me>,
"Charles Richmond" <numerist@aquaporin4.com> wrote:

> "Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message

> news:1bwqpolqsp.fsf@snowball.wb.pfeifferfamily.net...

>> James Dow Allen <gmail@jamesdowallen.nospam> writes:

>>

>>> Don't forget the CDC 6600 et al with an RJ instruction that saved the

>>> return address by writing it, inside a Jump instruction, into the core

>>> memory location immediately prior to the called subroutine.

>>>

>>> It does seem odd that the designer(s) were unaware of the convenience of

>>> *recursive* calls.

>>

>> It was designed very specifically for heavy-duty number-crunching in

>> FORTRAN. No recursion there!

>

> But now... *today*... FORTRAN can handle recursion quite nicely, thank you

> very much!!!

>

> --

>

> numerist at aquaporin4 dot com


But is there an Objective Fortran? Or Fortran+1?

--
Gambling with Other People's Money is the meth of the fiscal industry.
me -- in the spirit of Karl and Groucho Marx
Re: The Subroutine Call [message #88715 is a reply to message #88055] Thu, 20 June 2013 12:36 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In <51c31fb9.9417468@news.eternal-september.org>, on 06/20/2013
at 03:37 PM, jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) said:

> It is not to be condemned that he avoided worrying about, say,

> implementing LISP, because his machines were designed to promote the

> coding style that would show they were delivering what they promised:

> making every CPU cycle count for people doing bleeding-edge

> supercomputing.


However, his decision to not "waste" resources on memory parity was
unfortunate.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: The Subroutine Call [message #88717 is a reply to message #88715] Fri, 21 June 2013 16:01 Go to previous messageGo to previous message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> In <51c31fb9.9417468@news.eternal-september.org>, on 06/20/2013

> at 03:37 PM, jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) said:

>

>> It is not to be condemned that he avoided worrying about, say,

>> implementing LISP, because his machines were designed to promote the

>> coding style that would show they were delivering what they promised:

>> making every CPU cycle count for people doing bleeding-edge

>> supercomputing.

>

> However, his decision to not "waste" resources on memory parity was

> unfortunate.

>


"Parity is for Farmers".
Pages (4): [1  2  3  4    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Computerized weather forecasting--then and now?
Next Topic: AT&T's Newly Patented Self-Destructing Emails (via Forbes Tech)
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 10:22:25 EDT 2024

Total time taken to generate the page: 0.06755 seconds