From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Favorite CPU
Keywords: Burroughs, ALGOL, MCP
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Tue, 11 Aug 92 16:46:21 GMT

In article <1992Aug8.045945.17898@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <1992Aug07.212531.14134@allegro.com> sieler@allegro.com (Stan Sieler) writes:
>
>>
>I'm sure that's all true, but irrelevant: Compilers that too-nosily check
>for bounds, etc. are making the code run slower; that's one of the tradeoffs
>of "Security" as you relate it, etc.  Most Fortrans are allowed to go off
>the deep end and eventually crash and burn, but when running correctly will
>run quite nicely.  Put bounds checking into the works and watch stable versions
>of code crawl unnecessarily.

This reflects several misconceptions:
a. Code with bounds checks runs slower. This depends heavily on the
   compiler, hardware, etc. It may turn out that bounds checking comes
   for free (System 38), or that having made a bounds check lets you
   produce more optimal code. 

b. "..when running correctly will run quite nicely": Gee, I wish I could
   write applications so that they only ran incorrectly when I was
   developing them. I trust you leave your parachute behind when you
   are soloing, and only take it along with you when the instructor is
   coming along? 

c. The cost of bounds checking is overrated in most places. 
   The cost of NOT bounds checking is only valued by those who place
   performance in front of correctness.
   Please don't write air traffic control systems or xray machine 
   controllers for me if you are of the latter school.

>>As I recall, the original B6500 ALGOL compiler was written in ALGOL on the
>>B5500.  The B5500 compiler was written, I believe, in ALGOL on the B5000.
>>Where that came from, I don't know.

 I think it was bootstraped from another system, but don't have 
hard evidence.

>>Slow?  Hell no!  These machines could be programmed quicker, booted faster,
>>reconfigured easier, and ran better than anything else on the market.  Sure,

This is true. IBM NOW has the ability to slice up a S/390, and maybe
put it back together, but that's more than 20 years later...

>>system.  I remember using virtual memory, multi-processors, multi-programming,
>>HLL programming, and hierarchical file names in 1970 ... years before the
>>rest of the industry rediscovered them.

Yup. 


>This still doesn't answer a basic question: how much faster, especially in
>key routines, perhaps mostly in the O/S, would the thing run if recoded into
>good assembler for the beast.  Apparently the answer is that no one really
>knows, except some from the maligned Davis group.

Not very much. First of all, the Algol compiler was ONE pass. This
meant that we would routinely recompile ALL of APL when we made a
one-line change to it. Took a few minutes -- mostly tape spin time.

>>>But on Burroughs machines, the lack of an assembler wasn't because you
>>>didn't need one - it was because you weren't allowed to use one!
>>Wrong...it was because you didn't need one!
>
>Wrong, it wasn't needed because it wasn't available.  There was no

It wasn't needed because it wasn't needed: You didn't gain anything by
using an assembler: The machine WAS an Algol machine, and Algol constructs
mapped pretty directly onto the hardware. Hmmm. In that sense, there
WAS an assembler. It happened to be Algol.

Because of the almost one-to-one mapping, Algol code ran quite well,
and I doubt if it would ever have been worthwhile to code ANYTHING
in assembler, from a performance standpoint, and certianly not from
a maintenance standpoint.

>>
>>>Actually (according to an article in this newsgroup a year or so ago),
>>>the reason for this was that the machines didn't have any real memory
>>>managament - the only way to prevent user processes from writing into
>>>each other's memory was to use compilers that simply didn't allow it. 

Other way around: The compiler did it, so the hardware didn't need it.
See, RISC technology again: Let the compiler do it.


Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada