From: Michael Ellerman <michael@ellerman.id.au>
To: Matt Evans <matt@ozlabs.org>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.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:43:55 +1000 [thread overview]
Message-ID: <1275529435.22020.1.camel@concordia> (raw)
In-Reply-To: <4C0700FD.6060303@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]
On Thu, 2010-06-03 at 11:10 +1000, Matt Evans wrote:
> 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.
Emphatic nod. We all trust Paulus to get this right, but I for one would
not be game to touch it without a test suite.
It's ripe territory for a boot time selftest IMHO.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-06-03 1:43 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
2010-06-03 1:43 ` Michael Ellerman [this message]
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=1275529435.22020.1.camel@concordia \
--to=michael@ellerman.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=matt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.