From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101658 invoked by alias); 17 Aug 2016 18:07:29 -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 101647 invoked by uid 89); 17 Aug 2016 18:07:29 -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=240H, accurately, topposting, 240h 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 18:07:27 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 1F499340F5F; Wed, 17 Aug 2016 18:07:26 +0000 (UTC) Date: Wed, 17 Aug 2016 18:07:00 -0000 From: Mike Frysinger To: "ISHIKAWA,chiaki" Cc: gdb@sourceware.org, ysato@users.sourceforge.jp Subject: Re: h8300 sim: what is "eightbit" memory ? Message-ID: <20160817180725.GB21655@vapier.lan> Mail-Followup-To: "ISHIKAWA,chiaki" , gdb@sourceware.org, ysato@users.sourceforge.jp References: <20160817022656.GG30544@vapier.lan> <89caac16-7e2a-3322-3bf4-0356460f7533@yk.rim.or.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <89caac16-7e2a-3322-3bf4-0356460f7533@yk.rim.or.jp> X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00038.txt.bz2 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-length: 1281 On 17 Aug 2016 14:18, ISHIKAWA,chiaki wrote: > Sorry for top-posting, but doesn't this "eightbit mem" refer to area > that is accessible with 8-bit offset? > I think I worked with H8/240H or some such CPU and not sure if H8/300H > has similar architecture. that is what it sounds like from gcc's pov. but that description makes it sound like the first 256 bytes of memory are accessible regardless of addressing mode (e.g. you could use an 8-bit address, or 16-bit with the H8/300, or 24-bit with the H8/300H). the sim implements it not as the same piece of memory, but an actual different address space. so this is the memory map the sim presents: 0x0000 0000...0x00FF FFFF 16MiB of external memory 0x0010 0000...0x0100 00FF the eightbit memory and actually, all addresses beyond 0x100000 are masked into the eightbit mem by doing (addr & 0xff), but that's more of a design choice rather than the sim trying to represent the hardware accurately. i'm trying to figure out how the hardware is supposed to behave so i can accurately adjust the sim to match. if eightbit is just an address mode, that's dirt simple to handle -- a (void *)0 will go to the same memory location regardless of the addr mode used by an insn. but it isn't what the sim is doing today :(. -mike --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXtKfdAAoJEEFjO5/oN/WBZIUP/3EIQPoOtsBNL/WNAfZzLANQ TkmoxhxUVnJ3p3XTHKEj3aVyvBCFBoae0D+jNBUwfdpMLOzhAyskt4iBa4qMzflt Khhn4IqGEHY/l+Y0o4yqcJlrnODWumfSYg9rnsL79+8WuVyLO9lhp7QKxDq+chJb IvgJGL+qZfThJJ2baQmzyMWY4qBhSkqZmNTcn0D1s3UveyhEPK/3KWnYoH5uLjPC yOdAhZW0TZxGZXhodWdSgh/1jrUi9+kKnZ4TSX3TJvx4B3NtYjuZWkEg22M6OJLJ VNIkGUwnykC+AglMZ/BkHBKXgNJwDZJzRfIb3jdXcLcc4cYtNn0C1zWV6AkJo3Is /RKbBcKLNTiyjEAx45qNq8mDqbp5QRWWQOD4ohyqpGOT+roQPUjYSVEEZ91CEeMv b7mJNqh49bpvFTIPpxgHNKjksVlrSTv+w6rwYT0dbqYiiwNTGcZwB4PRShDLcpte r6c0LABKt5hUxSakLYs/C9IxeVQi/K/PmVPox3Yn4GYh36E5ny227vVYSt/BKeA8 dBG/LSkKvNRsco2hj6wMcNLBuSoFjnsnJn+8blilxChkooKTD+JQKi/89PfID66x 1sgkc4wjxnULQ7xWRdDMhiL/brB29CTLCJpDw0olIsEH4WaI0PT2JqDDT91vDzNq 2Z69tggmATymRPoJEZ5p =h2zV -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD--