From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=a8Gc=A4=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34])
	by sourceware.org (Postfix) with ESMTP id D8A153858D32
	for <gcc-patches@gcc.gnu.org>; Sun,  7 May 2023 19:16:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D8A153858D32
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id BF8B692009C; Sun,  7 May 2023 21:16:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id B876C92009B;
	Sun,  7 May 2023 20:16:13 +0100 (BST)
Date: Sun, 7 May 2023 20:16:13 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
cc: YunQiang Su <yunqiang.su@cipunited.com>, 
    Richard Sandiford <richard.sandiford@arm.com>, gcc-patches@gcc.gnu.org, 
    YunQiang Su <syq@debian.org>
Subject: Re: [PATCH v2] MIPS: add speculation_barrier support
In-Reply-To: <EC557C8F-4487-456F-9BD1-ACE9EBB7453A@flygoat.com>
Message-ID: <alpine.DEB.2.21.2305072001480.54316@angie.orcam.me.uk>
References: <20230428123327.686353-1-yunqiang.su@cipunited.com> <20230428131249.713463-1-yunqiang.su@cipunited.com> <mpth6sttgj1.fsf@arm.com> <alpine.DEB.2.21.2305031948370.26664@angie.orcam.me.uk> <3C634BC6-7556-4724-8012-83F8F3C1C1B3@flygoat.com>
 <alpine.DEB.2.21.2305041628470.42277@angie.orcam.me.uk> <EC557C8F-4487-456F-9BD1-ACE9EBB7453A@flygoat.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3488.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

On Sun, 7 May 2023, Jiaxun Yang wrote:

> > Both EHB and J[AL]R.HB are backwards compatible however (except for an 
> > obscure 4Kc J[AL]R.HB erratum I came across once and which may be no 
> > longer relevant), so I think the legacy sequence ought to just return via 
> > JR.HB as well, therefore providing the required semantics with newer 
> > hardware.  If it does trap for 4Kc, then the OS can emulate it (and we can 
> > ignore it for bare metal, deferring to whoever might be interested for a 
> > workaround).
> 
> Hmm, I just checked MIPS-IV manual, it seems like HB bit (bit 10) is defined as
> zero for both JR and JALR.
> 
> Is it actually omitted in implementation?

 What has become the hint field was supposed not to be decoded in earlier 
silicon, which is why such encodings were chosen for JR.HB and JALR.HB.  
I was told it was actually verified across existing silicon at the time 
the instructions were being defined with MIPSr1 (i.e. when the hint field 
was added to the ISA).  The issue with the 4Kc was an unfortunate mistake.

 Many instructions are not fully decoded causing encoding aliases, MFHI, 
etc. comes to mind.

  Maciej