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: Mon, 31 Aug 1992 05:59:48 GMT

In article <id.UDQS.4_4@ferranti.com> peter@ferranti.com (peter da silva) writes:
>Johnny Billquist <bqt@Minsk.docs.uu.se>:
>> 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?
>
>Charles Lasner replied, with what sure sounds like a slam:
>> How can you tell, when you don't even know what code it generates?
>
>That ticked me off, so I went a little ballistic:
>> 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?
>
>In article <1992Aug26.071344.14926@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> Peter, you've really gone off the deep end now:
>
>> TTL or CMOS means nothing, because it penalizes/assists all code equally.
>
>No it doesn't. A TTL implementation will have different instruction timings
>than a CMOS implementation, and optimising for the TTL or the CMOS version
>of the processor will produce slightly different code. The same is true of
>the microcode, the cache controller, the amount of main memory, the disk
>paging algorithms, the current state of the firmware (cache enabled or
>disabled in the CPU). Good code for a 68000 really sucks on a 68020, and
>vice versa. All of this has to be taken into consideration if you're going
>to evaluate whether it's produced reasonably efficient code.
>
>And I can tune my high level code for a 68000 or for a 68020 simply by setting
>a flag on the compiler command line. That flag changes the size of integers
>(32-bit ints are faster on the 68020, 16-bit ints on the 68000), instruction
>choices, enables in-line floating point code, and so on. Hell, that's a choice
>that's going to radically effect the validity of the code!

But this has nothing to do with any other argument!  Assembler programmers
for years have learned model-dependent quirks, and where needed use
conditional assembly to handle the problem, or macroes.  All you have
succeeded in saying is that there are compilers which may or may not generate
punky code, and that you can affect changes to the relative punkiness of the
code without any yardsticks for whether the code truly is or is not "worthy"
compared to rewriting the application in assembler by a truly competent
person.

>
>> >Assembly language is already a level of abstraction removed from machine code.
>
>> Wrong.
>
>PDP-11 "as":
>
>	jge	foo
>
>Depending on where "foo" is, that will reduce to:
>
>	bge	foo
>
>or
>
>	blt	1f
>	jmp	foo
>1:

There are demented assemblers out there.  We have been fighting them for
years.  Not all of them are so demented, and besides these effects are
known, and quite localized.  A competent programmer caring about this
problem works around it.  Nitpicking aside, the statement stands.

>
>RISC assemblers do even more hacking.
>
>Then we get processors where
>
>	move_word	r0, r1
>
>and
>
>	move_byte	r0, r1
>
>are completely different opcodes, instruction formats, and so on. There's
>even some of this in the 68000...

True, but totally irrelevant.  Your perception of similarity importance is
somewhat strange, and in any case shows nothing for the argument of abstraction
as was stated.  If anything, it helps prove the usual one-to-one correspondance
between assembler and machine language since they *better* be different.

>
>> 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.
>
>Only in CISC processors, and probably not even the majority for those.

Is the PDP-8 a CISC?  On this machine the relationship is 100% 1-to-1.

>
>> >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.
>
>No more than lumping assembly, C, Lisp, and shell into the same sentence.
>The point is that different problems need different tools.
>
>> Machine code as you describe it hasn't been used since the '50's, least of
>> all by you :-).
>
>You'd be surprised.
>
>I've written a lot of 1802 machine code in the course of hacking real-time,
>implementing Forth and debugging my 1802 assembler. I've *still* got parts
>of the 1802 machine code floating around in my head...

That's not the same thing as you implied.  All assembler programmers use
short sections of things like DEBUG assemble and unassemble commands for
non-symbolic numerical assembler.  I can read PDP-8 octal dumps directly and
tell you what's going on.  On a PDP-12, I can use the slow-run option and
watch every machine state change one at a time, and totally follow it as
it moves along.  I have debugged real-time code using fetch/exec stops too, 
and watched the lights to know what's going on, so what?  I still *write*
the code in symbolic assembler to create it in the first place.

Knowing the machine-level code of an architecture and occasionally dealing
with it is not the same thing at all as writing in machine language, as
was typically done in the '50's, where sometimes the attitude was that
a utility to merely state what you could in machine language would be
considered a waste of valuable machine time :-).

cjl