Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!rice!titan.rice.edu!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.lang.modula2
Subject: Re: JPI M2 2.00 - PROCEDURE FUNCTIONS & ERROR CHECKING
Message-ID: <10293@brazos.Rice.edu>
Date: 27 Jul 90 17:01:28 GMT
References: <90206.084158TRL3@psuvm.psu.edu> <10218@brazos.Rice.edu> <1990Jul27.102753.21385@diku.dk>
Sender: root@rice.edu
Organization: Rice University, Houston
Lines: 46

In article <1990Jul27.102753.21385@diku.dk> jensting@skinfaxe.diku.dk (Jens Tingleff) writes:
>preston@titan.rice.edu (Preston Briggs) writes:

>>My particular idea needs single-entrance, single-exit,
>>though as another poster pointed out, we could could handle all sorts 
>>of nasty things during optimization when a complete flow graph
>>is constructed anyway.

>Isn't this method flow-analysis ? The whole point about flow-graphs in
>"single-entrance / single-exit" languages is that they are *easy* to
>contruct. The "single.." property gives only reducable flowgraphs (I think
>that's Aho and Ulmanns term for it), which may be processed on the fly
>when parsing, which (to my understanding..) is what's done here.

Well sure.  Modula-2 programs and such always give reducible flow graphs
which simplifies the implementation of certain data flow analysis
algorithms, particularly those involving some sort of interval reduction.

My little example from the other day was a particulalarly simple version
of what Rosen calls "high-level data flow analysis."  By "high-level,"
he meant that the routine's flow graph is never constructed; instead,
we do data flow analysis over the nested statements of the routine.

My example was "particularly simple" because I didn't actually do
any data flow analysis.  We never looked at the data at all.

>The ease of contruction of flowgraphs is one of the points where 
>Modula-2 can be snotty and superior in the company of other languages
>;-) ;-). Note that this ease was put to good use in optimising BLISS
>compilers (BLISS also has reducable flowgraphs) [Wulf et al. "the design
>of an optimising compiler" American Elsevier New York 1975].

Right.  The BLISS compiler also used Rosen's ideas for their data flow
analysis.  In contrast, a typical Fortran compiler might generate
an intermediate form of the program (looking something like
assembly perhaps) and then require the optimizer to discover the
flow graph from this low level form (not that it's particularly
difficult either).

I particularly like the point about M 2 being snotty and superior...
It *is* easy to build the flow graph, which simplifies optimization;
but Wirth is pretty down on optimizing compilers, so ...?

-- 
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu