Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Reverse engineering of Intel branch predictors Date: Wed, 23 Oct 2024 21:06:41 +0000 Organization: Rocksolid Light Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="3376478"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 X-Rslight-Site: $2y$10$guVmDzYnFfHX5EI.2H.Pd.HaU5TRJl.wRzGyNYjQV1nLGPwNs5xvG Bytes: 1874 Lines: 28 On Wed, 23 Oct 2024 18:36:16 +0000, Thomas Koenig wrote: > Seems like Intel branch predictors have been pretty completely > reverse-engineered. The following paper promises to for very > interesting reading: > > https://www.usenix.org/conference/usenixsecurity24/presentation/li-luyi > > I wonder what you think of this... A couple of points (likely perinate only to me):: In MY 66000 ISA:: a) RET is not predicted b) switch() is not predicted c) method calls are not predicted d) GOT calls are not predicted Which pretty much gets rid of the problem. c+d) GOT calls and method calls use the CALX instruction which loads IP from memory--thus not needing prediction--and not using a trampoline, either. a) When RET is seen in the instruction stream more than 1 cycle in front of the DECODE point, various mechanisms are used to fetch instructions at the return address. b) switch() is the JTT instruction