Re: Can someone explain step by step how one avoid many conditional in forth as described in Moore Fourth essay?

Message-ID	<4F0DC609.9020503@SPAM.comp-arch.net> (permalink)
Date	2012-01-11 09:25 -0800
From	"Andy (Super) Glew" <andy@SPAM.comp-arch.net>
Organization	comp-arch.net
Newsgroups	comp.lang.forth, comp.sys.intel, comp.arch
Subject	Re: Can someone explain step by step how one avoid many conditional in forth as described in Moore Fourth essay?
References	<19111298.516.1326191150632.JavaMail.geo-discussion-forums@yqbu38> <jehfpu$9de$1@dont-email.me> <jejuor$922$1@speranza.aioe.org> <e222444f-1181-4388-bdbd-7824b05c8154@dp8g2000vbb.googlegroups.com>

Cross-posted to 3 groups.

Show all headers | View raw

On 1/11/2012 4:29 AM, Alex McDonald wrote:
> On Jan 11, 12:21 pm, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
> wrote:
>> "Arnold Doray"<inva...@invalid.com>  wrote in message
>>
>> news:jehfpu$9de$1@dont-email.me...
>> ...
>>
>>>> [Forth code]
>>
>>> CPU pipelining is improved by reducing conditionals. Modern CPUs have
>>> branch prediction, but these aren't always successful, in which case the
>>> pipline needs to be flushed, lowering the CPU's throughput.
>>
>> Is that still true for multiple cores?
>>
>> I.e., I would think the following is entirely possible and plausible, but I
>> haven't studied a CPU design in decades.  The CPU's designers could execute
>> the process in parallel with one core taking one direction for the branch
>> and the another core taking the other branch direction.  Once the correct
>> branch is determined, the bad execution path is discarded.  If the primary
>> core had the good execution path, it just continues execution.  If the
>> alternate core had the good execution path, it's internal state could be
>> "pushed" to the primary core.  If they used static ram for the internal
>> state, then it could be "pushed" asynchronously, i.e., between clocks or
>> sub-clocks.  It would require reserving a core for the branch path
>> execution, at least temporarily.
>>
>> Rod Pemberton
>
> Search on "speculative execution". It can also be done at the compiler
> level; that doesn't require processor support. Intel's P6 was their
> first chip to support it iirc.

Taking both paths on a branch is currently called "eager execution".

Branch prediction is one form of "speculative execution".

P6 did speculative, but not eager.  As, for that matter, did P5 (Pentium).

I don't know of anyone doing full eager execution, although it has been 
studied out the bejeezus.  Branch prediction usually beats it.  I 
believe an IBM chip did eager ifetch - fetching both sides of a branch - 
but did not actually execute, stalled at decoder or therabouts.

Back to comp.sys.intel | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

csiph-web