Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <12740@pt.cs.cmu.edu>
Date: 21 Apr 91 18:41:51 GMT
References: <7184@auspex.auspex.com>
Organization: Carnegie Mellon
Lines: 23

In article <7184@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>And what about some of the
>more elaborate procedure-calling, procedure-entry, or procedure-exit
>instructions?
>
>Admittedly, to some extent, the problems with the more elaborate
>features may come either from 1) sloppy implementations of them and
>2) using the elaborate features even when inappropriate

The problem with an elaborate procedure calling convention is that
you *have* to do it that way - by emulation if not by use of the
fancy instructions. To do otherwise is to confuse debuggers,
exception/longjmp packages, and smart linkers, not to mention
breaking separate compilation.

Actually, the worst calling convention I ever dealt with had none of
those problems. IBM 360 PL/I-F didn't *have* a debugger, smart
linkers hadn't been invented, and the exception package was easily
tacked on. The reason it was easy was because the machine code for a
procedure prologue, contained (get this) a *call* to the runtime
package...
-- 
Don		D.C.Lindsay 	Carnegie Mellon Robotics Institute