From: repo@depo.UUCP (repo man)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Distribution: world
Date: 12 Sep 92 04:26:35 EST
Organization: Organized?  HAH!

In article <1992Sep5.122850.17017@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

<gobs of comments deleted>

> >>>>I write for the 8086/8088 model as do most people.
> >>>>It runs on 8088, 8086, 80186, 80188, 80286, 80386SX, 80386DX, 80486SX,
> >>>>80486DX, 80486DX2, and about 20 non-Intel clones from AMD, NEC, ULSI, TI,
> >>>>and a few other cpu clone maker's cpu's.

I think its safe to infer that you program exclusively for MS-DOS/Intel,
exclusively in assembly.  I don't agree that "most people" code in this
environment, however, given the diversity of platforms and operating systems
to be found.  Since you think the world revolves around DOS and Intel, and
you probably don't care whether or not your application will be used on
anything but the status quo, its quite easy for you to bash HLLs in favor of
the exclusive use of assembly.  Since the users of your software undoubtedly
have generally the same processors, and run the same operating system as
yourself, using assembly in every instance isn't necessarily a bad thing.
None of your programs will run on my 68000 based Amiga of course, at least
not without SUBSTANTIAL effort (which neither you nor I are interested in
providing), and that's perfectly ok.  You have accepted the fact that your
coding work will alienate countless computer users, and that's ok too, I
suppose.  Using the ixemul.library, and amiga GCC, I have *easily* (in fact,
most required only minor shell-specific Makefile alterations) ported the
following GNU applications to AmigaDOS:

compress
diff
elvis (vi clone)
find
egrep
sed
shellutils and textutils (several simple UNIX-like utilities)
tar
gnu-termcap

Not to mention several other UNIX applications.  I stress the ease with
which this was done, and by using the -O2 optimization flag they run quite
swiftly.  I am very happy that the GNU foundation dosen't share your
philosophies and methods of software engineering.

> >>>Yes, but your code will be sub-optimal for all but the 8086/8088.
> >>>And as Lezz Giles pointed out, you can forget about the 68030.
> >>>(and of course, your code won't work for a Z/80 ;-)
> >>
> >>Gee whiz, mea culpa! my 80x86 code can't run on z 68030 or Z-80.  Well, your
> >>C-generated MAC II binary won't run on my '486 :-).
> >
> >So just recompile it!
> >Better yet, distribute your code in source form.
> >Another alternative is to use interpreted languages (like perl),
> >or to compile to a byte-code which is then interpreted.
> >(An application that I have worked on used the latter method to
> >achieve seamless, virtually effortless portability to over 700 different
> >systems.)
> 
> I was one of those suggesting that if hll's should be invented, they should
> be interpreters calling excellently-coded assembly routines, because that
> way you could run code that you couldn't express in the hll, but could call
> in a closed way, although the language wouldn't just abstract what's going on
> in a relatively simple way as we have now, but could be virtually totally
> insulated from it.  This is part of the argument of posters pointing out that
> hll's discussed here aren't high-level enough.

Interpreters have a purpose, certainly not to be used for large scale or
time critical problems, due to the obvious parsing overhead associated with
them.  They are more suited for small utilities and the like.  What is wrong
with the concept of coding the critical parts of your program in assembly,
and linking the results with your other, HLL generated objects?
Interpreters will ALWAYS be slow, for obvious reasons, whereas compilers are
producing output more and more resembling that of what hand-coded assy would
generate.  Again using GCC as an example, the 'C "register" keyword is now
obsolete, and we are in but the infancy of compiler optimization technology.

<more deleted>

In eariler posts you commented about the general proficiency of HLL versus
assembly programmers.  I would like to point out that I personally know and
understand the Motorola 68000 instruction set, inside and out.  I know
EXACTLY what each instruction does, and I understand the subtleties between
them (differences between jsr, jmp, bsr, and bra, for example).  All this
means is that I took the time to learn this.  It dosen't mean I know how to
arrange the instructions in the most advantageous order.  Point being, the
skill of a programmer dosen't lie in the amount of trivious code he can
generate, but in the elegant way he solves the problem at hand.


-- 
      depo!repo@weird.miami.fl.us   "Of all the things I've lost,
repo man ...!mthvax!weird!depo!repo  I miss my mind the most."