[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple 1 CFFA1 AND FORTH +

On 11/4/2010 8:19 AM, David Schmenk wrote:

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.


Absolutely.  The high-volume "consumer" market is the one that
causes me the most concern.


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.


At HP, we built computers used in embedded systems with a requirement
for manufacturing continuity of 20-30 years.  That certainly makes you
stop and think about technology trends!  Consider the space shuttle...


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).


;-)

And for word processing, you can get a lot more done on an Apple II
where you don't spend more time picking fonts than writing.  ;-)


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.


Agreed.  More discipline has been infused over the years--by Microsoft,
no less!


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.


Could not agree more!

I've personally found that trying to explain exactly what is happening
and why that rules out x and y and z is *very* helpful in getting me
to tell the difference between what I *actually* know and what I only
*think* I know.  I've solved a lot of my problems in the middle of such
explanations!  ;-)

-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."