From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: Mel: Fact or Fiction?
Date: 17 Apr 92 15:23:32 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <1992Apr17.140745.18963@sctc.com> smith@sctc.com (Rick Smith) writes:
>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

The story indicates that Mel never used the utilities provided, i.e., the 
SOAP-like utility which apparently was widely known (among company employees)
not to work.  The implication is that the program therefore was hand
created down to the low-level details.  I leave it to someone else to guess
if there was an intermediate level we might call almost an assembler, meaning
some of the accoutrements of an assembler, perhaps something akin to a
rudimentary debugger with mnemonic input at least or somesuch, or was it just
ones and zeroes punched on cards/tape?

cjl