From owner-freebsd-sparc64@freebsd.org Fri May 27 03:21:35 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 DBF7EB4C16F; Fri, 27 May 2016 03:21:35 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 AC1031679; Fri, 27 May 2016 03:21:35 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pa0-x22b.google.com with SMTP id bz2so6068294pad.1; Thu, 26 May 2016 20:21:35 -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=dkWu8SyHWKW0ZPWcskkPm00TWK2Cs6wAUUvMjRCtKkM=; b=RbElxn1pCnRaRLhOwMkUNklzSzViq2spBYg892WQP8F2bSBg2WmVhDlhYPKA07QPM8 c8CFvwYmtb6GGg56DBdPpAUoNIQir0QlNGA7rDw5NX8bjNFSIugJSlVBV3O33SSsP0tE hyniL55uh5EhoJkkAS38zl4a0uKZw1l+POQSneNxfNwTI9MM0zch3eX+3qny4suzH9iQ c45HUuhfzvoDuRwJWMjkIixKweVjSYhTprMAscUZGC6rYO9KvXaOWcSFjVpiiDCIt6AJ fsxliFYR8b401Eq0wqq2sn694gFUMRL+mV8snWzPvyB49i5OnpADs2F5F3XeaMgzSAQd fopw== 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=dkWu8SyHWKW0ZPWcskkPm00TWK2Cs6wAUUvMjRCtKkM=; b=QU2dLTOta2v6gUhvXMSV/+R05U0JPNM+VYPRgZv7qyydaFZ0tLntFRoiOrPdDi+mXF +cM9zu3DxpcD6z3H6muH1DOTA6cb7zgxcON3dDx7+rKqwzP8cD8v9j8KxWvgOOR6U2kO XlwZiq1KUrLdeyMigS4kT3TavykIbdMb0gRoiZp/FFFXHjBvIU2qOK3jK2iVE9Dk4EEL OiAtdegZQCEXOvHerTRVr64dFHn1Te2ePCeH0MyxkOh3HotpXxBa1hDP+Lbv29ZfNAyC YLlcNmnpISMJuTO2cNagN9dk00zSs0R1dw4LI+L7DbUCDbO5ZztOZFLI+WMGwatzWB6J enIw== X-Gm-Message-State: ALyK8tL55qa8VO2gV4dxoZHHCBMB4Ye/mlFZ076or4X6ukePdOjpIxNpLmEPBAqqFOxaACjroeodIVxGNVODpQ== MIME-Version: 1.0 X-Received: by 10.66.26.165 with SMTP id m5mr18269601pag.155.1464319295224; Thu, 26 May 2016 20:21:35 -0700 (PDT) Received: by 10.66.183.232 with HTTP; Thu, 26 May 2016 20:21:35 -0700 (PDT) In-Reply-To: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Date: Fri, 27 May 2016 05:21:35 +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 03:21:36 -0000 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 On 27 May 2016 at 00:03, Mark Millard wrote: > Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access fai= lure [from before -r300694] would (likely?) also be a failure on some forms= of FreeBSD SPARC use? > > > Why I ask: > > One of the ports that I had submitted a bug report for unaligned access p= roblems on a rpi2 (armv7-a/cortex-a7 style handling) was: > > archivers/lzo2 > > ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd recen= tly commented that the report might go away after testing what is now -r300= 694 (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 b= othering the upstream author? > > I have generally stuck to architectures for which I have examples to obse= rve, if nothing else than to validate at least some of my understanding tha= t is from reading materials. I normally only submit what I've observed in s= ome form. > > I've no such SPARC context nor do I have knowledge/reference material for= SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPARC= configuration coverage. > > As a matter of hear-say my impression is that some SPARCs can be configur= ed to require some variation of strict alignment. > > But I do not know how much I can infer from what I observed on a rpi2 (ar= mv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at least = 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 bec= ause of SPARC even if the problem is validated to go away for the updated r= pi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I h= ave 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.org= " --=20 Cedric Blancher Institute Pasteur