From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Mel: Fact or Fiction?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 17 Apr 1992 08:11:56 GMT

In article <1992Apr16.144351.25444@sctc.com> smith@sctc.com (Rick Smith) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>>Just confirming a point that got a little lost in the Mel thread: assembler
>>as we know it today was essentially unavailable for these machines, even as
>>late as the '60's, these early machines never developed what we remotely
>>would call a symbolic assembler. Someone complained that Mel was such a
>>bad programmer that he used machine, *not* assembly language.  The point is
>>that this wasn't an option for Mel, ...
>
>I find this highly unlikely. Assembler technology matured in the '50s;
>about the only changes after that were macros and address mode
>syntaxes.  Assemblers just weren't that hard to write.  I vaguely
>recall an article on "superprogrammers" by one of those guys like
>deMarco where he admitted to writing an assembler in 2 weeks.  I did
>one in a month as a pink faced kid out of school on a machine I'd
>never seen before.  I admit it wasn't in machine language, but...
>
>However, drum machines are a special case since they aren't really
>random access devices. A highly skilled drum programmer is going to
>carefully position every instruction in a program so that it's right
>under the read head when the previous instruction has finished. A
>vanilla symbolic assembler won't help for one of those. You need
>something like SOAP ("Symbolic Optimizing Assembly Porgram") which was
>developed for the IBM 650. SOAP was 1950s technology; I don't remember
>the exact date offhand. SOAP automatically assigned instruction
>locations so that they'd be under the drum head as the program
>executed. That's harder to do right compared to symbolic assembly. I
>can believe that a hardcore coder might not trust it, especially if he
>didn't trust the people who wrote it.
>
>>Further, since the young narrator of our Mel tale was hired to attempt to
>>write a FORTRAN for the thing, it was obviously De Rigeur to write in machine
>>language for all company programmers at that point in time.
>
>It seems even less likely to me that a company would produce a FORTRAN
>compiler when they don't believe in software tools.  Anyway, the
>cheapo approach to compiler writing back then was to write a compiler
>to generate assembly language, and feed that result through the
>assembler to get binary. Took lots of paper tape, of course.  But it
>meant the guys would have had to build an assembler first. Anyway,
>compiler development was much, much riskier back then. I'd expect them
>to develop simpler tools first. People had developed numerous
>techniques for compiiling, but they weren't as transferrable to other
>efforts as they are now.

I think you are giving too much credit to this company :-).  They sound like a
cheap bunch of money grubbers.  We never found out if our young narrator even
finished his project, however the original poster pointed out that only
machine language and FORTRAN were available to his father in the 60's for the
beast.  This would indicate that they never really did an assembler for it
that was worth anything.  From the story, we are told that their equivalent of
the SOAP thing didn't work.  I get the general drift that no one there trusted
any company-provided utility to work, so each person was a "complete
development system" unto themselves, which is also consistent with your
observation about managers, especially since it's apparent that they lost the
non-cheating version of the program.  No one was into library maintenance of
demo programs yet.  Likely the programmer put up the demo at the show himself.

I don't dispute the theoretical possibility of a decent assembler back then,
and if present the reasonableness of using it as a back end for a FORTRAN
compiler.  I do dispute the availability of it to Mel at this particular
company though :-).

How did one write a program in symbolic assembler, and then have the SOAP
thing optimize its addresses?  Even if you write relocatable modules, this
doesn't solve the problem because iterations require jumping backwards, etc.
Are you sure that SOAP actually worked?  In any case, apparently with good
reason, Mel never used their version, and did good hand optimization of the
code.  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.  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.

So, maybe Mel was right to use machine language under any circumstances, since
the tools of the time weren't really good enough for his purposes, which was to
make an atypically faster program that didn't play by the "rules" of 
development virtually all other programs would follow and thus be slow.

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, although someone posted recently that some assemblers don't
generate code one-for-one.  Can someone expand on this?

cjl (My programs aren't loaded with 4096-way interleave :-))