Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!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: <2413@l.cc.purdue.edu>
Date: 28 Jul 90 13:50:23 GMT
References: <1991@key.COM> <2378@l.cc.purdue.edu> <ARS4N0F@xds13.ferranti.com> <1990Jul28.090036.374@lth.se>
Organization: Purdue University Statistics Department
Lines: 60

In article <1990Jul28.090036.374@lth.se>, bengtl@maths.lth.se (Bengt Larsson) writes:
> 
> (sorry for commenting this late, we seem to have some problem with the
>  news system here)
> 
> In article <2384@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> 
> (about ASSIGNed GOTOs)

	[Discussion was about ASSIGNed GOTOs without list.]

> Are you _really_ concerned about _one_ extra memory access? (and one likely
> to be in the cache at that?) What sort of code do you write?

An ASSIGNed GOTO is unlikely to have only one memory access.  It may even be
that not all the GOTO locations are known at compile time, and even that
some of the locations may be in another program block.  Of course, the 
compiler of that block needs the information that this might happen.

> (And it would be more polite to put it like "What _I_ really want..."
>  instead of boldly stating "What is really wanted" all the time. Your wishes 
>  and desires may not be the whole worlds.)

Criticism accepted.
> >
> >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.
> 
> What do you mean by this? "where it is the
> responsibility of the remote code to see that the relevant aspects of
> the current configuration are preserved or restored"? This sounds like
> a subroutine call (with callee-save)?

Sometimes this will do, but not always.  For one thing, the code being
branched to is local to the subprogram, and is not going to be called 
from anywhere else, so there is no need for a call-return.  The code
will often be short.  Also, the code does not necessarily return to the
location from which it is called.  A common situation is the following:

comp:	some code;
	texp -= expr;
	if(texp < 0) branchto bad;
	....

bad:	more code;
	unbranchto comp;

A global optimizer might handle this, but the point which has to be made is
that the branch target optimization is subordinate to the main optimization.
The "structured" way of doing this is likely to insert the branch block into
the main code, and unless fall-through is not faster than branch, and the
instruction cache is large, this is likely to lead to slower code.

-- 
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)