Path: utzoo!attcan!uunet!bu.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: <2384@l.cc.purdue.edu> Date: 22 Jul 90 15:09:42 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> <10070@brazos.Rice.edu> Organization: Purdue University Statistics Department Lines: 42 In article <10070@brazos.Rice.edu>, preston@titan.rice.edu (Preston Briggs) writes: > In article 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)