Re: Why do we still assemble?

(Someone wrote)
> I think that the Burroughs people were pretty proud of the fact that their
> operating system had essentially no assembler code in it. I don't know
> for sure, but I think their (Algol) compiler generated object code
> directly.


Not "essentially" no assembler code, none at all. I still have a listing
of the II.something MCP. It's written in an Algol dialect called ESPOL
which users didn't have access to. It had all the features of Burroughs
Extended Algol (the users' language) + you could get at all the
instructions as procedure calls (like PL/360 or BLISS). If memory serves
(and the listing is in another country) there was one *small* bootstrap
procedure held as binary (not assembler) in an array.


As a matter of fact, a friend and I added assembly code support to the
II.5 Algol compiler. All _I_ ever used it for was to switch off
accounting for my programs, and I only did that once to show it could be
done.


djohnson@arnold.ucsd.edu (Darin Johnson) writes:


>At UC San Diego, A Burroughs for a long time was a primary mchine student
>use. Some people wanted to build a LISP
>interpreter for it.


It's worth noting that there *was* a Lisp compiler for the B6700. It came
from the REDUCE group (Portable Standard Lisp) and worked very nicely
indeed. It compiled Lisp to Algol. I think the copy I saw was acquired
in 1978.


>The architecture, if you're unfamiliar with it, is
>stack based (with Algol the primary language), and to get pointers
>necessary for LISP, a few behind the scenes tricks would have been
>required (microcode?).


There was no user-writable microcode on the B6700. The architecture has
had quite a few different implementations since.


>Folklore has it that before anyone got very far,
>an edict came down from Burroughs through the administration, that this
>was not to be allowed, as a simple user error at the LISP level would have
>crashed the entire machine.


At the University of Auckland the student Fortran compiler (STUFOR)
writted by Dr Fenwick was a compile-and-go system that *did* generate
object. The compiler had "DIRECT ARRAY" (one that wouldn't be "paged")
which it filled with object code, then it called a locally written
intrinsic called GOPHER to change the tags from 0 (s.p.data) to 3 (code).
After running the student's code, it called GOPHER again to change the
tags back. Worked like a charm, and never as far as I know crashed the
machine.


The B6700 had some vector-processing features, and there was a special DO
VECTORMODE statement. (I wrote a library of trig functions to use that;
it gave a useful speedup.) There was syntax to specify the increment for
each array, but if you wanted any increment other than +1 or -1 you had to
recompile the Algol compiler to enable that option, and Burroughs'
documentation warned that if you did that you voided all software
warrantees.


I find any claim that *Burroughs* laid down "an edict" about their
machines rather unlikely, given these two examples. For vectormode with
non-unit increments, they warned about the dangers but explicitly told you
how to do it if you wanted to. As for STUFOR, its techniques were written
up in the company magazine. I wrote a garbage collector in ESPOL and
described it in the same magazine: Burroughs were *not* in the business of
telling people *not* to do things on their machines!


The moderator writes:
>[It is certainly true that the security of the Burroughs systems depended
>on the correctness of application object code, and the compilers were
>trusted components of the system. I hear that the easiest way to hack one
>of them was to write yourself a tape in backup format containing an
>executable program you made yourself that did things a compiler never
>would let you do, then restore the program from the tape and run it. Oops.


The way it worked was that files were tagged with an 8-bit code that
described their contents (APL Workspace, Fortran source code, DMS data
set, whatever), and some of those codes said "this is executable code".
In order to give a file an "object" type a program had to have a special
privilege bit set in its header. This bit could be set or clearer by a
simple command from the operator's console.


When my friend and I produced our version of the Algol compiler (it also
included someone else's DECISIONTABLE stuff, which was real fun) we just
got the computer centre director's permission to ask the operators to set
the privilege bit on that program. End of story. It really wasn't hard.
All it took was a management decision.


The University of Tasmania produced a Pascal compiler for the B6700.
It was a *very* well thought out Pascal system, and another example of
a customer-written compiler for B6700s.
--
Richard A. O'Keefe; ok@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.