The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: dot@dotat.at (Tony Finch)
Subject: [TUHS] Early Unix function calls: expensive?
Date: Mon, 4 Jan 2016 11:35:44 +0000	[thread overview]
Message-ID: <alpine.LSU.2.00.1601041128370.25050@hermes-2.csi.cam.ac.uk> (raw)
In-Reply-To: <a3f91e2b1d49d6cc11b78b419a42a455.squirrel@webmail.yaccman.com>

scj at yaccman.com <scj at yaccman.com> wrote:
>
> As part of the PCC work, I wrote a technical report on how to design a C
> calling sequence, but that was before the VAX.  Early calling sequences
> had both a stack pointer and a frame pointer, but for most machines it
> was possible to get by with just one, so calling sequences got better as
> time went on.  Also, RISC machines with many more registers than the
> PDP-11 also led to more efficient calls by putting some arguments in
> registers.  Later standardizations like varargs were painful on some
> architectures (especially those which had different registers for pointers
> and integers).

I had a look for your technical report online but my searches failed me.
Do you have a link to a copy?

Doesn't alloca() get interesting if you have a stack pointer but no frame
pointer? :-)

http://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/src/libc/sys/alloca.s

Nowadays it's usually implemented as a builtin, and given that the
compiler ought to be able to cope in most cases, but if you alloca() a
variable amount things soon get too difficult...

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Northeast Viking, North Utsire: Southeasterly 5 to 7, occasionally gale 8 in
south. Rough or very rough, occasionally moderate later. Fair. Good.


  reply	other threads:[~2016-01-04 11:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-03 23:35 Warren Toomey
2016-01-03 23:53 ` Tim Bradshaw
2016-01-04  0:01   ` John Cowan
2016-01-04  4:40     ` Armando Stettner
2016-01-04  8:52       ` Tim Bradshaw
2016-01-04 17:29         ` Larry McVoy
2016-01-04 13:50       ` Clem Cole
2016-01-05  2:00       ` Ronald Natalie
2016-01-05 15:13         ` Clem Cole
2016-01-05 16:46           ` John Cowan
2016-01-05 17:33             ` Diomidis Spinellis
2016-01-05 17:42             ` Clem Cole
2016-01-05 17:28           ` Ronald Natalie
2016-01-05 17:43             ` Clem Cole
2016-01-05 17:46               ` Ronald Natalie
2016-01-05 18:03                 ` Warner Losh
2016-01-05 18:24                   ` Ronald Natalie
2016-01-05 20:26                     ` scj
2016-01-05 20:49                     ` John Cowan
2016-01-05 23:24         ` Dave Horsfall
2016-01-05 23:55           ` Ronald Natalie
2016-01-04  0:00 ` John Cowan
2016-01-04  0:42 ` scj
2016-01-04 11:35   ` Tony Finch [this message]
     [not found] <mailman.3.1451865187.15972.tuhs@minnie.tuhs.org>
2016-01-04  1:08 ` Johnny Billquist
2016-01-04  1:29   ` Larry McVoy
2016-01-04  1:31 Noel Chiappa
2016-01-04  2:24 ` scj
2016-01-04  4:24   ` Larry McVoy
2016-01-04  1:59 Norman Wilson
2016-01-04 15:09 ` John Cowan
2016-01-04  2:21 Clem Cole
2016-01-04 12:53 Noel Chiappa

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=alpine.LSU.2.00.1601041128370.25050@hermes-2.csi.cam.ac.uk \
    --to=dot@dotat.at \
    /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).