Talk:Burroughs Large Systems

Assembler

B5000 machines are programmed exclusively in high-level languages, there is no assembler.

and

The B5000 stack architecture inspired Chuck Moore, the designer of the programming langauge FORTH, who encountered the B5500 while at MIT. In Forth - The Early Years, Moore described the influence, noting that FORTH's DUP, DROP and SWAP came from the corresponding B5500 instructions.

If the 5500 didn't have an assembler, where did Chuck Moore get the DUP, DROP and SWAP from? Mhx 14:49, 15 July 2006 (UTC)

When people say "the B5000 had no assembler" what they usually mean was that there was no "computer program for translating assembly language — essentially, a mnemonic representation of machine language — into object code" which is how the relevant Wikipedia article defines assembler. The point being that all software shipped with, or sold for, the B5000 was compiled from source written in a high-level language like ALGOL or ESPOL. Burroughs didn't have any low-level assembly language programmers writing code for the B5000. There was an instruction set of course, just not a tool to allow humans to program directly to the instruction set.

it is a secure architecture?

"...it is a secure architecture that runs directly on hardware..." - if this section means something specific, then it need to be clarified. I can't see the connection between the B5000 and virtual/Java.--Snori 03:50, 2 September 2006 (UTC)

Article is mis-named and misses some stuff

This is a good article, but it needs some improvement.

• The article is named "B5000" but it's really about Burroughs large-scale systems. Many of the features only appeared later
• The article does not emphasize the SMP nature of these machines. The B5500 was the first commercial SMP dual processor machine.
• The article mentions the HP stack machines, but does not mention HP was actually inspired by Tandem computers, which was inspired by the Burroughs large systems.
• The B6500/B6600/B6700/B7500/B7600/B7700 were SMP machines with up to 8 processors on the B7700. But that was the limit: the 8th processor had negative marginal utility as a general-purpose processor,which is why it was used only for I/O. The B6800/B7800 were NUMA architecture, well before anyone else did this.

-Arch dude 04:40, 25 November 2006 (UTC)

Note: You have the order wrong for Tandem versus HP. The HP architecture was derived somewhat from the B5000 series. Tandem was started by Ex-HP folks, consequently the Tandem machines were derived from HP, not the other way around. —Preceding unsigned comment added by 64.81.240.50 (talk) 13:49, 12 May 2008 (UTC)

I am now making the changes, starting with a page move from "Burroughs B5000" to Burroughs Large systems I intend to generalize the article appropriately, and then add the new features. -Arch dude 16:40, 25 November 2006 (UTC)

The much, much bigger problem is that the article fails to distinguish adequately between the B5000/B5500/B5700 and all the later systems, which were not code-compatible with the B5000 and were vastly different in many ways. (By contrast, if Rip van Winkle had gone to sleep operating or programming a B6700 in 1975, he could wake up today and feel right at home with its successors.) The later systems have been constantly renamed by the Burrough/Unisys Sales Prevention Department (B6/7000, Large Systems, A-Series, ClearPath NX/LX, Libra) to the point that the rest of us have given up and just call them MCP systems. But they have a continuity going back to the B6700, whereas there was a sharp discontinuity between the B6700 and its predecessors.--Paleolith (talk) 08:14, 18 December 2007 (UTC)

Most of the description refers to the B6500 and descendants, which had 3-bit tags. The B5000 had a one-bit tag in the data itself rather than external to it. The B5000 also had "stream procedures", essentially hardware string editing routines that used a partially different instruction set and could (and did) happily klobber memory because they ignored the tag bit. Stream procedures were the architectural impetus for the change to the B6500 - Burroughs had to remove the security hole, and so they fixed everything else too.

I wrote the cited DCALGOL compiler. The B6500 software team was 23 people, for a brand new OS, five brand new compilers, and everything else including all documentation. We worked for three years into simulation while Jake Vigil got the hardware working. Two weeks to the day after the new hardware was released to software we had a compiler able to compile itself under OS control on the hardware. Group leader was Ben Dent, to this day the best manager I have ever worked for. - Ivan Godard

Please help with this "History" Table

I started on this, but I do not know enought to finish. Please help.Feel free to edit inline here, or just discuss. -Arch dude 20:59, 26 November 2006 (UTC)

