From owner-svn-src-all@freebsd.org Mon May 28 10:14:14 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09DE6F7ACAE for ; Mon, 28 May 2018 10:14:14 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B37887B52 for ; Mon, 28 May 2018 10:14:13 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.197.147 Received: from britannica.bec.de (p5799C593.dip0.t-ipconnect.de [87.153.197.147]) (Authenticated sender: joerg@bec.de) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 19B261C001A for ; Mon, 28 May 2018 12:14:10 +0200 (CEST) Date: Mon, 28 May 2018 12:14:09 +0200 From: Joerg Sonnenberger To: svn-src-all@freebsd.org Subject: Re: Deorbiting i386 Message-ID: <20180528101409.GB5945@britannica.bec.de> References: <201805232218.w4NMIxMA067892@slippy.cwsent.com> <18a87d6d-14af-ef9d-80ff-403039e36692@cs.duke.edu> <20180525003949.GA710@lonesome.com> <05C5BD86-70D0-4B02-AC29-36E68B3602AE@FreeBSD.org> <1A6567CD-5BE8-4E80-A262-00ADB75CF35A@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-Spam-Level: X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 10:14:14 -0000 On Sun, May 27, 2018 at 03:15:05PM -0700, Maxim Sobolev wrote: > Well, strip extra 32 bits, use slower memory and busses (extra decoding > logic etc). Voila, you suddenly have platform that can run 99% of code in > wild today with just few hundred mW of power. Try that with arm32, you > would be surprised how many software is technically compiling and all that, > but has some weird runtime issues with either byte order or unaligned > memory accesses. Not even mention performance issues due to the lack of > hand-crafted JITs. Surprisingly, neither unaligned memory access nor byte order is really a problem on ARM. The first can be turned off on all but vintage CPUs and the latter is typically LE nowadays if not runtime switchable. The two portability gotchas for ARM are entirely different things: (1) char == unsigned char (2) Over-sized shifts are saturing. Joerg