Re: Caller allocates space for callee-save registers

andrew@rentec.com (Andrew Mullhaupt)
Mon, 1 Jun 1992 14:11:28 GMT

          From comp.compilers

Related articles
Caller allocates space for callee-save registers pardo@cs.washington.edu (1992-05-21)
Re: Caller allocates space for callee-save registers pardo@cs.washington.edu (1992-05-27)
Re: Caller allocates space for callee-save registers gaynor@brushfire.rutgers.edu (1992-05-29)
Re: Caller allocates space for callee-save registers henry@zoo.toronto.edu (1992-05-29)
Re: Caller allocates space for callee-save registers andrew@rentec.com (1992-05-31)
Re: Caller allocates space for callee-save registers juul@diku.dk (1992-06-01)
Re: Caller allocates space for callee-save registers andrew@rentec.com (1992-06-01)
Re: Caller allocates space for callee-save registers stephen@estragon.uchicago.edu (1992-06-01)
Re: Caller allocates space for callee-save registers preston@dawn.cs.rice.edu (1992-06-01)
Re: Caller allocates space for callee-save registers leichter@zodiac.rutgers.edu (1992-06-02)
Re: Caller allocates space for callee-save registers pardo@cs.washington.edu (1992-06-03)
Re: Caller allocates space for callee-save registers dalamb@qucis.queensu.ca (1992-06-03)
Re: Caller allocates space for callee-save registers andrew@rentec.com (1992-06-03)
[7 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: andrew@rentec.com (Andrew Mullhaupt)
Keywords: optimize, linker
Organization: Renaissance Technologies Corp., Setauket, NY.
References: 92-05-123 92-05-161
Date: Mon, 1 Jun 1992 14:11:28 GMT

stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
>Andrew Mullhaupt <andrew@rentec.com> discusses the problem of interfacing
>with "essentially alien" library routines, where no opportunity exists to
>bargain over interface conventions and difficulties of data structure
>representation overshadow considerations of low level linkage efficiency.
>
>My view is that this problem CAN be solved now and MUST be solved soon.
>Since it involves interface between different software modules sharing
>hardware, it falls very clearly in the province of the operating system.


This is probably a very good way of looking at the problem. You've certainly
convinced me that it should be solved at the OS level. Unfortunately, in
practice the OS level is the one which takes the longest to change.




> ... In particular, type safety and
>data rerepresentation MUST be moved into the operating system; if you are
>a believer in functional programming it follows a fortiori (since code IS
>data) that code generation must also be moved down below the abstraction
>that the operating system provides.


This is an interesting point. But even as a functional programming
unbeliever I think it makes a lot of sense. I was late to come to the
belief that compilers should have common back ends, (because of early
childhood traumas with the first few f77 compilers), but this is
essentially taking that point of view to the limit. In fact, it looks a
lot like the economical way to develop compilers for heterogeneous
machines. Is OSF's ANDF a step in this direction?


>Once you have a uniform virtual machine with strong typing, the problem
>goes away. (It is specifically the absence of strong typing in C and in
>Unix communication channels that makes Unix source-level portability not
>quite work in this regard - that and the fact that C is far from a good
>intermediate code).


Your uniform virtual machine may entail some performance annoyances, as
far as my limited knowledge reveals. If the uniform virtual machine has no
"endian-ness", (which I presume is included in the word "uniform") but the
underlying processors do have, then some implementations of the virtual
machine have to bite the bullet and swap things, while others do not.
Quite clearly, the chips on which this burden falls may be at a
disadvantage which their manufacturers may view in financial terms.


Later,
Andrew Mullhaupt
--


Post a followup to this message

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