Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Re- HLLs vs. Assembly
Message-ID: <15782@smoke.brl.mil>
Date: 10 Apr 91 05:04:41 GMT
References: <9104060651.AA18946@apple.com> <1991Apr6.100927.21953@nntp-server.caltech.edu> <1991Apr9.150402.563@latcs2.lat.oz.au>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 21

In article <1991Apr9.150402.563@latcs2.lat.oz.au> stephens@latcs2.lat.oz.au (Philip J Stephens) writes:
>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.  Indeed, most errors we see in
the C newsgroup appear to spring from people holding to inappropriate
low-level models that they developed in terms of a specific machine,
which are not correct when applied to another machine.  The only
exception to this should be when writing extremely low-level systems
code such as device drivers that have to diddle memory-mapped I/O
locations just so, etc.  (You can't even write such code in most HLLs,
C being the most notable exception.)

There are a few situations in which certain basic information about
the system can help, for example in a Fortran program that accesses
a huge multidimensional array; if it accesses it in the wrong order,
performance might be poor due to virtual memory "thrashing".  But
knowing what machine opcodes and addressing modes exist is of no real
value to a Fortran programmer.