Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #832

Re: Green Compiler ?

Path csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end
From glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups comp.compilers
Subject Re: Green Compiler ?
Date Wed, 2 Jan 2013 19:52:00 +0000 (UTC)
Organization Aioe.org NNTP Server
Lines 80
Sender johnl@iecc.com
Approved comp.compilers@iecc.com
Message-ID <13-01-009@comp.compilers> (permalink)
References <12-12-010@comp.compilers> <12-12-012@comp.compilers> <12-12-022@comp.compilers> <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>
NNTP-Posting-Host news.iecc.com
X-Trace leila.iecc.com 1357244146 326 64.57.183.58 (3 Jan 2013 20:15:46 GMT)
X-Complaints-To abuse@iecc.com
NNTP-Posting-Date Thu, 3 Jan 2013 20:15:46 +0000 (UTC)
Keywords performance, architecture
Posted-Date 03 Jan 2013 15:15:45 EST
X-submission-address compilers@iecc.com
X-moderator-address compilers-request@iecc.com
X-FAQ-and-archives http://compilers.iecc.com
Xref csiph.com comp.compilers:832

Show key headers only | View raw


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


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