From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68109 invoked by alias); 28 Mar 2015 07:41:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 68099 invoked by uid 89); 28 Mar 2015 07:41:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 28 Mar 2015 07:41:08 +0000 Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 9656C340A85; Sat, 28 Mar 2015 07:41:06 +0000 (UTC) Date: Sat, 28 Mar 2015 07:41:00 -0000 From: Mike Frysinger To: Jiri Gaisler Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 03/13] sim/erc32: Switched emulated memory to host endian order. Message-ID: <20150328074106.GR30239@vapier> Mail-Followup-To: Jiri Gaisler , gdb-patches@sourceware.org References: <1426626170-21401-1-git-send-email-jiri@gaisler.se> <1426626170-21401-4-git-send-email-jiri@gaisler.se> <20150323024519.GB8039@vapier> <550FD646.7040905@gaisler.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7WENQHN97/U9vH7R" Content-Disposition: inline In-Reply-To: <550FD646.7040905@gaisler.se> X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00941.txt.bz2 --7WENQHN97/U9vH7R Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1034 On 23 Mar 2015 10:00, Jiri Gaisler wrote: > On 23/03/15 03:45, Mike Frysinger wrote: > > On 17 Mar 2015 22:02, Jiri Gaisler wrote: > >> --- a/sim/erc32/erc32.c > >> +++ b/sim/erc32/erc32.c > >> +#ifdef HOST_LITTLE_ENDIAN > >> + waddr ^=3D 3; > >> +#endif > >> + mem[waddr] =3D *data & 0x0ff; > >=20 > > doesn't this assume the target is big endian ? this shows up a few tim= es in=20 > > the changes to this file. >=20 > The target (SPARC) is always big endian, so I believe this is correct. wikipedia says: The endianness of the 32-bit SPARC V8 architecture is purely big-endian. Th= e=20 64-bit SPARC V9 architecture uses big-endian instructions, but can access d= ata=20 in either big-endian or little-endian byte order, chosen either at the=20 application instruction (load/store) level or at the memory page level (via= an=20 MMU setting). The latter is often used for accessing data from inherently=20 little-endian devices, such as those on PCI buses. but i guess that'll need quite a bit of work to fix up ? -mike --7WENQHN97/U9vH7R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVFlsSAAoJEEFjO5/oN/WBtPMP/j0WQQRGgW6UAS3G7pj8k3rQ EGf/YzMCpdtFjqzGIhscnDC4VnWwfcMJOxTFVUuwSH0Uq+n0fkbPtGaaNysoofcI AIb6V2vbNOhZIHqixndIiEJ91VBawRmDvCpIz553hkj9I0GideM4VQsh7Drt4tdt CrgBo0Eb/eCdMsjKPnFXPI3mMm8gtmLHBjj6gq2FV7jBRWVr5A85kExDrPIddKNa mtu3eWgvdARjc7fKME+GUk+3wvp1FVz9n1V9B4sXfar3WdBAP2TBXNbxWjx8buPX V+mKFqL6nlyh1EQ7XqjR3js1VS1Cki5jvO0m/B1jZA6MEsIiePyaE8XKy+YEvRaz r06q5a/LkgMjpMyDVK+kPCSpIpW1ne6e7ZThVUgVi6W1Y5lrqOAIJMa1+yJJy9vG 9PEitWj11vhTuo6+DXuxhNM1SPExwt0L6cVuXJUmOBR/X7kIaLbsgzkgJWesfCQf 8bGPqsAeGbF34z+tQ2wM2Y3gw7xha/DAVDTS1nkoR5AqUkSrhbnJFYY+AuuDZCeN +3k/ZvFWcNI6lI+bLKPh0tH6lHyktYS9nbb46ugdBBrMYwxNXnXiy8YgxEdKJbN8 L+8C/0UwTmQiK75TvN59fd3I83F+Ibg0ZrpwUYLbgqVGPRjUGm95l0cQIv7V86B+ AmZNYbH0SAq8V6+FENnK =zDue -----END PGP SIGNATURE----- --7WENQHN97/U9vH7R--