I am moving this to the article, eventhough it is still incomplete. -Arch dude 00:36, 4 January 2007 (UTC)

I am not really prepared to put significant changes in to this table. However, I believe the descriptions for B5500, B5700, B6500, and B6700 may somewhat understate the differences involved, although I am not sure how much more detail should be squeezed into this table. For example, I believe the "cactus stack" architecture was introduced in the B6500, the multiprocessing may have first appeared in the B5500, etc. There were also technically significant architectural differences reflected in both the CPU organization (esp registers) and instruction sets between the B5000 series and the B6000 series. There are other details of probably only historical interest (but, hey, what else are we doing here?), such as the use of "drum" memory on the original system and its replacement with fixed hard disk drives on (I think) the B5500. I will fix one typo in the main article copy of this (if it's still there when I get back to it), and I will try to help with the dates for some of the more recent systems if I can find some of my documentation. -Jeff 22:55, 4 September 2007 (UTC)

Burroughs (1961-1986)
B5000	1961	initial system, 2nd generation (transistor) computer
B5500	1964	3x speed improvement(?)
B6500	1969	3rd gen computer (integrated circuits), up to 4 processors
B5700	1971	new name for B5500
B6700	1971	new name/bug fix for B6500
B7700	1972	faster processor, cache for stack, up to 8 processors.
B6800	1977?	RAM memory, NUMA architecture
B7800	1977?	RAM memory, faster, up to 16? proccessors
A Series	1984	re-implemented with faster ICs?
Unisys (1986-present))
Micro A	1989	desktop "maingrame" with single-chip processor.
Clearpath HMP NX 4000	198?	??
Clearpath HMP NX 5000	199?	??
Clearpath HMP LX 5000	1998	Implements Burroughs Large systems in emulation only (Xeon processors)
Libra 100	2002?	??
Libra 200	200?	??
Libra 300	200?	??
Libra 400	200?	??
Libra 500	2005?	??
Libra 600	2006?	??

UCSD and Burroughs large machines

UCSD had a series of Burrougs large machines for business and academic use. Professor Emeritus Kenneth Bowles gave a presentation at the UCSD Pascal 30th anniversary gathering. He mentioned modifying the O/S to handle student jobs (low memory requirements, low runtime) with less overhead. This was so much better, other universities adopted this fix.MWS 21:42, 15 February 2007 (UTC)

There was something about coopting tag 6 in this context. I remember leafing through a colleague's glossy and seeing an article. MarkMLl 09:36, 4 September 2007 (UTC)

Early competitors

by the late 1950s it had not gone beyond it's Tab products

Can anybody expand on this? As far as I know Burroughs was weak even in this area- it had the Sensimatic for desktop use but nothing approaching the sophistication of IBM "unit record" kit. MarkMLl 09:36, 4 September 2007 (UTC)

I do not know the answer, but whatever it is, it belongs in the Burroughs article, not in the lead paragraph of the Burroughs large systems article. -Arch dude 13:50, 4 September 2007 (UTC)

I didn't say a full exposition did belong in this article, but I can't help but feel that there's a better link or description of what's meant than a simple Tab. I'm not sure what, mind- possibly a link to a forthcoming Electromechanical Accounting Machine or similar. MarkMLl 21:01, 4 September 2007 (UTC)

DMALGOL

The following text appears at the start of the second paragraph in the DMALGOL section:

DMALGOL has extensive preprocessing, allowing fairly sophisticated programs to be written/executed, just in the preprocessing phase.

To me this seems quite difficult to make sense of. I am not sure, but I might suggest either that the sentence be dropped, or maybe changed to something like;

DMALGOL has sophisticated preprocessing facilities, allowing for the automated generation of highly-tailored programs from common templates by extensive data-driven code modification during the preprocessing phase.

That seems a little wordy, but, if I understand correctly, is somewhat closer to the actual point.

- Jeff 23:09, 4 September 2007 (UTC)

While that text is probably an improvement, it really needs further breaking out. Although the preprocessing was (and is) used extensively in generating the DMSII software (though less today than 30 years ago), it is also available without the DMSII-specific features. For many years, this version of the ALGOL compiler was known as CTPROCALGOL. Today the regular ALGOL compiler is released with the CTPROC features available, so mentioning these only in the DMALGOL section is only correct as an historical comment.

