Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| optimizing gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-08-12) |
| Re: optimizing anton@mips.complang.tuwien.ac.at (2011-08-13) |
| Re: optimizing haberg-news@telia.com (Hans Aberg) (2011-08-13) |
| Re: optimizing walter@bytecraft.com (Walter Banks) (2011-08-14) |
| Re: optimizing torbenm@diku.dk (2011-08-15) |
| Re: optimizing bumens@dingens.org (Volker Birk) (2011-08-15) |
| Re: optimizing haberg-news@telia.com (Hans Aberg) (2011-08-15) |
| Re: optimizing gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-08-15) |
| From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
| Newsgroups: | comp.compilers |
| Date: | Mon, 15 Aug 2011 18:03:09 +0000 (UTC) |
| Organization: | Aioe.org NNTP Server |
| References: | 11-08-015 11-08-022 |
| Keywords: | optimize |
| Posted-Date: | 16 Aug 2011 00:10:08 EDT |
Walter Banks <walter@bytecraft.com> wrote:
(snip, I wrote)
>> It seems to me, though, that in the case of RISC, and even more in the
>> case of VLIW processors like Itanium, delaying the final optimization
>> and code generation pass would be useful. ...
>> [This is pretty standard in the toolchains for embedded processors. I
>> gather that the ARM compilers generate intermediate code, and all the
>> optimization and code generation happens in the linker. -John]
> To add to John's comment. We have been writing and selling compilers
> for embedded systems for a long time. Since the early 90's we have
> been doing our code generation at link time.
> Embedded systems are unique to make this attractive. The application
> code is almost never hosted, fast small code is highly desired and
> they are compile once run often systems.
In addition, embedded code is rarely expected to run on a newer
generation processor without any code changes.
Consider that a current generation z/OS machine can run programs
compiled and linked for OS/360 over 40 years ago. Maybe not as well
as if optimized for z/Architecture, but not so bad.
Now, consider an Itanium-5 designed in 10 years (well, not likely),
and designed to make optimal use of state-of-the-art technology. Even
to execute the same instructions, the optimal packing of those
instructions into words, or even the instruction word size, may
change. The ability to overlap the execution of instructions depends
very much on how they are ordered by the compiler. Freeing the
processor designed from bit compatibility, while requiring the
intermediate code to stay compatible, should allow for more optimal
processor design.
Maybe there won't be any new VLIW architectures. RISC isn't quite as
dependent on the compiler as VLIW, but RISC does still depend on the
compiler code generator.
Stories are that Office for Mac 2004 won't run at all on OS X Lion,
and that Office 2008 has some problems on Lion. Maybe the expectation
that old programs will run one newer systems is passe. Do people now
expect to by all new software when they buy a new machine?
-- glen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.