Re: Apple 1 CFFA1 AND FORTH +

[David Schmenk <dschmenk@gmail.com>]

On Nov 4, 1:40 am, "Michael J. Mahon" <mjma...@aol.com> wrote:

SNIP

>
> The "quick, ship it before we discover it doesn't work" style is a
> relatively recent "innovation"--I fondly hope it is short-lived.
>
> Maybe when Moore's "Law" peters out some more, we'll begin to expect
> electronics to work for 10-20 years instead of 10-20 months, and
> reliable implementations will be more appreciated by the market...

It depends on the market.

If you're at a large company designing a CPU to be used in products
for the next 5 years that will only undergo process tweaks to cost
reduce it, then it makes sense to spend the engineering resources
upfront and delay tapeout as required.  You can't afford to "fix it in
software" when you don't have control over the software being run on
it.

Small companies developing leading edge technologies don't always have
the luxury of spending 2 years developing and refining a product.
With a total market opportunity of 6 months means a 3 month delay just
put you out of business.  Managing the risk becomes the only way to
survive.  Of course that is no reason for sloppy engineering, but
sometimes there has to be a calculated risk of test coverage, wafer
process technology, software development timelines, QA, etc.

Otherwise you would be reading this on your 16 MHz 386 with a 640x480
VGA running MS-DOS in 2010 (well, I know there are some that still
read this on their 1 MHz Apple II).

>
> >> Quite seriously, suspecting hardware invites a kind of superstition
> >> that is an "easy out" for hard-to-find software problems.  In my own
> >> experience, it has never been a hardware problem--even on a prototype
> >> processor.  (Oh, there were hardware problems, but I didn't find
> >> them with *my* programs!)
>
> > Actually, the phrase "It works on *my* computer." from a developer
> > used to drive me crazy.  As if their computer was the only one it had
> > to work on.
>
> Right.  The astronomical number of configurations in use makes
> comprehensive compatibility testing completely impractical these days.
>

Yet it's still expected that it will.  It's actually getting better
than it was.

> >> BTW, I knew someone who actually found a hardware problem on a 7094.
> >> He found that on this particular machine, floating-point multiply
> >> was not commutative!  It took him a couple of days to get the CEs
> >> to believe him sufficiently to write test programs to prove it, then
> >> they found the defective gate and fixed it.
>
> >>   From that day forward, this math professor always began his FORTRAN
> >> programs with the statement:
>
> >>      IF 2.0 * 0.5 .NE. 0.5 * 2.0 THEN STOP
>
> >> ;-)
> > Hardware, software, the only difference is the packaging.
>
> There is (or at least used to be) one other very significant
> difference:  hardware/firmware was designed and implemented by
> strict, methodical hardware engineers who meticulously designed and
> tested hardware/firmware devices of very limited complexity;
> while software was designed and implemented by much less formal,
> seat-of-the-pants autodidacts who kept changing ridiculously
> complex software until it seemed to work.  ;-)
>
> Hardware engineers:  difficulty 4, score 9.
> Software engineers:  difficulty 9, score 3.
>
> I never met a hardware engineer who, in response to a particularly
> elusive bug, began to suspect errant electrons or quantum fluctuations.
> ;-)  They are pretty clear that 999 times out of 1000, their logic is
> the source of their problem.  (That doesn't mean that very occasionally
> something like cosmic ray-induced single-event upsets didn't turn out to
> be implicated ultimately.  ;-)

No, but heat, crosstalk, noise, etc could also be a culprit.  In the
case of hard to find bugs, it can be more productive to bring in
engineers from multiple disciplines to help track it down.  Sometimes
proving what it isn't is just as helpful as what it could be.
Insights from others who may have different tools at their disposal
can identify problems quicker than having one engineer bang their head
against a problem.  Note that I'm not saying an engineer shouldn't do
their due diligence and quickly blame something else.  I don't really
think many engineers are prone to do that.

>
> -michael
>
> NadaNet 3.1 for Apple II parallel computing!
> Home page:  http://home.comcast.net/~mjmahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."

Dave...