NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/os2/advocacy/3432

Text File | 1992-07-30 | 4.2 KB | 77 lines

Newsgroups: comp.os.os2.advocacy
Path: sparky!uunet!elroy.jpl.nasa.gov!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!pshuang
From: [e-mail] (Ping-Shun Huang)
Subject: Re: Portable?
In-Reply-To: [e-mail]'s message of 29 Jul 92 21:48:01 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (News system)
Nntp-Posting-Host: ninja.mit.edu
Organization: Massachusetts Institute of Technology
References: <[e-mail]> <[e-mail]>
Date: Fri, 31 Jul 1992 08:17:26 GMT
Lines: 63

In article <[e-mail]> [e-mail] (Pete Skelly) writes:

 > Now if you have any exception with real issues, argue those, instead of
 > this "ARE" garbage.

I agree, people who are taking too much pleasure trying to pick at every
word and sentence written by Microsoft employees are really making a
poor showing in this newsgroup by acting like children. Stop trying to
provoke hostility -- this goes for BOTH SIDES as appropriate.

 > Programmer A is doing Top Down design, while programmer B is doing
 > bottom up design.  Programmer A can take into account the
 > archetectural quirks of a number of different systems.  Programmer B
 > is going from an archetectural spec for a limited number of systems.
 > In B's case, translating to C may not be that difficult.  Translating
 > to C for another processor or system may be.  It's the hacks
 > introduced in doing that that can cause problems.  In addition, in
 > 'B's case, you have two programmers working on the project.  One who
 > wrote the assembly, and 'B'.  The assembly coder may not have had the
 > same objectives as B, and B may have to hack around some stupid
 > performance things.  Given that A and B are equal programmers, I'd
 > suspect that B would have a far worse time of it.

I think your scenario here isn't completely fair. I would expect the
following would be ordered from most buggy to least buggy code,
programmer quality being equal: (a) writing a new filesystem in
assembly; (b) writing a new filesystem in C; (c) writing a new
implementation of an old filesystem, with abstract specifications in
hand, with an old reasonably debugged assembler implementation
available, including history of the bugs encountered and fixed in that
implementation. I would propose that (a) compares to the HPFS in OS/2
1.x, (b) compares to NTFS, and (c) compares to any re-writes of HPFS for
a portable OS/2. Critical to my ordering of the three in terms of
expected quality of code is that the knowledge base for (c), e.g.
knowing some of the pitfalls that were encountered before and fixes for
them and reasons for them.

Certainly, many of the bug fixes might be for lessons learned which are
very specific to that particular implementation for that particular
platform using that particular development environment. (See footnote.)
However, I would imagine many of the problems encountered and fixed in
the assembler implementation would be ones which pertain to the C code
being written, which are only apparent when you try to turn the paper
specifications into actual machine opcodes.

(Footnote: Unfortunately, the first bug which I could think of that
fitted into the "lessons learned specific..." was one which I
encountered recently on a project. I noticed a stretch of literal
hexadecimal opcodes in one component of a source file and asked my
co-worker why they were hand-assembled when the assembly source was
right there but commented out. His response was that when that code was
originally written, it would not work and he spent hours trying to
figure out why not, to no avail. He finally started tracing it byte by
byte, and finally realized that MASM [not sure which version but I
believe it is one up to date] had compiled the incorrect opcode for an
instruction. Sure enough, when he consulted the Intel 386/486 CPU guide
and inserted the hexadecimal equivalent of what he thought was the
correct opcode instead, the code worked perfectly. This kind of
painfully worked-out fixgets you nowhere in translation to C. :)

--
Ping Huang (INTERNET: [e-mail]), probably speaking for himself