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) |
From: | Andrew Fry <andrewf@slhosiery.com.au> |
Newsgroups: | comp.compilers |
Date: | 18 Oct 1998 23:21:32 -0400 |
Organization: | Hilton Hosiery Company |
References: | 98-10-104 |
Keywords: | code |
If it's of any interest to you, I once used a related technique at a
higher level in the compiler for a proprietary language which allowed
(encouraged; very strongly) highly ambiguous expressions.
The technique involved enumerating the various possible
interpretations of an expression; then abstractly "executing" the
stack-machine code using type information instead of values. If the
execution failed (type conflict; empty stack; etc.) or completed with
more or less than 1 item on the stack, then it wasn't a reasonable
interpretation of the expression.
The type information required is very simple (parameter types and
result type) but in the very ambiguous environment I was operating
(many identically named operators with variable numbers of sometimes
optional parameters) the technique suffered from exponential execution
time problems!
Mail me (andrewf@slhosiery.com.au) if you think I can be of any
assistance.
Andrew.
Oukseh Lee wrote:
>
> Hello,
>
> Whoever knows about TYPE ANALYSIS of STACK-MACHINE CODES?
> Please make me know. Thanks in advance.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.