From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115929 invoked by alias); 17 Aug 2016 02:27:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 115915 invoked by uid 89); 17 Aug 2016 02:27:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=snyder, clue, Snyder, H*MI:lan 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 ESMTP; Wed, 17 Aug 2016 02:26:58 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id BAEBB340A9E; Wed, 17 Aug 2016 02:26:56 +0000 (UTC) Date: Wed, 17 Aug 2016 02:27:00 -0000 From: Mike Frysinger To: gdb@sourceware.org Cc: ysato@users.sourceforge.jp Subject: h8300 sim: what is "eightbit" memory ? Message-ID: <20160817022656.GG30544@vapier.lan> Mail-Followup-To: gdb@sourceware.org, ysato@users.sourceforge.jp MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s3R87C3fwYeCSZ0b" Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00034.txt.bz2 --s3R87C3fwYeCSZ0b Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-length: 2469 the h8300 sim has its own implementation for memory handling that i'd like to replace with the common sim memory code. however, it's got a weird bit of code it calls "eightbit mem" that makes this not as easy as it would otherwise be. the code has this comment: /* These define the size of main memory for the simulator. Note the size of main memory for the H8/300H is only 256k. Keeping it small makes the simulator run much faster and consume less memory. The linker knows about the limited size of the simulator's main memory on the H8/300H (via the h8300h.sc linker script). So if you change H8300H_MSIZE, be sure to fix the linker script too. Also note that there's a separate "eightbit" area aside from main memory. For simplicity, the simulator assumes any data memory reference outside of main memory refers to the eightbit area (in theory, this can only happen when simulating H8/300H programs). We make no attempt to catch overlapping addresses, wrapped addresses, etc etc. */ i've read the H8/300 Programming Manual and the H8/300H Software Manual and can't find documentation on it. the closest i can find is the bits about the exception vectors, but that sounds like a convention where the first 256 bytes of memory are used for a special purpose. the sim will actually allocate a sep memory buffer of 256 bytes and you address it by accessing anywhere outside of main memory. e.g. i would expect code to access it like: uint32_t *data = (void *)0; data[0] = reset_exception_vector; not like the sim expects like: uint8_t *data = (void *)0x1000000; data[0] = ...; the gcc manual doesn't have a lot to say: Use this attribute on the H8/300, H8/300H, and H8S to indicate that the specified variable should be placed into the eight-bit data section. The compiler generates more efficient code for certain operations on data in the eight-bit data area. Note the eight-bit data area is limited to 256 bytes of data. and the gcc code implies that it's accessed via special addressing: eightbit_data: This variable lives in the 8-bit data area and can be referenced with 8-bit absolute memory addresses. but the sim doesn't access its eightbit memory based on specific insns, it does it purely on the addresses requested. unfortunately, much of this code was authored by Michael Snyder, so i can't ask him :(. does anyone familiar with the H8/300 have a clue as to what's going on with this code ? -mike --s3R87C3fwYeCSZ0b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXs8tvAAoJEEFjO5/oN/WBPFkQAJQ3vX10rwE4fcJ5djyAfC64 1rMZ+wzNpd0uBsg73XmKz8ry9Q22Qw30Eel45UeDziD6P4CefndhTMdOjJlyE5Cz vKspCaT2Ck3Y8ycAoDg3SqACPigl4WP9Ezo0zHM98NWEU4ujLyjdZeWOovAt9pQL vm6T6ECmkC7jVrDBLM52Sn0i4N8nVq0lD7+2BlhZGcz4eGGY4FUTpvlLGzxZ1iyE 0Ru3dVDB3Fxz98Ieeuog+hfwoeMxJgGUT+X+PsilABIBAp/pNeg+WsQURpLx3ysg Z2d4FOP8kRjLc+qzpVoq+vGw9OfoZRdhJSWz/kJl1cH8u8NNfi9okmIQlgqsBVbi mJfAZGfL2YmzxZTv2qJomvurpFrxrov6F+VCt40cIEbzceA5FN9mVb1dab7owmKj XxNHAJYidIcCdYmu72W/4Pvlkdx/GhTDEYEVieUHBBwQsKYHBec46LupviG9rOiY EHP4M6SDDtCa4gW2ltlrSPNw5aw5gfCS2NdaePf7nuop7oyq5K9A/NHPex4K1sJH ip4myk0PieB3pi95i6bBStoaqW2u/cgAzhFL3JBxb9xmJirreYpa1LapzJX3GMJx 3TKZx7Deng0lXz+KOEG/QxIrLUfZ0zG6bm+Pt7+q2VdrWYUzef56aNwRJLwuveq1 t0DE8RsmfM0q24cvEbY6 =DBVh -----END PGP SIGNATURE----- --s3R87C3fwYeCSZ0b--