Re: Reconstructing the Types of Stack-Machine Codes

anton@mips.complang.tuwien.ac.at (Anton Ertl)
18 Oct 1998 23:16:31 -0400

          From comp.compilers

Related articles
Reconstructing the Types of Stack-Machine Codes cookcu@ruby.kaist.ac.kr (Oukseh Lee) (1998-10-17)
Re: Reconstructing the Types of Stack-Machine Codes anton@mips.complang.tuwien.ac.at (1998-10-18)
Re: Reconstructing the Types of Stack-Machine Codes M-Jourdan@calva.net (1998-10-18)
Re: Reconstructing the Types of Stack-Machine Codes andrewf@slhosiery.com.au (Andrew Fry) (1998-10-18)
Re: Reconstructing the Types of Stack-Machine Codes cwm2n@cobra.cs.virginia.edu (Christopher W. Milner) (1998-10-21)
Re: Reconstructing the Types of Stack-Machine Codes kers@hplb.hpl.hp.com (1998-10-24)
Re: Reconstructing the Types of Stack-Machine Codes Jan.Vitek@cui.unige.ch (1998-10-30)
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: 18 Oct 1998 23:16:31 -0400
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 98-10-104
Keywords: code

  Oukseh Lee <cookcu@ruby.kaist.ac.kr> writes:
> Whoever knows about TYPE ANALYSIS of STACK-MACHINE CODES?


The JavaVM people have to do this to check the validity of the class
file, and also to do better register allocation (the JavaVM has a
unified stack, but most architectures have separate integer and FP
register sets).


There is also work on statically type-checking Forth (by Jaanus Pöial,
Peter Knaggs and Bill Stoddart), but it is inspired by MLs type
inference and may be overkill for your purpose. You can find these
papers in the Forth bibliography:
http://liinwww.ira.uka.de/bibliography/Compiler/forth.html


> An example to explain why type information help us to generate more
> efficient target code:
>
> For example, for input code (a),
> assuming possible control-flow is A->C and B->C,
>
> A: push 1 A: rsp <- rsp+1 A: r1 <- 1
> push 2 M[rsp] <- 1 r2 <- 2
> jump B rsp <- rsp+1 jump B
> B: push 3 M[rsp] <- 2 B: r1 <- 3
> push 4 jump B r2 <- 4
> C: add B: rsp <- rsp+1 C: ... <- r1+r2
> M[rsp] <- 3
> rsp <- rsp+1
> M[rsp] <- 4
> C: ... <- M[rsp]+M[rsp-1]
> rsp <- rsp -2
>
> *rsp: register for stack *r1,r2: integer registers
> pointer
>
> (a) input (b) stack-emulation (c) efficient
> target code target code
>
> If we know the top of stack before C is two integer, instead of
> stack-emulation target code such as (b), we can generate more
> efficient target code such as (c).


Seems that you only need to know the stack depth statically, not the
types. There is a lot of work on this. You will probably find several
papers discussing this in the JavaVM JIT compiler literature. Among
my own work the most relevant is probably


@InProceedings{ertl&maierhofer95,
    author = {M. Anton Ertl and Martin Maierhofer},
    title = {Translating Forth to Efficient C},
    crossref = {euroforth95},
    url = {http://www.complang.tuwien.ac.at/papers/ertl&maierhofer95.ps.gz},
    abstract = {An automatic translator can translate Forth into C
                                    code which the current generation of optimizing C
                                    compilers compiles to efficient machine code. I.e.,
                                    the resulting code keeps stack items in registers
                                    and rarely updates the stack pointer. This paper
                                    presents a simple translation method that produces
                                    efficient C code, describes an implementation of the
                                    method and presents results achieved with this
                                    implementation: The translated code is 4.5--7.5
                                    times faster than Gforth (the fastest measured
                                    interpretive system), 1.3--3 times faster than
                                    BigForth 386 (a native code compiler), and smaller
                                    than Gforth's threaded code.}
}


@Proceedings{euroforth95,
    title = "EuroForth~'95 Conference Proceedings",
    booktitle = "EuroForth~'95 Conference Proceedings",
    year = "1995",
    key = "EuroForth '95",
    address = "Schloss Dagstuhl, Germany",
}


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html


Post a followup to this message

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