From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Xenix Support, FICC
Date: Thu, 27 Aug 1992 17:22:07 GMT

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!

> >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:

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...

> 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.

> >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...

I did the 1802 assembler in Fortran, though.

Done some PDP-11 and Z80 machine code, too.

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

In the pure physics sense, I'm here to observe the Universe.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180