The security issues with DMALGOL have nothing to do with the compile-time processing or (for the most part) the DMSII interface. The biggest security issue is address-equation, which is totally and blatantly insecure. It is significant in optimizing the DMSII routines, but mainly it is used to create procedures in different environments which share identical code -- a logically reasonable thing to do but not possible in plain ALGOL. Probably a secure feature to provide this capability could be devised, but there was never any particular reason. Used under the control of the Burroughs/Unisys software engineers, the insecurity was not an issue.--Paleolith (talk) 08:09, 18 December 2007 (UTC)

---

I have another question about this section - which I have embedded in the section text as a "hidden comment":

DMALGOL is <!-- essentially the DCALGOL [is this correct?] -->a language <!-- further [?] -->extended for compiling [[database system]]s and for generating code from database descriptions.

I can't swear that this is true unconditionally, but I remember being able to use DMALGOL to write MCS code back in the day; however, it is possible that we had created a non-standard DMALGOL compiler (all the ALGOL variants were generated from a common source code with various compile-time options controlling the details). My memory is that DMALGOL implied DCALGOL also, but I might be mistaken.

- Jeff 23:30, 4 September 2007 (UTC)

DMALGOL does not subsume DCALGOL. The main article is correct as it stands. The key capability of the DCALGOL compiler was the ability to code "attach to a primary queue" which when executed made the compiled program a Message Control System (MCS). Being recognised by the MCP as an MCS gave privileges way beyond running under a privileged usercode. CANDE was compiled using DCALGOL. The DCALGOL compiler was often not loaded onto the machine as a security measure. - Shannock9 20:35, 12 November 2007 (UTC)

Actually DMALGOL is a superset of DCALGOL. However, I would not want it described in this way in the article, as that would tend to obscure the differing purposes of the two.--Paleolith (talk) 08:09, 18 December 2007 (UTC)

---

I wrote DCALGOL in 1970, long before DMALGOL existed, and also the first B6500 CANDE. The cited business about timesharing a single stack across multiple users was mine, although having multiple stacks with controllable loads was added later by other hands. DCALGOL was an extension to regular Burroughs Algol, with support for messages and queues. Algol of the day had no "struct" construct with named fields (you used an array and named numeric indexes), and DCALGOL messages were the first implementation of what today would be a struct or object type with pointer links, although extremely ad hoc. —Preceding unsigned comment added by Igodard (talk • contribs) 02:55, 2 September 2008 (UTC)

==

Did no-one notice this little gem, on the end of the description of the SCAMP card?

[um, a what? a PCI card for an "Intel" x86 PC? :)]

Liam Proven (talk) 04:13, 12 April 2008 (UTC)

Unreferenced sections

Whomever wrote the sections about LISP and APL seems tohave some personal information. I cannot find a reference to this.

Unless someone can find a source, I vote that this section be removed:

Thus Burroughs FORTRAN was better than any other implementation of FORTRAN.^{[citation needed]} In fact, Burroughs became known for its superior compilers and implementation of languages, including the object-oriented Simula (a superset of ALGOL), and Iverson, the designer of APL declared that the Burroughs implementation of APL was the best he'd seen.^{[citation needed]} John McCarthy, the language designer of LISP disagreed, since LISP was based on modifiable code^{[citation needed]}, he did not like the unmodifiable code of the B5000^{[citation needed]}, but most LISP implementations would run in an interpretive environment anyway.--Tom (talk) 20:34, 15 August 2008 (UTC)

Tom, I certainly would not argue against removing this section. Of course much of the article appears to be based on memory with inadequate references, but this paragraph is perhaps the worst.--Paleolith (talk) 00:45, 9 September 2008 (UTC)

Agreed. I almost took it out when it first appeared, My own recollections support the Algol claims, but I have no memory to support the FOTRAN claims. -Arch dude (talk) 01:23, 9 September 2008 (UTC)

This sentence frustrates me (Language support section):

"Many wrote ALGOL off, mistakenly believing that high-level languages could not have the same power as assembler, and thus not realizing ALGOL's potential as a systems programming language, an opinion not revised until the development of the C programming language."

as Multics was writen using high-level language Pl/1 8-6 years before appearance of C.

(195.14.165.61 (talk) 15:32, 30 March 2009 (UTC))