From owner-freebsd-sparc64@freebsd.org Fri May 27 04:14:55 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57498B4CC90; Fri, 27 May 2016 04:14:55 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26C331325; Fri, 27 May 2016 04:14:55 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pf0-x22f.google.com with SMTP id g64so37760909pfb.2; Thu, 26 May 2016 21:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=sBSNRe3gf63kFJ5c21VlMqTvZ/omf2EELZiyqpV2UZs=; b=VmsPzDRCR5BOXLHf7BOEQZ+h9OZhzum42bxIAT6Na1Y0OWIUMSFekRNkFdpFJ5dV9P Re9RrzB8FlEuIM2hJP1mTsx52qo4lN3w8LSJc1f8wLY7wz8GmztJt9XDDNmApjYnEJSo vDFDbnYBDqudcJFz5BRiEDKSXazpce8AlNM3mkS9ynSJdJDB+sDiZGCxwXEd5NikyG84 EdQduIi3yUGUV3UC70Cle2hq9oAuKJWDPyOAeBAOA0e12ur7tGL8m+PVAXCmDQAfN8kF PeYhw4R4OJU/bJxlZIznOo4M/jHTjn+6jzrcAH2B/2D+q5OXfdgUPZXyPVql+8XT83/H U1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=sBSNRe3gf63kFJ5c21VlMqTvZ/omf2EELZiyqpV2UZs=; b=iTZ8Daco9S/I4ifPGBve2jvfwmuJAS6lkfe6i0n4YXgChz940tZ0HHOasve8kZqXwE BWYwdNlywS+4/PXdLoKIyqoGAd4jbFJ5pI+r/C2T0cWLOzqRuZXfVtZvNlUe5vUK/46i wdK75QPTPiG+IJ4x55msRgXBM5S0aRMEHTICEnPSro0O1Yj3YIzMojamelDjZFxlP0Bb Rcw76M018CxxI/dYC0+AlB4zPeDHLinHT5r82jtTFYefgJevMuJjbxicbrQMzVo5VXxq +Wxj6AqKGN9dMdJ1AMYBy++qHxb/kW4Ybs8T26Fm1rBxHJPmqJC7uB2Tr8PCV9IKO7mN U2+w== X-Gm-Message-State: ALyK8tJ6hI4xxKHFlxi5Bbaw//IJNuVRqoGf0jEK6h31rij70S9IIuHmEA2gp9NtARGeyxsPNwpcNn2BiPWVpw== MIME-Version: 1.0 X-Received: by 10.98.19.5 with SMTP id b5mr19187982pfj.153.1464322494570; Thu, 26 May 2016 21:14:54 -0700 (PDT) Received: by 10.66.183.232 with HTTP; Thu, 26 May 2016 21:14:54 -0700 (PDT) In-Reply-To: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Date: Fri, 27 May 2016 06:14:54 +0200 Message-ID: Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Cedric Blancher To: Mark Millard Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 04:14:55 -0000 SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all 'normal' RISC implementations. SPARCv9 ABI adds some 'special' instructions (separate from the normal load/store instructions) for unaligned access, but as said they come with costs, as stated before PLUS the risk that they are unimplemented in the actual hardware and trigger emulation traps. Ced On 27 May 2016 at 05:59, Mark Millard wrote: > On 2016-May-26, at 8:21 PM, Cedric Blancher w= rote: > >> All pure RISC implementations enforce 'natural alignment' - a 32bit >> data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must >> be 8 byte aligned, a 128bit data type must be 16 byte aligned. >> Some RISC implementations are not pure, but still the misalignment >> comes with a (performance) penalty, either by issuing two loads or >> running through a whole trap handler (!!!!) function with hundreds of >> instructions. >> >> Ced > > Thanks for the notes. > > Having once worked in a "micros" group in a logic analyzer product line f= or many years, working on the software tools that were used for that subjec= t area, I'm very familiar with that general structure of alternatives --but= not with SPARC specifics. In your terminology: I've no clue how pure of a = RISC implementation is involved for any SPARC variation. > > I'm looking for SPARC-specific information that suggests if the defect re= port originally for armv7-a/cortex-a7 as FreeBSD formerly configured things= instead also likely applies to some SPARC variation/configuration that Fre= eBSD supports. (See later below.) > > If FreeBSD has some other fairly strict alignment context that is not a S= PARC that might also serve. > > Unless upstream can be told that some specific FreeBSD variant is unsuppo= rted by their software because of presuming unaligned access is okay, I dou= bt that a report to upstream should be made based on FreeBSD as a context. = (This presumes that the port passes a test under the new armv7-a/cortex-a7 = and related alignment requirements. I'm not to that point yet.) > >> On 27 May 2016 at 00:03, Mark Millard wrote: >>> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access f= ailure [from before -r300694] would (likely?) also be a failure on some for= ms of FreeBSD SPARC use? >>> >>> >>> Why I ask: >>> >>> One of the ports that I had submitted a bug report for unaligned access= problems on a rpi2 (armv7-a/cortex-a7 style handling) was: >>> >>> archivers/lzo2 >>> >>> ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd rec= ently commented that the report might go away after testing what is now -r3= 00694 (allowing more unaligned access on, for example, armv7-a/cortex-a7). >>> >>> Matthias Andree has since asked in a comment: >>> >>>> ISTR SPARC architectures also barf on unaligned access, so is it worth= bothering the upstream author? >>> >>> I have generally stuck to architectures for which I have examples to ob= serve, if nothing else than to validate at least some of my understanding t= hat is from reading materials. I normally only submit what I've observed in= some form. >>> >>> I've no such SPARC context nor do I have knowledge/reference material f= or SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPA= RC configuration coverage. >>> >>> As a matter of hear-say my impression is that some SPARCs can be config= ured to require some variation of strict alignment. >>> >>> But I do not know how much I can infer from what I observed on a rpi2 (= armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at leas= t come configurations. Nor do I have access to a test environment for SPARC= . >>> >>> So I wonder if my archivers/lzo2 submittal in question should survive b= ecause of SPARC even if the problem is validated to go away for the updated= rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I= have some other submittals that might face the same type of question. >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >>> _______________________________________________ >>> freebsd-sparc64@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >>> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.o= rg" >> >> >> >> -- >> Cedric Blancher >> Institute Pasteur > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > --=20 Cedric Blancher Institute Pasteur