Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <d225ec41967f4c62bb862f2ffdc85994@www.novabbs.org>
Deutsch   English   Français   Italiano  
<d225ec41967f4c62bb862f2ffdc85994@www.novabbs.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder2.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Reverse engineering of Intel branch predictors
Date: Mon, 11 Nov 2024 17:17:47 +0000
Organization: Rocksolid Light
Message-ID: <d225ec41967f4c62bb862f2ffdc85994@www.novabbs.org>
References: <vfbfn0$256vo$1@dont-email.me> <c517f562a19a0db2f3d945a1c56ee2e6@www.novabbs.org> <jwv1q002k2s.fsf-monnier+comp.arch@gnu.org> <a3d81b5c64ce058ad21f42a8081162cd@www.novabbs.org> <vgsh98$tht0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1994343"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$J.k8HJgFANKRSTqsvu2kL.5NOetNBC.pf7//z4yKhJGn.n22FWsji
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 2480
Lines: 45

On Mon, 11 Nov 2024 9:03:36 +0000, Thomas Koenig wrote:

> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>
>> For example: The classical way to do dense switches is a LD of the
>> target
>> address and a jump to the target. This requires verifying the address of
>> the target. Whereas if you predict as JTT does, you verify by matching
>> the index number (which is known earlier and since the table is
>> read-only
>> you don't need to verify the target address.
>>
>> So, it is not that you don't predict, it is that the data used to
>> verify the prediction is more precise and available earlier.
>
> Hmm... just wondering.
>
> How does this handle
>
>   switch(a)
>     {
>        case 1:
>        case 3:
>        case 4:
>        case 7:
>          /* Do something */
>        break;
>        case 2:
>        case 5:
>        case 11:
>          /* Do something else */
>        break;
>        default:
>          /* Something else entirely  */
>     }
>
> Would the values 1,3,4 and 7 be considered different for
> prediciton purposes?

Probably.

You might take the target IPs and put them in an indirect prediction
target buffer, so that by the time one has (a) one has the first inst-
runctions at the target label. Then, verification is by index
comparison\
not by IP-address comparison.