From: Matt Evans <matt@ozlabs.org>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org, "K.Prasad" <prasad@linux.vnet.ibm.com>
Subject: Re: [PATCH] powerpc: Emulate most Book I instructions in emulate_step()
Date: Thu, 03 Jun 2010 11:10:21 +1000 [thread overview]
Message-ID: <4C0700FD.6060303@ozlabs.org> (raw)
In-Reply-To: <20100603004758.GA19618@brick.ozlabs.ibm.com>
Paul Mackerras wrote:
> [snip]
> The second alternative -- emulating the lwarx/stwcx and all the
> instructions in between -- sounds complicated but turns out to be
> pretty straightforward in fact, since the code for each instruction is
> pretty small, easy to verify that it's correct, and has little
> interaction with other code.
Easy to verify -- visually or logically?
Having had a little experience with interpreters 'invisibly' operating behind the scenes I am all for very rigorous testing of these things. I have lost at least four of my nine lives to incorrect flag values, odd data problems and hideous heisenbugs etc. of such interpreters. Looked at another way, you'd be surprised how much one can break in an interpreter and still successfully run various programs.
Presumably your first pass is completely correct already, but I'm thinking that if any future changes are made to it
it would be good to include test code/modes alongside the interpreter so others can check alterations. E.g. include the "run user program interpreted" test switch patch, or even better compare the interpreted state to real hardware execution. There are other more directed test strategies (e.g. handwritten tests, random code) but these would be a good start.
Cheers,
Matt
next prev parent reply other threads:[~2010-06-03 1:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 11:29 [PATCH] powerpc: Emulate most Book I instructions in emulate_step() Paul Mackerras
2010-06-02 12:45 ` Kumar Gala
2010-06-03 0:47 ` Paul Mackerras
2010-06-03 1:10 ` Matt Evans [this message]
2010-06-03 1:43 ` Michael Ellerman
2010-06-03 6:25 ` Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0700FD.6060303@ozlabs.org \
--to=matt@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=prasad@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).