9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] NUMA
Date: Sun, 17 Jul 2011 11:24:45 -0400	[thread overview]
Message-ID: <817df5ce4b22486b880c9a2df854300b@ladd.quanstro.net> (raw)
In-Reply-To: <20110717084411.95552B827@mail.bitblocks.com>

On Sun Jul 17 04:45:18 EDT 2011, bakul@bitblocks.com wrote:

> Also note that the ISA implementations these days are quite
> complex (perhaps even more than your typical program).  We
> don't see this complexty because it is all hidden behind a
> relatively simple ISA.  But remember the FOOF bug? Usually the
> vendor has a long errata list (typically only available on a
> need to know basis and only under NDA!). And usually they
> don't formally prove the implementation right; they just run
> zillions of test vectors! I bet you would be scandalized if
> you knew what they do :-)

i have the errata.  i've read them.  and i find them reassuring.
you might find that surprising, but the longer and more detailed
the errata, the longer and more intricate the testing was.  also
long errata sheets, especially of really arcane bugs indicate the
vendor isn't sweeping embarassing ones under the rug.  i've
seen parts with 2-3 errata that were just buggy.  they hadn't even
tested some large bits of functionality once!  on the other hand
some processors i work with have very long errata, but none of
them matter.  intel kindly makes the errata available to the public
for their gbe controllers.  e.g.
	http://download.intel.com/design/network/specupdt/322444.pdf
page 15, errata#10 is typical.  the spec was violated, but it is
difficult to imagine working hardware for which this would matter.

i can't speak for vendors on why errata is sometimes nda,
but i would imagine that the main fear is that the errata can
reveal too much about the implementation.  on the other hand,
many vendors have open errata.  i've yet to see need-to-know
errata.

by the way, proving an implementation correct seems simply
impossible.  many errata (perhaps like the one i mentioned)
come down to variations in the process that might not have
met the models.  and how would you prove that one of the
many physical steps in producing a chip correct anyway?

- erik



  parent reply	other threads:[~2011-07-17 15:24 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-15 15:15 tlaronde
2011-07-15 20:21 ` tlaronde
2011-07-15 20:47   ` ron minnich
2011-07-15 22:59     ` Charles Forsyth
2011-07-16  8:02     ` tlaronde
2011-07-16 16:27       ` erik quanstrom
2011-07-16 18:06         ` tlaronde
2011-07-16 19:29           ` Ethan Grammatikidis
2011-07-16 19:54           ` erik quanstrom
2011-07-16 20:56             ` dexen deVries
2011-07-16 22:10               ` Charles Forsyth
2011-07-17  1:44                 ` erik quanstrom
2011-07-17  7:38                   ` tlaronde
2011-07-17  8:44                     ` Bakul Shah
2011-07-17 10:02                       ` tlaronde
2011-07-17 12:04                         ` dexen deVries
2011-07-17 15:24                       ` erik quanstrom [this message]
2011-07-17 15:28                         ` ron minnich
     [not found]                         ` <CAP6exYL2DJXbKfPZ8+D5uL=fRWKEyr8vY2OVc4NTO3wsFo=Unw@mail.gmail.c>
2011-07-17 15:32                           ` erik quanstrom
2011-07-17 17:16                         ` Bakul Shah
2011-07-17 17:21                           ` erik quanstrom
2011-07-17 15:51                     ` erik quanstrom
2011-07-17 16:12                       ` dexen deVries
2011-07-17 16:37                       ` tlaronde
2011-07-17 10:08               ` Ethan Grammatikidis
2011-07-17 14:50                 ` erik quanstrom
2011-07-17 17:01                   ` Ethan Grammatikidis
2011-07-17  3:39       ` Joel C. Salomon
2011-07-17  7:01         ` tlaronde
2011-07-17 15:05           ` Joel C. Salomon
2011-07-17 15:26           ` erik quanstrom
2011-07-17 15:52             ` ComeauAt9Fans@gmail.com

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=817df5ce4b22486b880c9a2df854300b@ladd.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /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).