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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.