Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: HLLs vs. Assembly
Message-ID: <13345@ucrmath.ucr.edu>
Date: 5 Apr 91 07:59:48 GMT
References: <13156@ucrmath.ucr.edu> <1991Mar30.080418.16299@ee.ualberta.ca> <1029@stewart.UUCP>
Organization: University of California, Riverside
Lines: 95

>>>>
By the way, what tendencies do HLL's have that "constrict you into doing
something in a certain way"?
<<<<

All languages (included different assembly languages) have a "programming
paradigm".  The differences between some languages is subtle (e.g., there
are small, subtle, differences between languages like "C" and Pascal, there
are considerable differences between languages like "C", Snobol4, ICON, LISP,
Prolog, and SETL). Some languages are especially suited for certain apps.
For example, Snobol4 and ICON are really great at pattern matching, but fair
poorly in number crunching applications.  APL is great for linear algebra
and matrix arithmetic problems, but you never use it for database
manipulation, COBOL isn't good for anything (okay, I couldn't resist that
one!).  

Any application which requires bit pushing, assembly language wins hands
down (a good example is a SCSI device driver I have been converting from C
to 32532 assembly language).  The program will generally shorter by a factor
of two or more and about 10-100 times faster.  Furthermore, in the hands of
competent assembly and C programmers, the assembly language program will
be easier to read and understand.  This is not an absolute assessment, but
it has been true most of the time, in my experience.

Applications which push bytes around (e.g., text editors, graphic
display drivers, memory managers, etc.) are generally easier to write or
not much more difficult to write in assembly than in a language like C.
Not all such applications, but a good number of them.  Too many times I've
started writing such a program in C only to swear at myself well into the
project because so many components of the project would have been easier to
implement in assembly.  Why not write those components in assembly and call
them from C?  Alas, working in C forces you into a different programming
paradigm.  You have to think about the problem in a different fashion
("Constricting" is such a harsh term).  This paradigm permeates throughout
the code.  Writing a few procedures or functions in assembly will not let
you escape that paradigm.  Assembly language programmers *think* about
problems differently than C programmers.  This is the true reason good
assembly language programmers write much faster code than C programmers.
If you write "C" code using MOVs (or LDAs), you're code isn't going to
be much faster or much smaller than the output of the compiler.  Indeed,
optimizing compilers may beat the pants off of people acting as human
compilers.  I'm sure this is what the original poster was alluding to
when s/he made the above comment.

Of course, there are some applications where the choice of assembly language
is not appropriate.  Assuming a decent toolkit of library routines written
in assembly language, I could not justify writing user interface code in
assembly language.  C, Pascal, or something at a high level (like 4th Dimension
on the Macintosh) is more appropriate.  And there would be very little
performance benefit to sticking with asm.

>>>
I doubt it.  Modern OS's with their multitasking and inter-process
communication capabilities are much more complex than most application
programs.  They have to manipulate process lists, maintain I/O request
queues, use statistical methods and even heuristics to re-prioritize tasks,
etc.  And I'm not even talking about things like graphical window management
and such.  Don't tell me all these things are easier to code in assembly
language than, say, C.

Sure, operating systems used to be simple; all they did was talk to the
hardware.  For these, assembly language was acceptable.  MS-DOS is such
a system.  But for modern OS's like UNIX, assembly language just gets in
the way, and doesn't provide significant performance advantages.
<<<<<

An OS, though, is a byte pusher.  The process manager, communications
managers, device managers, and user interface toolkits would all benefit
from being written in assembly.  The file manager is questionable.

Manipulating process lists, I/O request queues, and reprioritzing tasks is
no big deal in assembly language.  I teach OS (CS 431) at Cal Poly Pomona.
I make my students write their code in 8086 assembly language.  These are
people who are totally incompetent in assembly language.  Yet they manage
to accomplish these tasks quarter after quarter.  Statistical methods
and heuristics are definitely beyond these students, but they're not beyond
me.  They are just fancy names for some really simple processes.  Certainly
not too complex for a reasonable assembly language programmer.  Keep in
mind, that re-prioritizing tasks occurs at the level of the short and
medium-term scheduler.  These processes have to be very fast!  Indeed,
even in UNIX the dispatcher (i.e., short-term CPU scheduler) is typically
written in assembly language.

As for the Graphical User Interface- No way is this easier to write in
assembly than in C.  But there is an obvious performance benefit to having
this written in assembly.  X-Window is a good example of what happens when
you try to write such code in C.  It's wonderful that X is portable, but
you need a H**L of a machine  run in reasonably well.  I'd hate to imagine
a PC (<386), Mac, or *egads* an Apple IIgs where the windowing software was
written in C.
*** RAndy Hyde