Re: Caller allocates space for callee-save registers

juul@diku.dk (Anders Juul Munch)
Mon, 1 Jun 1992 13:02:03 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)
[8 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: juul@diku.dk (Anders Juul Munch)
X-Char-Esc: 29
X-Charset: ASCII
Keywords: optimize, linker
Organization: Department of Computer Science, U of Copenhagen
References: 92-05-123 92-05-161
Date: Mon, 1 Jun 1992 13:02:03 GMT

stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
>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.


Type safety as an OS feature? An OS with builtin type safety would be a
one-language OS. There can be no canonical type description format,
because the concept of type is much too wide for that. One view of what
types are is that a type is a set of values. The criterion for dividing
the set of all values into type subsets is entirely in the hands of the
language designer, who might choose non-distinct types (as is the case
with OO typings) and who might choose to use abstract types containing no
information on physical structure.


      Using a high-level language for the lowest level implies that everyone
will use that language, because other HLLs would be an order of magnitude
slower, unless they are very much like the first language.


>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).


C may have its problems used as intermediate code, but do you really think
ML would be better? The higher the level you make the lowest, the more
careful you have to be not to inhibit alternative coding strategies.


Anders Munch | Department of Computer Science
juul@diku.dk | University of Copenhagen, Denmark
[There's nothing that says that the OS has to understand all of the type
tags that it maintains, just that caller/callee tags have to match. If
languages need to add new types, they are free to do so but they can't pass
the new types back to other programs that don't understand them. -John]
--


Post a followup to this message

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