Re: "standard" C calling convention? (Nick Maclaren)
24 Feb 2003 13:43:10 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: "standard" C calling convention? (Dennis Ritchie) (2003-02-21)
Re: "standard" C calling convention? (Christian Bau) (2003-02-21)
Re: "standard" C calling convention? (Mike Ludwig) (2003-02-21)
Re: "standard" C calling convention? (Sander Vesik) (2003-02-21)
Re: "standard" C calling convention? (Andrew) (2003-02-21)
Re: "standard" C calling convention? (2003-02-24)
Re: "standard" C calling convention? (2003-02-24)
Re: "standard" C calling convention? (Glen Herrmannsfeldt) (2003-02-24)
Re: "standard" C calling convention? (Marco van de Voort) (2003-02-24)
Re: "standard" C calling convention? (2003-03-09)
Re: "standard" C calling convention? (Mike Ludwig) (2003-03-09)
Re: "standard" C calling convention? (2003-03-14)
| List of all articles for this month |

From: (Nick Maclaren)
Newsgroups: comp.compilers
Date: 24 Feb 2003 13:43:10 -0500
Organization: University of Cambridge, England
References: 03-02-072 03-02-089 03-02-090
Keywords: C, history
Posted-Date: 24 Feb 2003 13:43:09 EST

"Dennis Ritchie" <> writes:
|> A couple of weeks ago I scanned and OCRed a tech report
|> by Steve Johnson and me on desiderata for a C calling
|> sequence that we wrote in 1981. It's pre-ANSI, but still
|> generally relevant, if people are interested.
|> (or .ps or .pdf if you prefer).

Most interesting, and not particularly C-specific! There are a
few slightly extraneous notes that I would add.

As you say, that was written for older C. Berkeley introduced alloca
and C99 introduced variable sized arrays, both of which would be best
handled by a secondary stack (but rarely are). For that, now sadly
forgotten, wisdom, one must chase up any writings one can find on
Algol 68 implementations, unless someone else can think of a suitable
reference. I can't.

Putting them on the heap leads to horrible fragmentation, but is
common, and putting large or variable arrays on the main stack can
cause very considerable loss of efficiency, especially on systems with
limited offset sizes in instructions but also by cache effects.

It seems to consider only a contiguous stack design. There have
been several implementations that allowed stack extension other
than by moving a 'stack limit' pointer. This isn't hard, and can
be done either by handling interrupts or by having a pointer check
on each call.

Back in 1981, the overhead of a pointer check was still significant,
but it is now negligible. It is still rare, which is sad because
its absence leads (on many Unices) to the stack overlapping some
other segment without warning. Of course, that is serious only on
32-bit systems.

Similarly, it considers only a single-mode design. Systems like
MVS allowed functions using different addressing modes to be linked
together and, of course, this is a MAJOR problem when the system
allows user mode interrupt handlers. The calling sequence and
implementation of setjmp and longjmp can get quite complicated
when you have to allow for changing mode.

[ For people who have not used such systems, under MVS you can
really handle interrupts in user mode - INCLUDING fixing up and
restarting in the middle of a system call - and naturally there
are many and various constraints on when you must return from a
handler, must not return and so on. ]

Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Tel.: +44 1223 334761 Fax: +44 1223 334679

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.