Related articles |
---|
optimizing compilers for low power design idatarm@gmail.com (2014-06-15) |
Re: optimizing compilers for low power design kaz@kylheku.com (Kaz Kylheku) (2014-06-15) |
Re: optimizing compilers for low power design ivan@ootbcomp.com (Ivan Godard) (2014-06-15) |
Re: optimizing compilers for low power design Pidgeot18@verizon.com.invalid (2014-06-15) |
Re: optimizing compilers for low power design derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2014-06-16) |
Re: optimizing compilers for low power design walter@bytecraft.com (Walter Banks) (2014-06-16) |
Re: optimizing compilers for low power design gneuner2@comcast.net (George Neuner) (2014-06-18) |
Re: optimizing compilers for low power design andrewchamberss@gmail.com (2014-06-20) |
Re: optimizing compilers for low power design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-06-20) |
Re: optimizing compilers for low power design ivan@ootbcomp.com (Ivan Godard) (2014-06-20) |
Re: optimizing compilers for low power design genew@telus.net (Gene Wirchenko) (2014-06-20) |
Re: optimizing compilers for low power design gneuner2@comcast.net (George Neuner) (2014-06-20) |
From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | Wed, 18 Jun 2014 04:44:43 -0400 |
Organization: | A noiseless patient Spider |
References: | 14-06-003 14-06-004 14-06-008 |
Keywords: | architecture, hardware, comment |
Posted-Date: | 20 Jun 2014 09:17:15 EDT |
On Mon, 16 Jun 2014 12:11:32 +0100, "Derek M. Jones"
<derek@_NOSPAM_knosof.co.uk> wrote:
>A surprising percentage of power is consumed when a signal changes from
>0 to 1 or from 1 to 0. So the idea is to arrange instruction order to
>minimise the number of transitions at each bit position in an
>instruction sequence.
>
>[CMOS only uses power when it switches, so I'd think approximately all
>of the power would be consumed when a signal changes. The idea of
>Gray coded instruction streams is weirdly appealing. -John]
I'm mostly a software person, so this may be way off base.
However ...
For Gray coding instructions to be effective, most instructions would
have to offer multiple choices for their encoding. Certainly for the
most commonly used instructions and probably there would need to be at
least several choices of encoding.
ISTM then that the decoder becomes n-ways wider at each decision step,
and somewhat deeper [though maybe not twice] due to requiring
additional combining/filtering steps. So fetch to execute latency
would suffer and materially affect [already problematic] branching
performance.
Moreover, I would think that to make this work best you'd also need to
use fixed sized instructions externally so that there is no additional
pre-decode penalties for locating instruction boundaries, aligning
bits, needing extra fetches for instructions that span fetch lines,
etc. You want to be able to just shift and drop each instruction
directly into the decoder. But fixed size instructions would put
additional fetch pressures on the memory system.
On the software side, compilation becomes combinatorially more
expensive. You might save some CPU power at execution, but ISTM that
any savings from the CPU would be minimal because memory and cache
power are unaffected: I don't see any reasonable possibility to
minimize bit transitions from fetch line to fetch line, or farther
across cache address strides (which I think would help only with a
direct mapped cache anyway).
comp.compilers probably is not the right forum, but perhaps someone
who has CPU design experience can *briefly* speak to the hardware
aspect of this idea. Or we can take it to comp.arch.
George
[The Gray coding was mostly a joke. You're right, the circumstances
in which it would be useful are unrealistically limited. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.