[comp.sys.intel] I can't take it anymore

m5@lynx.UUCP (Mike McNally) (07/15/88)

I usually don't like to use the net for my personal gripes, but since I
fell that my mental health is a stake (and because this group is
usually so dull) I'm going to gripe now.

Am I (and everybody else here at Lynx) the only person to notice lots
of amazing, glaring typos in the 8-386/8-387 literature?  I mean, in a
preliminary book I could understand some slovenliness, but the inside
cover of my 386 book (freshly delivered by an Intel person) says 1986!

Some examples:

*** Appendix A of the 387 book lists all of the coprocessor
instructions in numeric order.  Aside from some minor complaints about
the format of the list, one should note that the 16-bit integer
instructions are listed as beginning with DA or DB escape bytes.
Section 6.0 of the datasheet included in the back indicates that the
16-bit integer things are DE and DF instructions.  Which is correct?
(The FADD page in the ASM386 manual adds more humorous confusion to the
issue.)

*** In the 80386 book the MOV to and from special register instruction
summary page conflicts with information in the opcode map, appendix A.

*** The opcode map has at least three wrong entries: PUSH Ib is listed
twice (one should be PUSH Iv), the CS seg. override is in the list
twice (one should be DS), and the addressing mode for a CALL entry is
listedd incorrectly (is Av, should be Jv).

*** On at least one instruction summary page (DEC), the opcode value
for one of the versions is left out (I know this kind of thing is on
more than one page, but I am using someone else's copy of the book and
he doesn't have as much stuff marked as I do.)  The opcode values
listed here are often wrong or in conflict with some other table.

*** (This is hearsay, but I tend to believe it) According to someone
who whimsically decided to use some code listed in an example in the
System Programmer's guide, some non-existant instructions (no, not the
bit-stuffing instructions) appear in the code.

I probably could go on, but this is boring.  One should note that much
of the information listed in the tables involves values and
instructions from the 8086, which has been around for long enough for
somebody to figure out how it really works.  These errors have of course
cost my company time and therefore money.

What's the deal?  Doesn't Intel think that literature is important for
the engineer?  Don't they think that shoddy literature reflects poorly
upon the company that produced it?  And finally, my personal pet peeve,
why should I feel good about paying $35  or so for a book (the ASM386
book) that was typeset on a Diablo-esqe lqp (not even with proportional
spacing!!!)?  Can't Intel afford a laser printer???????

******
As a final note, I would like to add that none of this has to do with
other aspects of Intel or its products.  In particular, I should like
to point out to kds that I appreciate his answers to various other
questions I've had.
******

Gee whiz, glad that's off my chest.

-- 
Mike McNally of Lynx Real-Time Systems

uucp: lynx!m5 (maybe pyramid!voder!lynx!m5 if lynx is unknown)

steve@edm.UUCP (Stephen Samuel) (07/19/88)

From article <4056@lynx.UUCP>, by m5@lynx.UUCP (Mike McNally):
> 
> Am I (and everybody else here at Lynx) the only person to notice lots
> of amazing, glaring typos in the 8-386/8-387 literature?  I mean, in a
> preliminary book I could understand some slovenliness, but the inside
> cover of my 386 book (freshly delivered by an Intel person) says 1986!
unh, 86 or 88?? If 86, then I'd be inclined to say that it WAS a preliminary
book (I mean, the '386 hasn't really been out all that long...)
If, on the other hand, the typo was on YOUR part there (or you assumed that
Intel messed up there too), then your charges are a bit more serious.
> What's the deal?  Doesn't Intel think that literature is important for
> the engineer?  Don't they think that shoddy literature reflects poorly
> upon the company that produced it?  And finally, my personal pet peeve,
Then again what do you expect of a company that releases (near)production
volume volume of a chip that can't always multiply right?
 I mean, when *I* can't multiply right, I blame it on the booze, NOT the
chips... 

(Followups redirected to rec.humor. Serious notes should re-redirect or mail)
-- 
-------------
 Stephen Samuel 			Disclaimer: You betcha!
  {ihnp4,ubc-vision,mnetor,vax135}!alberta!edm!steve
  BITNET: USERZXCV@UOFAMTS