Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpda!hpcuhb!hpsmtc1!dlw
From: dlw@hpsmtc1.HP.COM (David Williams)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Knowing Machine Code
Message-ID: <17030002@hpsmtc1.HP.COM>
Date: 9 Jun 88 19:02:09 GMT
References: <11093@apple.Apple.Com>
Organization: Hewlett Packard, Cupertino
Lines: 32

in:comp.sys.mac.programmer / dan@Apple.COM (Dan Allen) /writes:

(grammatical stuff deleted)

>I write most of my Macintosh apps in Pascal, my MPW Tools in C, and my
>debuggers, INITs, and other small stuff in Assembly.  I stand by my
>original statement that knowledge of a machine's native assembly
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>language and architecture is very important to writing a good piece of
 ^^^^^^^^^^^^^^^^^^^^^^^^^
Gee, I'm glad I know the architecture of phones, toasters, typewriters and
power drills so that I can use them properly and EFFECTIVELY ;)

Actually compiler writers and OS hackers should know these things in order to
implement faster, cleaner products. Applications programmers/designers should
IDEALLY never have to resort to something as primitive as assembly code. If its
too SLOW in a HIGHER level language, just means the HW/OS/COMPILER combination
is not efficient enough or has serious design compromises built into it. 

Look at Apple, still refusing to use graphics coprocessors in this day and age.
We just brute force the stuff thru the 68xxx for you!! If you are going to stay
with Quickdraw, put it on a QuickDraw RISC chip and pump up the clock speeds.
>code for that machine.  Or at least a fast and successful piece of code.
                                       ^^^^ I'll buy that at least.
Why not make the C/C++ compilers scream?

>(Perhaps the use of the word good implies too much of a moral
>decision-)!

>Dan Allen
>Apple Computer
----------
David Williams
Hewlett Packard