Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #832
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Green Compiler ? |
| Date | 2013-01-02 19:52 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <13-01-009@comp.compilers> (permalink) |
| References | (3 earlier) <12-12-028@comp.compilers> <12-12-034@comp.compilers> <12-12-037@comp.compilers> <13-01-002@comp.compilers> <13-01-005@comp.compilers> |
Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote: (snip, someone wrote) >> Smaller transistors have more leakage. > ACK (tunneling effect). (snip) > The actual use of registers depends on the control flow taken > *actually*. When a subroutine is optimized for using all available > registers, it has to save and restore the registers on entry/exit. > When it actually does nothing, due to given conditions, the time and > energy used for pushing/popping the registers is only wasted. Some use caller saves, some callee saves. In the latter case, the subroutine knows which registers it will change, and only needs to save those. It is usual to do that save on entry and restore just before return, but with a little extra logic the save might be delayed a little bit. > For that reason some (Texas Instruments?) processors implemented a > register stack, decades ago, with its stack pointer adjusted according > to the number of registers used in a subroutine. This stack could be > moved into the CPU nowadays, eliminating the need for saving registers > in external memory. If I remember the TMS9900, the registers were in memory, so that pointer just changed where in memory they were. > But this optimization reaches a hard limit on > deeply nested calls, with every subroutine using a high number of > registers. In external memory the register-stack size is adjustable to > program needs, just like ordinary stack size is, but a CPU resident > register stack has a fixed depth. Eventually the register stack still > could be kept in RAM, with an dedicated cache equivalent to the L1/L2 > caches. The original idea behind the 8087 register stack was that it would be interrupt driven, spill on overflow, restore on underflow. The problem was that the logic wasn't tested before the chip was built, and then it was too late. Also, it has only 8 entries. > Then the caches would automatically push/pop register contents > depending on their actual *use*, not by fixed push/pop *instruction > sequences*. OTOH we already have nested caches, so that the effect of > an additional register cache is questionable. (see Wikipedia "CPU > cache") A larger register stack, with working automatic spill/restore, and a fast enough interrupt handler, might work. > The x86 architecture uses another approach (register renaming), with a > high number of shadow registers (compared to only 16 addressable > registers). I'm not sure, though, how a compiler should generate code > for best use of that model... I first knew about register renaming for the floating point unit of the IBM 360/91. It was a popular example machine for many generations of books on pipelined processors. With only four floating point registers, renaming was pretty important for out-of-order execution for S/360. That was especially true since the 360/91 was designed to be able to run code not specifically optimized for it. RISC processors tend to expect compilers to order instructions appropriately, and also usually have plenty of registers. (snip) > [There were stacks with the top few registers kept in fast memory in > the Burroughs machines in the 1960s. It was easy to generate code for > them, but since register coloring was invented in the 1970s, modern > code scheduling for normal registers is much more effective. -John] Hmm. Not that I completely understand it, but it seems to me that normal general registers are generally used over shorter distances. Larger ones, such as vector registers, take longer to save and restore, and might also need to store values for a longer time. It could help much not to have to save/restore for every interrupt, for example. -- glen
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Green Compiler ? Abid <abidmuslim@gmail.com> - 2012-12-20 02:00 -0800
Re: Green Compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-23 08:18 +0000
Re: Green Compiler ? Peter Dassow <z80eu@arcor.de> - 2012-12-26 19:31 +0100
Re: Green Compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-28 03:09 +0000
Re: Green Compiler ? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-12-28 08:35 +0100
Re: Green Compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-28 16:14 +0000
Re: Green Compiler ? Peter Dassow <z80eu@arcor.de> - 2012-12-29 09:35 +0100
Re: Green Compiler ? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-12-30 08:14 +0100
Re: Green Compiler ? George Neuner <gneuner2@comcast.net> - 2012-12-31 01:24 -0500
Re: Green Compiler ? "Jonathan Thornburg" <jthorn@astro.indiana.edu> - 2013-01-02 04:09 +0000
Re: Green Compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-02 18:29 +0000
Re: Green Compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-02 05:11 +0000
Re: Green Compiler ? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2013-01-02 07:29 +0100
Re: Green Compiler ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-02 19:52 +0000
Re: Green Compiler ? "Charles Richmond" <numerist@aquaporin4.com> - 2013-01-04 08:59 -0600
Re: Green Compiler ? "Nils M Holm" <nmh@t3x.org> - 2012-12-23 10:01 +0100
Re: Green Compiler ? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-12-24 05:16 +0100
Re: Green Compiler ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-27 13:36 +0000
Re: Green Compiler ? "Nils M Holm" <nmh@t3x.org> - 2012-12-28 09:11 +0100
Re: Green Compiler ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-28 16:57 +0000
Re: Green Compiler ? George Neuner <gneuner2@comcast.net> - 2012-12-28 12:57 -0500
Re: Green Compiler ? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-12-30 09:22 +0100
Re: Green Compiler ? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-27 21:59 -0600
Re: Green Compiler ? Walter Banks <walter@bytecraft.com> - 2012-12-28 10:42 -0500
csiph-web