Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
From: scott@yarc.uucp (Scott Beckstead)
Date: Mon, 31 Aug 1992 18:34:37 GMT
Reply-To: scott@yarc.UUCP (Scott Beckstead)
Organization: Yarc Systems

In article <id.5CQS.J03@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Aug26.075307.15738@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> OK, we all know that there is a segment of our industry cranking out poor
>> HLL code, and there is another segment doing a better job.
>
>We do? I can't imagine anyone could address this point unless you identify
>these segments.
>
>I do know that one of the segments of the industry that produces crappy HLL
>code is extremely familiar with assembly: the hobbyists who are now writing
>Mac and Amiga and Windows programs, but who have previously hacked on Apple-2,
>Commodore-64, and Atari-800 machines where you HAVE to pretty much use
>assembler because they're too small to FIT a decent compiler. The HLL code
>I've picked up from BBSes from these people is horrible, even compared to the
>stuff in alt.sources. And these are ALL competant assembly programmers.
>
>> If my remark is so self-serving, then let me see either of you defend how
>> ignorance of assembler helps your hll skills.
>
>My point would be that it is largely irrelevant. Having a good grounding in
>computer design and hardware will help *both* assembly and HLL skills, but
>that learning assembly will not in and of itself make you a better programmer.
>
>Correlation is not cause.
>-- 
>Peter da Silva                                               `-_-'
>$ EDIT/TECO LOVE                                              'U` 
>%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
>Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

   Being one of those competent assembly coders to which Peter refers.
having actualy started in basic then moving to 16 bit mini computer
assembly then to the 6502 (via vic 20) then to forth (via the vic 20)
then to Pascal (via the C-64) then to C (on a 6809 and my C-64) Then to
a plethora of HLL languages and several more assembly languages via the
68000 and 8051 and  You name the embeded processor (yes peter even the
1802) I have to agree that the HLL code cranked out by us hackers is
really bad.  I didn't  really learn to handle HLL coding coherently
until I worked for a man who demanded it.  You see I never did manage to
go to school to learn  this stuff.  One thing I did learn though is that
there is no right  language in which to do a job.  The more languages
you know and the  more operating systems you can handle the more
employable you become. I have written operating systems in pascal, forth
assembler and C but  the only one that it was easy in was forth. 
Impossible to read and maintain  but real easy to implement.  I have
followed this "debate" with  Mr. C.J. Lasner and getting more pissed off
by the minute.  I was once hired to write a parser/os for a peripheral
sharing device it had to be real time  and it was done on a very fast
6502.  I wrote the first pass of the parser and  os in C with low level
drivers for the bit banging in assembly.  The C version of the parser
was prototyped under dos and was debugged inside of 7 weeks.   We were
instructed to do the whole thing in assembly instead.  After more than a
year of coding and debugging it never did run as well as the C code
that I wrote in a month and debugged in less than 3 weeks.  There were
only 3 programmers involved on this project each with a clearly defined 
area of work and each expert in assembly.  This is a typical reason 
that an Hll is used to begin with.  Now I've only been at this since 1974
so I don't claim to know it all, I've seen a lot of back and forth 
argument and it is all pretty much counter productive.  Assmebly has it's
place so do HLL but there is NO RIGHT WAY to learn it or write it nor
is there any magic bullet in assembly to fix all your problems.  As long 
as you have a design spec and a design goal clearly laid out you can't 
go wrong in whatever implementation you choose.  Sorry for the diatribe
but I had to say something.  
Scott
P.S
I'm no writer and I can't spell so please keep the silly flames to a minimum.
SHB


-- 
Reply to: scott@yarc.uucp 	|  
				|	Spin my nipple nuts and send me to   
  Smoke me a kipper, I'll be	| 	Alaska.
   back for breakfast	 	|