From owner-freebsd-ppc@FreeBSD.ORG Wed Sep 24 01:25:52 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 591AF662 for ; Wed, 24 Sep 2014 01:25:52 +0000 (UTC) Received: from asp.reflexion.net (outbound-240.asp.reflexion.net [69.84.129.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5A5B7A5 for ; Wed, 24 Sep 2014 01:25:51 +0000 (UTC) Received: (qmail 29667 invoked from network); 24 Sep 2014 01:25:44 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Sep 2014 01:25:44 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 23 Sep 2014 21:25:44 -0400 (EDT) Received: (qmail 6762 invoked from network); 24 Sep 2014 01:25:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Sep 2014 01:25:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id CC21B1C402B; Tue, 23 Sep 2014 18:25:37 -0700 (PDT) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: powerpc64/GENERIC64: a mtmsrd without a "context synchronizing instruction" (immediately?) following... Date: Tue, 23 Sep 2014 18:25:42 -0700 References: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net> To: FreeBSD PowerPC ML , Nathan Whitehorn In-Reply-To: <5A754BA9-544A-408F-B45C-691627DCA4ED@dsl-only.net> X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 01:25:52 -0000 Nathan Whitehorn wrote of the use of the document that I was = referencing: > I think you are looking at very old documentation. The 32-bit mtmsr is=20= > implemented on all POWER ISA compliant CPUs (see e.g. page 886 of the=20= > 2.07 document). > -Nathan I think we may be using different documents rather than different = versions of the same document. I may need to find what Nathan is using = and its time frame (PowerPC Architecture 2.07?). But he may want to = check what I've been referencing. So... pem_64bit_v3.0.2005jul15.pdf is Version 3.0 and directly from the IBM = site and has 657 pages... = https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/F7E732FF811F7831= 87256FDD004D3797 It is the current document of its type as far as I can tell. The title = is: > PowerPC=AE Microprocessor Family: >=20 > The Programming Environments Manual for 64-bit Microprocessors >=20 > Version 3.0 >=20 > July 15, 2005. It is described on its web page as: > This manual is to help programmers provide software that is compatible = across the family of PowerPC processors. This book provides a general = description of features common to PPC processors and indicates those = features that are optional or that may be implemented differently in the = design of each processor. This book is for only 64-bit processors. It is different from other architecture documents in that it also = documents the Operating Environment Architecture (supervisor = level/privileged-state resources for operating systems), not just the = UISA and VEA. The document warns that while the UISA is always adhered = to there can be VEA and OEA variations that the document does not cover. = But it also says that the "general-purpose" PowerPC microprocessors = comply with the document. In its own words... > The three levels of the PowerPC Architecture are defined as follows: >=20 > PowerPC user instruction set architecture (UISA)=97The UISA defines = the level of the architecture to which user-level (referred to as = problem state in the architecture specification) software should = conform. The UISA defines the base user-level instruction set, = user-level registers, data types, floating-point mem- ory conventions = and exception model as seen by user programs, and the memory and = programming models. The icon shown in the margin identifies text that is = relevant with respect to the UISA.=20 > PowerPC virtual environment architecture (VEA)=97The VEA defines = additional user-level functionality that falls outside typical = user-level software requirements. The VEA describes the memory model for = an envi- ronment in which multiple devices can access memory, defines = aspects of the cache model, defines cache control instructions, and = defines the time base facility from a user-level perspective. The icon = shown in the margin identifies text that is relevant with respect to the = VEA.=20 > PowerPC operating environment architecture (OEA)=97The OEA defines = supervisor-level (referred to as privileged state in the architecture = specification) resources typically required by an operating system. The = OEA defines the PowerPC memory management model, supervisor-level = registers, synchronization requirements, and the exception model. The = OEA also defines the time base feature from a supervisor- level = perspective. The icon shown in the margin identifies text that is = relevant with respect to the OEA.=20 > Implementations that adhere to the VEA level are guaranteed to adhere = to the UISA level, but may not neces- sarily adhere to the OEA level; = likewise, implementations that conform to the OEA level are also = guaranteed to conform to the UISA and the VEA levels.=20 > All PowerPC devices adhere to the UISA, offering compatibility among = all PowerPC application programs. However, there may be different = versions of the VEA and OEA than those described here. For example, some = devices, such as embedded controllers, may not require some of the = features as defined by this VEA and OEA, and may implement a simpler or = modified version of those features.=20 > The general-purpose PowerPC microprocessors comply both with the UISA = and with the VEA and OEA discussed here. In this book, these three = levels of the architecture are referred to collectively as the PowerPC = Architecture. The distinctions between the levels of the PowerPC = Architecture are maintained clearly throughout this manual, using the = conventions described in the Section Conventions on page 25.=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 22, 2014, at 7:00 PM, Mark Millard wrote: Context: 10.1-BETA2 powerpc64/GENERIC64 (with option DDB and option = GDB). (I later quote from pem_64_bit_v3.0.2005jul2005.pdf (from IBM).) IBM writes of mtmsr/mtmsrd: > For software that will run on processors that comply with = earlier versions of the architecture, a context synchronizing = instruction is required after the mtmsr[d] instruction.=20 That sort of principle does not seem to be followed by one example in = powerpc64/GENERIC64: 0000000000102168 <.__start+0x78> rldimi r9,r8,63,0 000000000010216c <.__start+0x7c> mtmsrd r9 0000000000102170 <.__start+0x80> bl 0000000000101120 = 0000000000102174 <.__start+0x84> ld r2,40(r1) 0000000000102178 <.__start+0x88> lis r3,16 000000000010217c <.__start+0x8c> addi r3,r3,0 ... There other mtmsr's/mtmsrd's that I found had one or two isync's = following, proving the context synchronization instruction. IBM also reports: > Processors designed prior to Version 2.01 of the architecture ignore = the L field. These processors set the MSR as if L were =910=92, and = perform synchronization as if L were =911=92. Therefore software that = uses mtmsrd and runs on such processors must obey the following rules. >=20 > If L=3D =921=92, the contents of bits of register rS other than bits = [48] and [62] must be such that if L were =910=92 the instruction would = not alter the contents of the corresponding MSR bits.=20 > If L =3D =910=92 and the instruction alters the contents of any of the = MSR bits listed below, the instruction must be followed by a context = synchronizing instruction or event in order to ensure that the context = alteration caused by the mtmsrd instruction has taken effect on such = processors.=20 > To obtain the best performance on processors, if the context = synchronizing instruction is isync the isync should immediately follow = the mtmsrd. (Some such processors treat an isync instruction that = immediately follows an mtmsrd instruction having L =3D =920=92 as a = no-op, thereby avoiding the performance penalty of a second context = synchronization.) >=20 Another interesting IBM note for mtmsr (not mtmsrd), but effectively = just a side note here: > The mtmsr instruction, which is otherwise illegal in the 64-bit = architecture may optionally be imple- mented in 64-bit bridge = implementations.=20 FreeBSD powerpc64/GENERIC64 seems to use mtmsr fairly freely. (k_trap, = trapexit, asttrapexit, .breakpoint, dbtrap, dbleave, ichss_set, = prof_clock_cnt, hardclock_cpu, kdb_trap, powerpc_interrupt, = flush_disabnle_caches, spinlock_exit, spin_lock_enter, powerpc_init, = cpu_sleep, moea64_add_ofw_mappings, moea64_late_bootstrap, = moea64_mid_bootstrap, moea64_cpu_bootstrap_native, = moea64_bootstrap_native, write_scom, read_scom, pcr_set, = openfirmware_core, save_vec, enable_vec, configure_final, = cpu_est_clockrage, cpu_idle_60x, save_fpu, enable_fpu, = mps3_cpu_bootstrap. Apple also used mtmsr (not mtmsrd) in the = openfirmware vs. kernel transitions in the published BootX-81 source = code.) =3D=3D=3D Mark Millard markmi at dsl-only.net