home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.compilers
- Path: sparky!uunet!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!wupost!think.com!spdcc!iecc!compilers-sender
- From: henry@zoo.toronto.edu (Henry Spencer)
- Subject: Re: Pros and cons of high-level intermediate languages
- Reply-To: henry@zoo.toronto.edu (Henry Spencer)
- Organization: U of Toronto Zoology
- Date: Thu, 23 Jul 1992 17:03:03 GMT
- Approved: compilers@iecc.cambridge.ma.us
- Message-ID: <92-07-081@comp.compilers>
- Keywords: C, optimize
- References: <92-07-064@comp.compilers> <92-07-073@comp.compilers>
- Sender: compilers-sender@iecc.cambridge.ma.us
- Lines: 27
-
- shankar@sgi.com (Shankar Unni) writes:
- >This is totally bogus. Let us assume that the ANSI spec were to say: local
- >variables are guaranteed to retain their values when a longjmp() takes you
- >back to the stack.
- >
- >Now how would this be done on a machine with several registers ...
-
- The right way to do it is to have the compiler recognize the presence of
- setjmp() -- ANSI C carefully restricts setjmp() usage so this is
- guaranteed to be possible -- and take suitable precautions.
-
- That is a little tricky in a simple one-pass compiler. What such a
- compiler can do, however, is note the presence of the <setjmp.h> header,
- and take worst-case precautions for code compiled with that header
- visible.
-
- Historical practice is to say that variables marked "register" can lose
- their values, and others can't. Any compiler smart enough to silently
- promote variables into registers ought to be able to handle one of the
- above strategies.
-
- And yes, some of us said these things to X3J11, but they didn't listen...
- --
- Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu utzoo!henry
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-