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

It is not just a matter of space but of time.  What is really wanted is
a *label to go with the GOTO.  Whether this is stored in an integer or
not is of little concern for wfficient programming.  Even a small looking
table instead of using a register variable costs.  This should have been an
automatic efficiency consideration for at least the past 25 years.
 
> 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 :-)

If a machine handles offests, fine.  Do what works best on the machine.
But if the language does not allow this, there should be some way of
overriding that aspect of the language.

> 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.
 
Fine, as long as only the optimizer uses it.

BTW, besides the goto, there should be a branchto, where it is the
responsibility of the remote code to see that the relevant aspects of
the current configuration are preserved or restored.  This is, at the
present time, difficult to do automatically if there are space proglems,
such as an inadequate number of registers.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)