The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: grog@lemis.com (Greg 'groggy' Lehey)
Subject: [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)
Date: Wed, 6 Jan 2016 10:04:40 +1100	[thread overview]
Message-ID: <20160105230440.GA85978@eureka.lemis.com> (raw)
In-Reply-To: <568C2923.3040204@update.uu.se>

On Tuesday,  5 January 2016 at 21:35:47 +0100, Johnny Billquist wrote:
> On 2016-01-05 18:43, Ronald Natalie<ron at ronnatalie.com> wrote:
>>
>> Just never figured out how to make good use of the MARK instruction on the PDP-11.
>
> Not surprising. As others noted, few ever did. And apparently none
> responding actually do either.
>
> It *is* a stupid instruction in many ways. And it's not for multiple
> returns either.
>
> It's an odd way of handling stack cleanup without a frame pointer.

Thanks for the (omitted) explanation.  At first sight, the instruction
almost seems to make sense for functions with a variable number of
parameters, but of course there are simpler ways to do it.

I wonder if this is a case of "it sounded like a good idea at the
time" (when the instruction set was being designed), and it took a
while for people to realize that it wasn't of any use.

I recall a similar issue with the Siemens 306, their first stack-based
machine, round about 1975.  They had function call and return
instructions which manipulated the stack pointer, but it seemed that
nobody used them: they didn't work.  From memory, the call instruction
incremented the stack pointer and stored PC.  The return call
instruction decemented the stack pointer and loaded PC--from the wrong
location.

I never used the 306 myself, but I often wondered if they modified one
of the instructions to DTRT.

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


  reply	other threads:[~2016-01-05 23:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.7.1452015811.15972.tuhs@minnie.tuhs.org>
2016-01-05 20:35 ` Johnny Billquist
2016-01-05 23:04   ` Greg 'groggy' Lehey [this message]
2016-01-05 23:20     ` [TUHS] PDP-11 MARK Johnny Billquist
2016-01-06  0:54       ` Ronald Natalie
     [not found] <mailman.11.1452041647.15972.tuhs@minnie.tuhs.org>
2016-01-06 11:55 ` [TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?) Johnny Billquist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160105230440.GA85978@eureka.lemis.com \
    --to=grog@lemis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).