The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: norman@oclsc.org (Norman Wilson)
Subject: [TUHS] Early Unix function calls: expensive?
Date: Sun,  3 Jan 2016 20:59:06 -0500 (EST)	[thread overview]
Message-ID: <20160104015906.4BF9843F88@lignose.oclsc.org> (raw)

As late as 1990, every UNIX I knew of still used the
expensive calls/ret instructions for subroutine calls.
I vaguely remember a consensus (and I certainly shared
the feeling) that in hindsight it would have been better
to use jsb/rsb, but changing everything would have been
so much work that nobody wanted to do it.

1990 was already past peak VAX in the UNIX world, so
I can't imagine anyone bothering to make such a change
to an existing system after then.  Especially a system
that already had many existing installations who would
have to deal with the resulting compatibility problem.

During the latter part of the 1990s, I was actively
supporting a private UNIX system just for myself on
a few MicroVAXes at home.  One of the things I did
was to write a VAX code generator for the then-current
version of lcc (the one around which the book was
written), so as to have an ISO-compatible compiler
and convert all of /usr/src (not so big even in those
days) to ISO.  It was an interesting exercise and I
learned a lot, but even then, I wasn't brave enough to
adopt an incompatible subroutine-calling convention.

Another big time waste in the original VAX UNIX was
the system-call interface: arguments were left on the
stack (where they had been put before calling the
syscall stub routine in libc); the kernel then had
to do a full-fledged copyin to get them.  It occurred
to me more than once to change the convention and have
the syscall stubs copy the arguments into registers
before executing the chmk (syscall) instruction.
That instruction didn't touch the registers; the
kernel saved them early in the chmk trap routine,
in its own address space, so no copying or access
checking would have been required to fetch their
call-time contents.

That would still have been a messy change to make,
because I'd have to be sure every program had been
relinked with the new-style libc before changing the
kernel.  (This was a system without shared libraries.)
But on a personal system it would have been doable.
I never did.

It's possible that current UNIX-descended/cloned systems
that have VAX ports, like Linux or Open/Free/NetBSD,
have had a chance to start over and do better on
subroutine calls and system calls.  Does anyone know?

Norman Wilson
Toronto ON


             reply	other threads:[~2016-01-04  1:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04  1:59 Norman Wilson [this message]
2016-01-04 15:09 ` John Cowan
  -- strict thread matches above, loose matches on Subject: below --
2016-01-04 12:53 Noel Chiappa
2016-01-04  2:21 Clem Cole
2016-01-04  1:31 Noel Chiappa
2016-01-04  2:24 ` scj
2016-01-04  4:24   ` Larry McVoy
     [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-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

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=20160104015906.4BF9843F88@lignose.oclsc.org \
    --to=norman@oclsc.org \
    /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).