🚀 go-pugleaf

In article <10070@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>In article <ARS4N0F@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>>> Regarding the merits of assigned GOTO, consider an architecture where the
>>> address of an instruction cannot in fact be stored in an INTEGER variable
>>> (because, for example, an address has 64 bits whereas an integer has 32).
>>
>>Given the relatively small number of addresses involved, using a lookup
>>table and a small integer token for each numbered line is an easy solution
>>to this problem.
>
>Sure.  Another alternative would be to use relative offsets from the
>beginning of the routine (not from the ASSIGN point!).  32 bits should
>cover most routines :-)
>
>I think the real problem with label variables is the tangle they make
>of the flow graph.  The poor ol' optimizer sees a "GOTO lvar" and
>says "Well, I guess he can branch to any label?"  We can do better by
>noticing which labels participate in ASSIGN statements, but it's
>still a mess.  Nice programmers (who'd like the optimizer to be
>nice to them) will provide a list of alternatives on their assigned gotos.

If one is only concerned about handling of standard-conforming program, then
you can note that a variable that has been set by an ASSIGN statement is
undefined for normal use.  This means

o  In the 64 bit/32 bit problem, simply have _two_ variables with the given
   name, a 32 bit variable for normal integer use and a 64 bit variable for
   use in the ASSIGN and assigned GOTO statements.

o  If an optimizer sees "GOTO lvar", it can assume that the label branched
   to is one set by "ASSIGN label TO lvar" in the same program unit, where
   we are talking about the _same_ lvar.  In most cases, this is a pretty good
   match with the list the programmer would have provided.
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications