home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.arch:10756 comp.lang.misc:3696
- Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!eff!sol.ctr.columbia.edu!destroyer!gumby!wupost!cs.utexas.edu!sun-barr!lll-winken!gauss.llnl.gov!casey
- From: casey@gauss.llnl.gov (Casey Leedom)
- Newsgroups: comp.arch,comp.lang.misc
- Subject: Re: gotos in hardware
- Message-ID: <141549@lll-winken.LLNL.GOV>
- Date: 15 Nov 92 18:47:19 GMT
- References: <BwxsF6.3DF@mentor.cc.purdue.edu> <1992Nov6.111616.109@turtle.fisher.com> <BxCLAu.5AF@mentor.cc.purdue.edu>
- Sender: usenet@lll-winken.LLNL.GOV
- Followup-To: comp.arch
- Organization: Lawrence Livermore National Laboratory
- Lines: 14
- Nntp-Posting-Host: gauss.llnl.gov
-
- | From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
- |
- | A goto, with no intervening possible exits, should be handled in such a
- | way that that the hardware starts getting the code at the new location
- | early, so that there are no unnecessary delays. It could even issue
- | instructions from that "new" code in the same way it does from current
- | code. The "structured" approach, where unconditional transfers are not
- | the rule, prevents this type of optimization.
-
- Just because you don't see many explicit "goto"'s in ``structured
- programs'' doesn't mean they aren't there. They're usually hidden as
- ``structured goto's'': e.g. "break" and "continue" in C.
-
- Casey
-