From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 26 Aug 1992 07:13:44 GMT

In article <id.R3JS.3SE@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <bqt.714224577@Minsk> bqt@Minsk.docs.uu.se (Johnny Billquist) writes:
>> >All I expect from a compiler is to produce the most efficient code it can,
>> >with the least amount of hassle.  Lets face it, most compilers do a more than
>> >reasonable job of producing efficient code for most applications.  Ever use
>> >GCC?
>
>> How can you tell, when you don't even know what code it generates?
>
>How can you tell, when you don't know the layout of the CPU? How can you
>tell, when you don't even know if it's implemented in TTL or CMOS? How can
>you tell, when you don't know what FAB line they used. How can you tell,
>when you didn't write the raw bits yourself? How can you tell, when you
>don't have a listing of the microcode?

Peter, you've really gone off the deep end now:

TTL or CMOS means nothing, because it penalizes/assists all code equally.
The ratios that are the jist of any of these arguments aren't determined by
what the underlying logic "family" is.  The code is the lowest accesible
level of the machine.  And, if microcode is available, it isn't gonna
make any difference, assuming it even applies, which it often doesn't.
Microcode concerns timing states, not "programming" in the sense we are
referring to.  If anything, assembler is the only way to fine tune the code
should it matter, using conditional assembly where it might matter, which is
hardly ever.  Faster CPU's will execute faster, regardless of how the code
comes to be running in the machine.

>
>Assembly language is already a level of abstraction removed from machine code.

Wrong.  On some notable crappy assemblers (such as C-based MASM) you slightly
lose control in the sense that due to inadequate assembler design, your
symbolic input isn't *exactly* a one-to-one correspondance to the machine code.
But in all cases they are 100% the same.  The symbol reference indeed is an
abstraction, but gained at literally no expense, since there is a one-to-one
correspondance between the symbol and the addresses of the running program,
further, in odd cases, we have all been known to use machine code to "fool"
the assembler into doing what we want to express as machine code, but couldn't
because of the rules of the language.  Compare this to any tweakng you do with
non-standard implementations of C, etc.  This is miniscule, but I am 
anticipating you're attempting to blow out of proportion extremely small nits
that mostly don't apply to any particular assembler.  By and large, there is
a perfect one-to-one relationship here.  The use of the word abstraction is
not what we mean when we refer to what C does to abstract all computer
architecture into some common syntax to poorly describe subsets of a given
architecture.

>Machine language is already a level of abstraction removed from gates.

True, but totally irrelevant; No one here is suggesting that hardware
designers should program in gates; these are *software*-controlled computers,
not hard-wired logic.  All software *starts* at machine level.  Again, you
are changing the meaning of the word abstraction by applying different
parameters for the word.

>Digital is already a level of abstraction removed from voltages and currents.

Again, true, but totally irrelevant for all of the previous reasons and more.

>Analog is already a level of abstraction removed from physics.

You are getting into a deeper hole :-).

>...
>
>Choose the level of abstraction you need to get the level of inefficiency you
>can tolerate, and work at that level. I work in analog, digital, machine code,
>assembly, Forth, C, Lisp, TCL, Postscript, Shell, whatever tool lets me best
>express the design I have in mind without bogging me down in details. Quibbling
>that I really don't know what's going on is silly... I'm not in this business
>to push electrons. I'm here to solve problems.

You seem to be more in the business of creating problems.  You are getting
ludicrous to lump analog, digital, and the others into the same sentence.

Machine code as you describe it hasn't been used since the '50's, least of
all by you :-).

BTW, in a pure physics sense, you are here to push electrons around :-).

cjl
Xref: sparky alt.folklore.computers:13229 comp.unix.misc:3399