Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 13 Jan 2012 12:09:05 -0600 Message-ID: <4F10733F.4040603@SPAM.comp-arch.net> Date: Fri, 13 Jan 2012 10:09:03 -0800 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 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> <4F0DC609.9020503@SPAM.comp-arch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 37 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-QhxhxFebNXu4l1+y8MoJ35U59aO0lVyr8xdZQth9O9NB4TuI2t0XIvwdxWdtBB7qwTgJuJgEObizR4+!LnegvPtW66pMeJdcr0c5Ilf3X6kaQf1GtceuVdVOFew8bVb8y2na2UUDswAf/PM= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3158 Xref: x330-a1.tempe.blueboxinc.net comp.lang.forth:8842 comp.sys.intel:166 comp.arch:5409 On 1/13/2012 9:47 AM, Joe keane wrote: > In article<4F0DC609.9020503@SPAM.comp-arch.net>, > Andy (Super) Glew wrote: >> I believe an IBM chip did eager ifetch - fetching both sides of a >> branch - but did not actually execute, stalled at decoder or >> therabouts. > > Doing some 'early' loads seems like a good idea, assuming that you have > some IF units free. > > But that is a *lot* different from the other suggestion, copying the > machine state to a different core. Microarchitectures proposed for eager execution: * using the same pipeline(s) as ordinary non-eager ** e.g. if stalled on the main path, execute on the alternative path ** DEE: e.g. if have gone too far down one path, execute on an alternative path that has higher relative probability of success than predicting yet another branch on the current path. Actually, the DEE technique applies to all forms of eager execution. * using eager threads on the same CPU core ** although not necessarily the same pipeline(s) - eager threading was one of the techniques I wanted to investigate on top of my multicluster multithreading (MCMT) substrate -- although in my experience eager nearly always loses out to non-eager forms of speculation. Note that this is not necessarily the same pipeline resources, since in my terminology an MCMT machine like Bulldozer is really a single CPU with multiple execution clusters. * using eager threads of execution on different CPU cores. Problem is that eager threads seldom last long, so it is hard for eager threads to overcome the cost of migrating to another core.