Groups | Search | Server Info | Login | Register
Groups > comp.compilers > #243
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: optimizing |
| Date | 2011-08-15 18:03 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <11-08-026@comp.compilers> (permalink) |
| References | <11-08-015@comp.compilers> <11-08-022@comp.compilers> |
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
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
optimizing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-12 04:05 +0000
Re: optimizing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 12:38 +0000
Re: optimizing Hans Aberg <haberg-news@telia.com> - 2011-08-13 18:12 +0200
Re: optimizing Volker Birk <bumens@dingens.org> - 2011-08-15 13:16 +0000
Re: optimizing Hans Aberg <haberg-news@telia.com> - 2011-08-15 18:55 +0200
Re: optimizing Walter Banks <walter@bytecraft.com> - 2011-08-14 06:29 -0400
Re: optimizing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-15 18:03 +0000
Re: optimizing torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-08-15 09:39 +0200
csiph-web