Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!munnari.oz.au!mel.dit.csiro.au!latcs1!stephens
From: stephens@latcs2.lat.oz.au (Philip J Stephens)
Newsgroups: comp.sys.apple2
Subject: Re: Re- HLLs vs. Assembly
Message-ID: <1991Apr12.040032.19536@latcs2.lat.oz.au>
Date: 12 Apr 91 04:00:32 GMT
References: <1991Apr6.100927.21953@nntp-server.caltech.edu> <1991Apr9.150402.563@latcs2.lat.oz.au> <15782@smoke.brl.mil>
Organization: Comp Sci, La Trobe Uni, Australia
Lines: 51

Doug Gwyn writes:
>
>I wrote:
>>You can't program effectively in a HLL if you don't know the hardware
>>you're working on, it's limitations and it's features.
>
>Wrong -- any decent HLL should be exploited in terms of the abstract
>model of computation that it supports, most definitely not in terms
>of any specific machine architecture.

  Sorry, I didn't phase that particular comment very well, did I?  I
agree that people should not be writing programs that only work
correctly on their machine, if they wish it to be portable to other
systems.  Unfortunately there is no such thing as a completely
portable program (although C programs under Unix tend to be pretty
good in that regard).
  However, portable programs aren't always the best in terms of speed
or efficiency.  It is sometimes necessary (or just plain desirable)
to use machine-dependent features for a particular implementation of a
program.  Obviously the best way to achieve this is to specify an
interface to machine-dependent routines and let the people who are
porting the program write the necessary code for those routines, which
honours the interface requirements.
  To do this, you must have knowledge of *your* machine.  It is silly
*not* to use machine-independent features when they can improve the
execution of a program such as a compiler, and the more people who are
capable of learning about the hardware of different machines when the
need arises, the better the software will be.
  C already allows this to happen, with it's include file syntax.
Every machine must provide a library of modules to perform the basic
I/O, and all these are machine-dependent.  But normal programmers are
not expected to know how to develop their own machine-dependent
library modules; they are expected to write all their libraries in C
using the existing libraries, and that results in more and more
inefficient programs.
  Curses is a good example of a library module that is unbearably slow
on *all* the Unix systems I've had the misfortune of needing it.  It
really needs to be written in assembly for it to operate at a decent
speed (and no, I'm not confusing the speed of the Curses package with
the speed of the baud rate on the terminal line).  The package is
small enough in it's functionality that an assembly version would not
be all that difficult to implement -- but how many people are actually
willing to do it?  I, for one, would love to tackle that project if I
had the time to do so.

<\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\>
<  Philip J. Stephens                ><   "Many views yield the truth."       >
<  Hons. student, Computer Science   ><   "Therefore, be not alone."          >
<  La Trobe University, Melbourne    ><   - Prime Song of the viggies, from   >
<  AUSTRALIA                         ><   THE ENGIMA SCORE by Sheri S Tepper  >
</\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>