Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!njin!uupsi!sunic!lth.se!newsuser From: bengtl@maths.lth.se (Bengt Larsson) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: <1990Jul30.183426.26506@lth.se> Date: 30 Jul 90 18:34:26 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> <1990Jul28.090036.374@lth.se> <2413@l.cc.purdue.edu> Sender: newsuser@lth.se (LTH network news server) Reply-To: bengtl@maths.lth.se (Bengt Larsson) Organization: Lund Institute of Technology, Sweden Lines: 100 In article <2413@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > [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. Why (if you have a fixed number of cases)? In Vax assembler it would be "jmp @jumptable[r0]". On a RISC, it would be a load followed by a branch. (and the VAX has it in a special instruction, CASE, which also takes care of arrays not starting at 1 and checks boundary conditions). >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. So you essentially want to be able to jump to any label, from any ASSIGNed GOTO? Are you aware that this will screw up many optimizations which otherwise could be done across labels? (at least I think it will. I'm no expert on compiler writing, please correct me if I'm wrong). >Of course, the >compiler of that block needs the information that this might happen. I think it will, yes. And I would believe that it will suffer from it. Another idea is that C, for example, allows pointers to functions. Maybe you could make use of that? And _still_ another thing is that if you want local subroutines ("which may not be called from outside"), that's exactly what you get with nested scopes, as mentioned in another article (a local procedure has access to all the surrounding procedures local variables). >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; Which, in a slightly more structured way would be comp: some code; texp -= expr; if (texp >= 0) { more code; goto comp; } wouldn't it? Are you worried that "more code" will mostly not be executed, and therefore you move it, reverse the test, branch and branch back? Is the execution time of your code that critical? And what in the world is an "unbranch to"? What sets it apart from a "branchto" (+ an optimizer)? >A global optimizer might handle this, but the point which has to be made is "the point which _I_ want to make 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. It may be slower. But: do you value your own time? How many hours does it take you to implement an algorithm if you micro-manage it like that? Is it going to be run ten billion times? Is it going to be sold to ten thousand customers? Is it really worth it? If you can achieve 80% of the speed in 20% of the programming time, isn't it worth it? Do you actually _get_ _anything_ _done_ when you program in such detail? How many programs of more than 100 lines have you completed? Of more than a thousand lines? Did they port to faster machines? That's a lot of questions, but I think they have to be made. It may be that you are spending lots of time just to get it "perfect". Unless your code is critical, it may (maybe) not be worth the effort. --------------------------------------------------------------------------- Disclaimer: I'm NOT a compiler writer, if I have totally screwed up somewhere, put it to me gently... :-) --------------------------------------------------------------------------- -- Bengt Larsson - Dep. of Math. Statistics, Lund University, Sweden Internet: bengtl@maths.lth.se SUNET: TYCHE::BENGT_L