From: smith@sctc.com (Rick Smith)
Newsgroups: alt.folklore.computers
Subject: Re: Mel: Fact or Fiction?
Date: 17 Apr 92 14:07:45 GMT
Article-I.D.: sctc.1992Apr17.140745.18963
Organization: SCTC

lasner@watsun.cc.columbia.edu (Charles Lasner) asks about
optimizing assemblers for drums:

>How did one write a program in symbolic assembler, and then have the SOAP
>thing optimize its addresses?  Even if you write relocatable modules, 

We're talking '50s technology. Relocatable modules tended to be
source code. Linkage editing ('linkers') were developed to meet
the requirements of compiled languages to support "libraries."
Drum optimizing assemblers took assembler source code and generated
absolute binary to load onto the drum.

>this doesn't solve the problem because iterations require
>jumping backwards, etc.

No loop can run faster than the drum rotation speed. That's a
fundamental limitation of the architecture. A good programmer unwinds
loops in cases like that so that execution time of a loop is close to
but always less than the drum speed.  No magic, just a tool to make
some of the work easier.

> Since each instruction carried its own pointer to the next one if
>there is no branch elsewhere, does this imply that a running program looks
>very different from the assembly listing if optimized?  This could be
>perturbing to any assembly language programmer. 

Not if you're used to the idea. You just copy an instruction's jump
address into the switch register and bingo, the next instruction shows
up on the lights. Like following pointers in any linked structure.

> On some machines, the
>mere fact that the code is relocated to a loading address can be somewhat of
>a problem, much less if every word of code is riddled with loaded values
>totally different from listed ones.  It becomes a debugging nightmare if so.

This gets back to your assumption that a drum assembler would create
something akin to a binary object module which then got 'linked.'
A drum optimizing assembler took complete responsibility for
assigning memory locations on the drum. It included the 'linker'
if you prefer to think of it that way.

>Admittedly, when memory becomes random-access (a term to describe the
>fact that memory ISN'T DRUM memory!) symbolic assembly language is the
>way to go, not machine language...

I would argue that in the drum programming environment the assembler
is even more important than in a non-drum environment. Think about
how you would go about writing a properly optimized program for
a drum. It involves making a map of your memory and filling in the
instructions based on engineering estimates of instruction timings.

The whole thing is trivially programmable (it's easy to say that
since it was demonstrated 1/3 century ago). You might want to be
clever about ordering your procedures so that the time critical
stuff gets assigned addresses first. But it just isn't that hard
to do.

I can imagine hackerish situations where one might take the assembled
result and tweak instruction positions to improve the machine
generated optimization.  I wouldn't be surprised if that's what Mel
actually did. All the 'story' tells is that some kid had to fix a
binary listing, we don't know if the binary was generated entirely by
hand. I doubt it in any case. Most people I know will take the tools
to the limit before they jump in and fix it by hand.

Rick.
smith@sctc.com        arden hills, minnesota