From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20912 invoked by alias); 17 Aug 2016 18:53:10 -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 20903 invoked by uid 89); 17 Aug 2016 18:53:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=stats, evident, sk:duaned, duane@duaneellis.com 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:52:59 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 4BE54340F1B; Wed, 17 Aug 2016 18:52:57 +0000 (UTC) Date: Wed, 17 Aug 2016 18:53:00 -0000 From: Mike Frysinger To: duane@duaneellis.com Cc: "ISHIKAWA, chiaki" , gdb@sourceware.org, ysato@users.sourceforge.jp Subject: Re: h8300 sim: what is "eightbit" memory ? Message-ID: <20160817185256.GD21655@vapier.lan> Mail-Followup-To: duane@duaneellis.com, "ISHIKAWA, chiaki" , gdb@sourceware.org, ysato@users.sourceforge.jp References: <20160817180725.GB21655@vapier.lan> <20160817113508.5c1bb9f86d671edec44bb378f25c04cc.5ecda5525d.wbe@email03.godaddy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cQXOx3fnlpmgJsTP" Content-Disposition: inline In-Reply-To: <20160817113508.5c1bb9f86d671edec44bb378f25c04cc.5ecda5525d.wbe@email03.godaddy.com> X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00040.txt.bz2 --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1659 On 17 Aug 2016 11:35, duane@duaneellis.com wrote: > mike>> if eightbit is just an address mode, that's dirt simple to handle > mike>> a (void *)0 will go to the same memory location regardless of the >=20 > mike>> addr mode used by an insn. but it isn't what the sim is doing > today :(. >=20 > If I remember correctly, the arm simulator does various calculations and > pipeline tracking. > It's been a while, but it was doing this in the giant instruction switch > statement. >=20 > I've not read or looked at the H8 simulator does the H8 simulator sort > of "count instruction/clock time" - based on memory accesses? nope, the h8300 sim doesn't have any stats/tracking like that > The old 6502 had a very similar zero page feature (first 256 bytes) - > aka: a zero page instructions. >=20 > Accessing zero page using a zero page instruction required 3 clocks > (aka: the first 256 bytes) > Accessing absolute required 4 clocks, but you *CAN* access zero page in > absolute mode if you choose > This was useful when I wrote bit-bang uart simulation code (ie: Tight SW > loop - to emulate a uart via GPIO pin) >=20 > Thus - from a logical view the "memory is just memory" end of story. >=20 > if this is not evident in the simulation code, this might have been a > planned feature that never materialized or was never finished. from what i can tell from the H8/300 manuals, there is no zero page, and the first few bytes are reset/exception vectors. https://www.renesas.com/en-us/doc/products/mpumcu/001/e602025_h8300.pdf so it's similar to the 6502 in that you have more efficient addressing for a small bit of memory, but i think that's about it. -mike --cQXOx3fnlpmgJsTP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXtLKIAAoJEEFjO5/oN/WBfLoP/AvuvQroDxbU0JLusPmLGB/K rU93xp52DweTZNgfyevi36kpz5KhKoVbDRB37RCY7GizwkCdUyMc5EQFnuJGNCsF Mh1RGcBMK4Ba6m2qP71Rp678AbHPwxEuIK6jgE+QJ7uS6puLMplOGaXm8FOc9y4n 3YVquWAcbOnZgl1+3myEpGZfPhrjEGd6FB6t+ECdTUTkuddhr1NAvchh2vvlqKOf GFFDFSB4WBKJhdebWPhihIuMkPLsbXGWnnCzZujdizQrGTOqDN9iv+w7plhDtgNQ 02Cuw1+vRiVKxipFIgIC8t4jkpbj3fFfR+rUX2JS8HZnOm8fEhTtIXUP0QnfUvnQ ZQCWIRSKfqNmApolEnImaonw0eafFEmjQt5D6bkrnTT2CZIkdrLFt0CQ543bFoC+ E2tkVLT3Xt5I74iIGaKMyH6EFtkvtUoxvW6zlK9TD8PUAIpg3bTfL46i9Z4a+Hvd 8q7FjemfTM4ALVBsVhMeXM5CiJcbRm1mKnPPomNwrINDpaRbFmqH6qThhRIV7p2Q 6+pUhU3Dh+ShAqwJs41sF8TCgjMdedxkOLCuJD6vXhJ/6AjZrfR27FFEHCkVyZJ8 RbSmbywz29F8XSnxykfnwWed5qFxYzdSlE/E+NV/kRnW/fBF/atoHE7dVy8puWKX rYjbxGADxI1g2N1BcfeA =cmh7 -----END PGP SIGNATURE----- --cQXOx3fnlpmgJsTP--