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.

Burroughs had an in-house pseudo-assembler for the B5000, called OSIL (Operating Systems Implementation Language), which ran on the Burroughs 220, an earlier vacuum-tube machine. The compiler developers hand-translated their Algol design into OSIL and initially cross-compiled it on the 220. Once they got the OSIL-generated compiler working on the B5000 well enough to compile the Algol source for the compiler, they abandoned the OSIL version.

quoted from http://retro-b5500.blogspot.com/ Peter Flass (talk) 00:06, 11 April 2012 (UTC)

At Victoria University (New Zealand) Chris Barker's Master's thesis concerned modifying the B6700 Algol compiler to accept his design of the syntax for decision tables; this meant we students had access to a compiler and the ability to have a code file declared a "compiler" to the MCP (the operator console command was MC name to "make compiler" the named code file), which meant that it had the authority to declare its code files executable. The compiler was table-driven ("ELBAT" was a key name) and easily extended so Bill Thomas then went through the B6700 hardware description and further added all the mnemonics for the opcodes and their usage so that assembler source statements could be mixed with normal Algol source and refer to items declared in Algol source in a natural way. Access to this was triggered by the new compiler option "set serendipity", so that it would not be stumbled upon. Thus VALC X, where X is an Algol variable, etc. Thereby, all the organisational convenience of a high-level language, with intervals of assembler for special deeds. I recall Chris Barker enthusing over his added code, that started "if if if ..." I also recall the assembler version of the Algol compiler as being described as half the size, and three times the speed of the Algol version of the Algol compiler. However, it was clear that the assembler version was not for the full language, though I don't remember which features were in or out. NickyMcLean (talk) 22:03, 11 April 2012 (UTC)

"we students had access to a compiler and the ability to have a code file declared a "compiler" to the MCP (the operator console command was MC name to "make compiler"" - pretty brave! That just blew all the security on the system. Peter Flass (talk) 23:08, 11 April 2012 (UTC)

Another possibility at the time was to make use of the fact that the interface between a compiler and the MCP was a 30 word array. Arrays were pass-by-name. The privileged bit was stored somewhere in that array. The next step was knowing that the contents of that array (called SHEET?) were written as the first record in the codefile. So if you wrote a program that ran a compiler as a task (PROCESS statement in ALGOL) then all you had to do was setting that bit to 1 in a tight loop while the compiler task was running. Sure enough the resulting codefile was privileged. The compiler itself wrote a 0 to SHEET[8] that is why the loop had to be fairly tight and it was a CPU intensive task. The workaround was to run SYSTEM/BINDER instead with just a single HOST instruction. That went very fast and was light on cpu usage. A nice side effect was that BOUNDCODE actually meant "this is privileged code". This was around MCP Mk 2.9 to 3.1, later on the privilged bit was moved outside the codefile so this trick stopped working." Hans Vlems — Preceding unsigned comment added by 84.246.0.231 (talk) 09:47, 14 August 2013 (UTC)

Too right. But I also ran a "proof of concept" whereby I compiled a prog to do something simple (print "hello"), saved the code file on a B6700 library magnetic tape, wrote a special prog. to read&write mag. tape, ran it on the mag. tape as an ordinary data tape&file to find and modify the text, then used the mag. tape as a library tape to copy the file back to disc, executed the modified prog without trouble, and beheld the altered message. We also discovered the password for the computer operator ("op/7" as I recall) found in a job (deck of cards) left lying about by a Burroughs engineer after a visit and I wrote an Algol prog. "Catspaw" that sent what you typed to the system command handler (just as if from the operator's console) and sent the response to your terminal (a cande session) - with the password, your prog. could switch to a specified usercode (cande of course did this constantly in supporting multiple terminals, and I was assured that therefore, no log was kept of such usercode switches), perpetrate the transaction, and switch back to your normal usercode, thus not drawing suspicion via the display on the system console of active tasks. The operator's usercode of course enabled more interesting commands to be executed. I only ever used it for proper deeds (and likewise my associates...), but I was amused to see that the computer centre staff discovered this prog. and used it to up the priority of their own tasks, etc. On one occasion I saw that they had four catspaws active at once. Thus if any criticism were to arise, there would be a forthright response. The B6700 was such a pleasure to use after IBM that no-one was hostile, also we were not first-year students... It was much more interesting to see just how much good stuff could be done. With our broad access, there was no interest in causing damage. At the larger Auckland university, there was less access (at least, that I knew about), but a student (Laurence Chiu) managed to train the operators into specifying a sequence of commands for his special prog. and for their convenience, his prog. would display the commands on the operator's console "to save you the trouble of typing them", and after a while some special commands could be interpolated into the text displayed... NickyMcLean (talk) 04:58, 12 April 2012 (UTC)

Another way to modify priority was to run an ALGOL program under CANDE that used the PROCESS construct available in that language. PROCESS created a task that ran alongside CANDE and its priority could be modified by the initiating program. The upper limit was CANDE's own priority. This behaviour only worked if CANDE was compiled with a specific compile-time parameter not set. — Preceding unsigned comment added by 171.33.133.147 (talk) 07:46, 22 October 2018 (UTC)

The compilers for the B6700 & B7700 were on-the-fly optimizers. Since they moved constant expressions out of loops, it was impossible to completely control the object code generated, making timing tests difficult. Burroughs software people modified the Algol compiler to allow brief passages in quasi-assembler, calling the result DWAlgol after the DWIW construct which introduced such passages: Do What I Want. This was not an "official program. Source: personal experience while working for Burroughs in the early 1970s.

NEW COMMENT FROM AJR: In my time using the B6700 at U of Otago, NZ, I did not come across DWAlgol, but did hear the (unproven) claim that the standard Burroughs Extended Algol compiler could be persuaded to produce every useful sequence of machine instructions. Perhaps the existence of DWAlgol proves that this was not the case. Surprisingly, as 2nd-year students, we had access to the Program Directory command. Issuing a prank PD *- (a PD of everything in the files system) at one of the terminals would throw the machine into a catatonic state for all users for as long as it took, which IIR could be a minute or two. Having cut my teeth on Elliot Algol, which was completely insulated from machine details, Burroughs Algol's hardware access extensions (such as: bit-field manipulation, pointers, and Scan and Replace) seemed incredibly advanced at the time, and bypassed a lot of the need for an assembler. -AlastairRoxburgh

Floozybackloves (talk) 21:10, 23 November 2017 (UTC)

Note that ESPOL had statements that generated single machine instructions. I suspect that they were used sparingly. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:51, 26 November 2017 (UTC)

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)

Actually, the B5000 family did not have a secure architecture. The B6500 fixed many of the security exposures. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:51, 26 November 2017 (UTC)

In the 1970's, when the DOD sponsored a lot of R&D on secure systems, I was told that the Burroughs large systems were "secure, but not securable." However, Burroughs did get the large system DOD listed as a secure system (I forget what the security level was). A friend of mine led the project, when it was about ready for release he offered a $50.00 reward for anybody who could break the security and modify/delete a file that should have been secure. A programmer in his group figured out a way to remove a log file the next day and got the reward. However, no-one found a way to illegally modify a file. Crmills 200 (talk) 00:04, 13 February 2019 (UTC) Carlton Mills

This document from 1987 has MCP certified as a C2-level system. Guy Harris (talk) 02:22, 13 February 2019 (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.

The B5000 did not have a one-bit tag in all words. It had a one-bit flag in control words and in numeric data, but not in either character data or instruction words. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:37, 5 January 2011 (UTC)

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)

The most significant change from the B5000 to the B5500 were the 3 tag bits. The B6700 had Model 2 and or model 3 processors as opposed to the B6500 which had the model 1 processors. They could be field upgraded, but it wasn't just a name change. Not on the list is the B5900, 1980, e-mode machine, the first 4th generation machine of the Burroughs large systems, more closely related to the A Series machines. All of these computers had 'RAM'. IC memory was tried on the B6700 but the failure rate from all IC manufacturers at the time was to high. B7900 ? 80brzmik (talk) 02:57, 4 January 2011 (UTC) Amended 65.27.125.98 (talk) 23:35, 4 January 2011 (UTC)

The change from a 1-bit flag in some words to a 3-bit tag in all words occurred with the B6500, not the B5500. Also, I'd consider the saguaro stack to be very significant. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:37, 5 January 2011 (UTC)

Please note the line: "After Burroughs became part of Unisys, Unisys continued to develop new machines based on the MCP CMOS ASIC." Unisys is Burroughs. After acquiring Sperry, Burroughs simply changed the name to Unisys. 80brzmik (talk) 04:22, 4 January 2011 (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 "mainframe" 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?	??

Regarding the current dispute in the History section table related to the B6700 entry. I've added some text that may be more relevant to this topic below under "Are x700 new names for old products or names for new products" Pdp11.caps11 09:19, 9 February 2020 (UTC) — Preceding unsigned comment added by Pdp11.caps11 (talk • contribs)

UCSD and Burroughs large machines

UCSD had a series of Burroughs 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)

I agree that this really should not be in an article about Burroughs Large Systems, but rather in an article about Burroughs in general. However, Burroughs was making electronic computers though out the 1950s: Burroughs produced its first electronic computer, the UDEC in 1949, followed by UDEC II and UDEC III produced through 1956. In 1952 Burroughs built the first memory for ENIAC Burroughs produced the E101, the first desk sized computer in 1954. In 1955 Burroughs acquired ElectroData and produced the B205 and B220 including all peripherals in the later 1950s In 1957 Burroughs produced the first large scale 2nd generation computer, the Atlas Guidance computer. In 1959 Burroughs produced the first multi-processing multi-programming computer, the D825. also in 1959 Burroughs introduced a high speed check processing machine the B101. 80brzmik (talk) 02:24, 4 January 2011 (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)

SCAMP card

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)

-) Don't know whether anybody can work it in usefully, but I've just spotted this:

A Unisys micro-A system running MCP, with 2 external SCSI drives and an external tape drive. When it boots, it says it starts running Microsoft Operating System/2 v1.00, after which it starts up the Unisys CPU board and MCP (and the 80386(?) in it does no more than I/O). I have no clue about MCP so it's a bit useless now (but fun :). In 2004, I got e-mail from an David Faultersack, an engineer on the micro-A program, who mailed: 'The system uses a 2.00" x 2.40" Burroughs processor module (11 die inside). When running the Burroughs OS, it is running on the Burroughs processor, with OS2 running I/O communication.'. Unfortunately, when I tried to boot the system in 2005, it blew up. I have kept the micro-A ISA card (which I hope is still working). http://www.belgers.com/walter/computers/ MarkMLl (talk) 10:43, 8 December 2013 (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))

Multics started in 1964. The MCP for the B5000 was written in ALGOL in 1960. What does C have to do with this? -Arch dude (talk) 15:42, 30 March 2009 (UTC)

Presumably they meant "it's not as if there were no systems programming languages between Burroughs' ALGOL dialects and C, because Multics used PL/I before C was created". However, that whole sentence is gone now, so it's moot. Guy Harris (talk) 02:03, 4 July 2011 (UTC)

Reentrant

I would appreciate it if someone familiar with the system elaborated the explanation as to why the system was automatically reentrant. I'm not able to decipher it from figure 4.5 alone.

Also, I tried reading the 1968 SJCC paper (http://doi.acm.org/10.1145/1468075.1468111, or if you don't have access, a scanned version is here: http://www.cs.berkeley.edu/~culler/courses/cs252-s05/papers/burroughs.pdf). Either I am misunderstanding it, or it is using a different definition of reentrant than I learned. It describes how procedures can access variables in a higher lexical level (ie global variables) via Display Registers which point to the relevant MSCWs further down the stack. It also describes how a program can be split into two independent jobs, which will share the part of the stack beneath them. Thus it seems to me that it is possible to write procedures that access global variables, which may be accessed concurrently by the same procedure running in another job, causing reentrance problems.

In that paper the description of why code is inherently reentrant describes code that branches at level 1, and does not share any data, just code. But that is the same as any system - seperate processes are inherently "reentrant" to each other, but coroutines or threads must be specifically written that way. It seems that when it says reentrant, all it really means is that the code is shared in memory between processes.

Pavon (talk) 22:31, 28 October 2010 (UTC)

At the time that article was written, most competing architectures (e.g., CDC 3800, IBM 360) were not stack machines, and the "normal" op-code to execute a subroutine call simply stored the return address inline at the top of the function that was being invoked. Writing re-entrant code on these machines requires a fair amount of extra work, and the resulting extra instructions meant that calling a re-entrant subroutine (or re-entrantly calling a subroutine) was considerably slower than usingthe simple op-code. The Burroughs architecture keeps the entire process context on the stack, including the subroutine calls. This was a radical innovation. Sure, you could still have problems with shared data, but the Burroughs system also had instructions that made it easy to implements locks, which was another innovation. -Arch dude (talk) 10:33, 29 October 2010 (UTC)

That's true for the CDC processors, but not for, e.g., GE, IBM, SDS, UNIVAC. In particular, it's not true for the IBM System/360. For UNIVAC Store Location and Jump is a problem but Load Modifier and Jump is not. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:18, 1 November 2010 (UTC)

Sorry, I was oversimplifying. The "store location and jump" type of instructions are an extreme and obvious way to describe to a younger programmer that support for re-entrant code was not considered important by the hardware designers. The more serious problem was the lack of efficient stack support. I specifically recall that you had to tell the compiler that a particular routine was to be re-entrant, and that the result was less efficient, on the 360. Unless you have a stack (or some other context-preserving mechanism) then your local variables are all in absolute locations, and a subroutine with any "local" variables is non-reentrant. I remember an awful lot of 360 assembler code from the early 1970s that did not separate code space from data space, that used entrypoint-relative addressing for the local variables, and that stored the return pc in a local variable. -Arch dude (talk) 22:25, 1 November 2010 (UTC)

I'd state that as "...not considered important by the assembler-language programmers and compiler/OS developers"; you don't need push and pop instructions, or a call instruction that pushes the return address onto a stack, to have a call stack, as demonstrated by, for example, a number of RISC architectures - and by various compilers on System/3x0. Guy Harris (talk) 07:26, 2 November 2010 (UTC)

It was never true either that local variables are all in absolute locations or that a subroutine with any "local" variables is non-reentrant. Depending on the compiler, there were issues with 'static storage. It's true that the old free compilers on the IBM System/360 used a GETMAIN for each stack frame, but the cost of reentrant code went way down when they started suballocating the storage from a single GETMAIN. Shmuel (Seymour J.) Metz Username:Chatul (talk)

What you're not getting apparently is how the stack machine architecture completely obviates the reentrancy problem which can be viewed as an artefact of the standard von neumann (VN) architecture plus asynchronous interrupts. Simply put, the model of an executing program context which these systems implement factors out reentrancy issuses, different contexts can't reenteer and corrupt each other because it's just not possible the way program contexts and interrupts are integrally processed. That's why I placed the illustration from the ACM Monograph Computer Systems Organization showing wait and event processing. This was developed from the beginning with multiprocessing in mind, a typical Burroughs main frame would have at least 3 different kinds of processors with possible multiple instances of each for general processing, mass storage i/o, and data communications, all programmed in a common environment of Algol dialects, which recall the stack architecture was developed to execute. The reason this happened as I noted is that Burroughs, in order to catch up with its traditional rivals, created a completely new computer architecture to execute the IAL, whereas the others persisted in the VN architecture which for that matter carries the same problem from the earliest days of electronic commercial computing to the present. To be clear, you could, in principle, if you had access to one of the microgrammable mid series machines and created your own operator set to do so, write a whole superstructure of code allowing you to code an example non-reentrant program. This in no way vitiates the original fact that short of such an implausiblity there's no way to create a program which isn't reentrant by virtue of its operation within the architecture (rather than it's subversion at the microcode level). Even if you were coding in the model specific operator lang that only the system compilers emit as object code, let alone any of the high level langs which is what everything was/is programmed in, you still couldn't write a non-reentrant program.

Those high level langs included most of those known before the late eighties, and the current unisys line includes a C compiler/translator. On their current microprocessor version of the Burroughs architecture, it is reasonable to think, near certain in fact, that all C programs compiled with it are reentrant. The only doubt on this last is if I was lied to that the libra series CPUs are a continuation of A and B series and not just some commodity CPU, which is very unlikely. They do run the MCP stack on stock intel iron these days and of course that's a gray case. 72.228.177.92 (talk) 17:41, 3 July 2011 (UTC)

See the lede now has emphasis on model variants/lines in the '70s but the second ¶ still has what I refer to above. Will add more detail in my draft 72.228.177.92 (talk) 19:43, 6 July 2011 (UTC)

Sign above 3 entries in this thread. Lycurgus (talk) 02:55, 11 December 2013 (UTC)

The apparent is often not true, and before assuming that someone is not getting something it is appropriate to ensure that what he is "not getting" is not wrong. In particular, the original Burroughs stack architectures were not bulletproof, due to allowing some dangerous syllables in normal state (See the B5500 Reference Manual), and some non-stack architectures, e.g., Multics, made reentrancy a nobrainer. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:23, 11 December 2013 (UTC)

About the only thing I can see that might be inherently different about the Burroughs architecture is that it might have made it difficult or impossible to refer to "global" data rather than data in your stack frame or caller stack frames. There's nothing about S/360 or its successors, x86, Power ISA, SPARC, PA-RISC, Itanium, ARM, etc., etc. that make it particularly difficult to implement reentrant or even recursive code. Guy Harris (talk) 21:40, 11 December 2013 (UTC)

Well, the B5000 was the first machine that I'm aware of with segmentation, and that did help with controlled sharing of data between processes, but later nonstack machines supporting segmentation, e.g., GE 645 for Multics, were available within a few years. As you noted, even when segmentation is not available or not used, reentrant and recursive code on a reasonable nonstack architecture is relatively simple. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:50, 12 December 2013 (UTC)

ESPOL as assembler

For both the B5x00 and the B6500 series, the ESPOL compiler included statements for generating specific syllables. Given that, claiming that there was no assembler is misleading, although there was certainly no dedicated assembler and it's likely that only a small amount of code used those features. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:22, 1 November 2010 (UTC)

What is an "assembler"? Traditionally these are distinct from compilers in that the latter transforms a high level language to object code whereas the former takes simple descriptions of single instructions and "assembles" them into object code. Both the essential features, merely assembling, and being a translator for an operator source lang are missing in the ESPOL and other similar Algol dialect compliers. 72.228.177.92 (talk) 15:39, 3 July 2011 (UTC)

ESPOL takes simple descriptions of single instructions and "assembles" them into object code. The fact that it also handles higher level language constructs doesn't change that, nor does it mean that the other features are missing. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:04, 20 July 2011 (UTC)

Never used it so, will defer to your experience if you did. 72.228.177.92 (talk) 14:27, 21 July 2011 (UTC)

Burroughs had three families of large systems

The title Burroughs large systems lumps together three very different families

1. B5000 family
   • B5000
   • B5500
   • B5700
2. B6500 family
   • B6500
   • B6700
   • B6800
   • B6900
   • B7500
   • B7700
   • B7800
   • B7900
   • A Series
3. B8500 family, descended from the D825
   • B8300
   • B8500

Of these only the descendants of the B6500 are still on the market. The families are different enough that it is confusing to have them in the same article, and I propose splitting the article. The article George Gray (October 1999). "Burroughs Third-Generation Computers". Unisys History Newsletter. 3 (5). {{cite journal}}: Unknown parameter |separator= ignored (help) provides some context. User:Chatul/References#Burroughs lists some of the relevant manuals from bitsavers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:09, 10 November 2010 (UTC)

This is not without merit and it would be consistent with that for 360/370 and others but I'm against it unless you are willing to put a lot of time into developing the separate articles. If anything, separate Large Systems, Medium and Small Systems, and Unisys Era articles makes the most sense to me, offers the best organization in which good articles could be developed. Some consolidation could then occur into the other two and this one from some other system model based articles e.g. B2000, B1700, etc. IMO the big distinction is between the Large Systems architecture and the Medium which were user microprogrammable although the capability was seldom used. 72.228.177.92 (talk) 21:45, 12 November 2010 (UTC)

Note that while the IBM S/370 was almost the same as the S/360, and most S/360 programs could run unchanged on the S/370, the B6500 not only didn't support the B5000 instruction set, it didn't even have the same syllable size.

There already are separate articles for the B1700 and B2500 families; I'm not sure whether you would call the B1700 small or medium. The only things missing are the really old machines and the machines based on military computers, e.g., B8500. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:49, 13 November 2010 (UTC)

I've moved the unique features section under B5000 and added sections for B6500 and B8500. Right now they are basically stubs, but I'm hoping that someone from Burroughs/Unisys can had historical data and supporting citations. It would be helpful if someone could separate the B5000 material in the rest of the article from the B6500 material, or at least note which is which. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:04, 29 November 2010 (UTC)

One factor to consider is the size of the article; adding material on the B5000 and B8500 would make it significantly larger, and it's already at the threshold. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:35, 17 December 2010 (UTC)

I worked on the B6000 and A Series machines for many years. There is a much simpler way to separate the machines rather than by model numbers, as there are so many models even up until today.

The B5000 and B5500 (B5700) were made at the Pasadena (CA) Plant, manufacturing moved interm to the City of Industry plant (CA) until the new Mission Viejo (CA)plant was ready. The B5900, B6000 and smaller A Series machines (such as MA825, A1,A2,A3,A4,A5,A6,A7,A9,A10) were made there. The B7000, B8000, larger A Series (Such as A12,A15,A17,A19,A21) and the D825 and D830 were made at Tredyffrin (also on a different thread the ILLIAC IV). These were known as the Very Large Scale machines from Tredy. While the machines made at the two facilities ran the same code, they were significantly different.

80brzmik (talk) 03:44, 4 January 2011 (UTC)

The IBM System/360 Model 30 and IBM System/360 Model 65 were internally different even though they ran the same code; however, they're considered part of the same line of computers, the IBM System/360 line. Is there any technical reason (rather than a "Burroughs didn't quite get what IBM was doing with making System/360 a line of compatible computers covering a wide range of price and performance" reason) not to consider the Large Scale B5900/B6000/smaller A-series machines and Very Large Scale B7000/larger A-series machines to be members of a single line of compatible computers? Guy Harris (talk) 05:44, 16 April 2023 (UTC)

Facility locations for B5000, B5500 and B5700

Does anybody have information on where the B5x00 processors were designed and built? If so, it would be a useful addition to the article.

I know that Burroughs had a plant in Detroit, but I have no idea which lines it manufactured. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:12, 25 November 2010 (UTC)

The B5000 and the B5500 were developed and manufactured at the Burroughs Pasadena plant. --80brzmik (talk) 01:49, 4 January 2011 (UTC)

Are x700 new names for old products or names for new products

Burroughs large systems#History lists B5700 and B6700 as new names for the B5500 and B6500, but Gray, George (October 1999). "Burroughs Third-Generation Computers". Unisys History Newsletter. 3 (5). Archived from the original on September 26, 2017. claims otherwise. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:54, 30 November 2010 (UTC)

No, they were incremental developments of previous machines. I had a B6700 for my and the other programmers use in a B6800 shop when I was Systems Programmer there. I'm removing the tag about splitting the article. 72.228.177.92 (talk) 12:30, 6 December 2010 (UTC)

The proposed split wasn't for x500 vs. x700, it was for 5xxx vs. 6xxx vs. 8xxx; I put the tag back. Guy Harris (talk) 19:05, 6 December 2010 (UTC)

1. An incremental enhancement to a design is not a rename
2. If you disagree with a proposed split then discuss the reasons why; unilaterally deleting the template without consensus to do so is simply vandalism. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:39, 6 December 2010 (UTC)

No it isn't vandalism. Perhaps you're not a native speaker of English. Don't dispute that an incremental design is not a rename, never said it was, that was somebody else. A rename is when the very same product, or one with negligible changes, is given a different designation. The progression in question is the normal, ubiquitous one. Also the B6800 reference card is displayed in my user space, you can contrast it with models before and after, as well as the product descriptions, such as can be found. At this point, as far as wiki standards are concerned, I would be guided by what was done with the contemporary IBM system articles, i.e. 360/370. In Burroughs the generational differences (in the Lerge System Group) were between 5, 6, and 7 thousand and then A series. 72.228.177.92 (talk) 23:08, 6 December 2010 (UTC)

"In Burroughs the generational differences (in the Lerge System Group) were between 5, 6, and 7 thousand" means that the 8xxx series should not be treated as a member of the same architectural family as the 5xxx or 6xxx. If the 5xxx instruction set was incompatibly different from the 6xxx instruction set - as I infer is the case - then those shouldn't be lumped together as well. S/360 and successors are different - it's not as if S/370 changed the formats of instructions from, say, having an 8-bit opcode to having a 12-bit opcode. Guy Harris (talk) 23:15, 6 December 2010 (UTC)

There's a previous section where I group the various models by architecture, but the 5000 line had 12-bit syllables, the 6000/7000 line had 8 bit syllables and the 8000 line had 6 bit syllables. The 5000 line had 48-bit words and the others had 51-bit words. Except for the 8000 line the hundreds digit distinguished generations, but did not represent new architectures. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 7 December 2010 (UTC)

Perhaps the moon is made of blue cheese. My native tongue is not relevant to the propriity of removing a {{split}} template instead of stating your opposition in the associated discussion. As for "somebody else", when you post anonymously that doesn't allow for distinguishing you from other posters. Perhaps you are the one who doesn't understand English, because when a procut with negligible changes is given a new name and that new name is not applied to the base product then it is not a rename.

What was done with done with the contemporary IBM system articles is relevant to mostly compatible systems, not to systems with different word lengths, different syllable sizes, different stack organizations and different addressing mechanisms. The 5000 and 6000 lines had a totally different architecture, while the generations within the 5000 line and the generations within the 6000/7000 lines were upward compatible. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 7 December 2010 (UTC)

On the Wikipedia page, History section, Burroughs (1961-1985) table, B6700 entry there is currently a dispute flagged against "new name/bug fix for B6500". Hopefully this is the appropriate area on the Talk page.

I performed hardware maintenance down to component level on a B6700 system for an ex-Burroughs maintenance engineer i.e. I was never Burroughs staff. I had been told existing B6500 systems were simply upgraded/reworked to become B6700 systems.

The B6700 was constructed in units that allowed simple system expansion or layout changes. Basically from base to top a rack consisted of

a)-Fans/blowers with passive components of that modules power supply designed for the unique requirements of Fairchild Complementary Transistor Logic (CTL or CTμL) i.e. +4.5V±10% and -2.0V± 10%. Refer and

b)-Power supply active components.

c)-Multiple card racks which held the Fairchild CTμL, Dual In Line (DIL), Integrated Circuits (ICs) on Printed Circuit Board (PCB) modules that plugged into sockets.

d)-Line drivers for the data cables used to interconnect the racks.

e)-Cabling system for interconnecting CPU, memory, etc. Note this cabling does not include any power supply cables or power interconnects as these are confined to the base of the rack.

The two highest maintenance areas of the B6700 processors (i.e. ignoring the peripherals) were the line driver cards at the top of the racks and the fans/blowers in the base of the racks. Cool air at the base of the rack is preheated by everything below (i.e. powers supplies and the CPU). These cards have the power amplifiers to drive the transmission lines between cabinets. With the inadequate cooling these PCBs changed color as the ICs overheated i.e. basically charred the PCB substrate. While the other high maintenance items were the bearings in the blowers. As they wore there was a daily task of checking/refilling oil reservoirs. Neither of these problem areas which required bug fixes were addressed by the B6500/B6700 transition.

Therefore the rework of B6500 to B6700 is being performed on a modular design and the highest maintenance areas of the processors that needed bug fixes were not addressed.

Short Burroughs History, Loren Wilton. Burroughs (Unisys), January 2004, includes

"Rewinding to the early 1960s, there needed to be a followon machine to the B5500. This was to be the B6500, which became the B6700 by the time it was released and workable."

"The B6500 was physically quite large, and was expensive. It did ALGOL very well, Cobol poorly, and unfortunately FORTRAN very poorly compared to a 7090. A great deal of effort went into FORTRAN compiler redesign to correct this, and vector math operators were added to the machine, creating the B6700."

While states when discussing the B6500

"Like the B5000, had reliability problems and quickly replaced with the B6700. All were field upgraded to B6700"

"All B6500s were field upgraded to B6700 to correct engineering problems with the B6500."

These references bring together the two main threads of rename or bug fix when talking about the B6500/B6700 transition. There are other references noting the introduction of vector maths operators with the B6700. Burroughs upgraded every B6500 into a B6700 to introduce the vector maths operators, in effect an extension to the instruction set. This system upgrade which addressed performance problems, could also be viewed as a bug fix.

In effect the manufacture has ceased production of an item, issued a recall, destroyed all the original items and provided an upgraded item as a replacement to all existing clients. The upgraded item in this case is distinguished by name and higher performance (addition of vector maths operators).

Is it appropriate to replace the disputed "new name/bug fix for B6500" text with "performance upgraded B6500" or similar text to remove the dispute flag?

Pdp11.caps11 08:00, 9 February 2020 (UTC)

B5000/B5500/B5700:

The George Gray reference says that the B5500 was built with faster circuitry and added some decimal arithmetic instructions, so it's far from a rename, but says little about the B5700.

This Burroughs document says (transcribed from UPPER CASE on a line printer and modernized with lower-case letters):

In 1970, Burroughs announced the availability of certain additional hardware for the B5500, such as extended core memory and a data communications processor. Newly installed B5500 systems with these features are called B5700 systems. Subsequent to the B5700 announcement, some new Burroughs publications and several revisions to older manuals used the term B5700 in their titles. At the present time, all software and programmer reference manuals with either B5500 or B5700 in their titles are pertinent.

which suggests that the B5700 was just a B5500 shipped with some additional hardware. Then again, that document also says:

... In 1965, the hardware configuration was expanded. The most significant change was the replacement of auxiliary drum storage with disk storage. A revised software operating system, called the Disk File Master Control Program (DFMCP), was supplied to utilize the new storage medium. Batch processing was still the only mode of access. At this time, Burroughs changed the name of the system from the B5000 to the B5500.

which contradicts what George Gray says:

It was just one year after the first B5000 customer delivery that IBM announced the System/360, and four months later (August 1964) Burroughs responded with its announceme nt of the B5500. Even though it was not his product, Irven Travis, director of the Defense, Space, and Special Systems group (otherwise known as the Great Valley Laboratories) near Paoli in suburban Philadelphia had been very impressed with the potential of the B5000 and convinced Burroughs Corporation president Ray Macdonald to authorize work on an improved version. The circuitry of the B5500 was three times faster than that of the B5000, and this increase in speed, coupled with the use of disks in place of drums, made the B5500 a success for the company. To improve the performance of COBOL programs, the B5500 added hardware instructions for addition and subtraction of decimal fields. Burroughs also adjusted to the reality of the marketplace and provided a FORTRAN compiler for the B5500.

which indicates a bit more of a significant change, with faster circuitry and decimal arithmetic instructions, so the Burroughs documentation doesn't indicate for certain that the B5700 is a new name for B5500 systems with certain additional features provided at installation time.

References

There is no flag bit in B5000 code or character words

The B5000 has a 48-bit word. Code words have 4 12-bit syllables and character words have 8 6-bit characters, with no bits left over for a flag bit. The flag bit only exists in control words, e.g., descriptors, and in numeric words. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:27, 16 December 2010 (UTC)

Has? You know of a functioning B5000 someplace? Also, why would there be (as opposed to being in the operational/executing state of live code in a machine) since that would violate the whole spirit and value of the architecture (i.e. IAL and other source code independence from the underlying machine). 72.228.177.92 (talk) 17:35, 19 December 2010 (UTC)

The point is that the article makes the claim, not that the claim is true. I wanted to discuss that here prior to removing the claim from the article.

As for violating the spirit of the architecture, the designers saw nothing wrong with having tags for code when they designed the B6500. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:11, 19 December 2010 (UTC)

As it stands now, this thread says in code, not for code. 72.228.177.92 (talk) 23:33, 19 December 2010 (UTC)

Regardless of how you word it, the claim a bit in each word was set aside to identify the word as a code or data word is wrong. A word containing code on the B5000 did not contain a flag bit. In contrast, a word on the B65000 containing code did contain a 3-bit tag. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:20, 20 December 2010 (UTC)

On the b6700, every 48-bit word (of data) in memory had 51 bits (and another for parity) - the three bits were used as tags, and some 3-bit value was for code (thus, execute-only and no write), and others meant data (read/write) and so forth. There was a special op-code STAG for set tag. This applied to the extra bits, whereas normal read/writes of memory were for the 48 data bits, however the tags were inspected by the hardware to ensure propriety. From the user's code a word had 48 bits, but the hardware dealt with more, just as with the normally silent checking of parity. NickyMcLean (talk) 21:38, 29 January 2012 (UTC)

Algol example and "value" parameters.

Looking again at the Algol example in How programs map to the stack I note a puzzling lack of semicolons, but more seriously, with regard to value parameters being read-only, I demur. The idea was presented to me in the context of a function that might find it convenient to mess with its parameters, and that in such a case it would be undesirable for the original parameter to be modified, thus, the function would be supplied a copy of the original parameter's value (perhaps via a stack) and it could do what it wished with the copy. In this view, it would be natural for a compiler to refrain from criticising any such modification in the subroutine (either with a warning or an error), and they should not be blamed for this. I'm not familiar with the details of the Algol language specification. Only if it explicitly disallows modification of parameters declared to be passed by value would it be proper to decry compilers failing to enforce that restriction. But in such a case, given that I have written such functions (ahem), I would be inconvenienced. In that sense "read-only" really means "don't write back" and I suppose a different word should be used to avoid the implication of no-change.

Actually, my main use of misbehaving functions is to have a function that reports success/failure with results supplied via parameters, as in While ReadAcard(in,text) do Process(text); This is much more convenient that messing about with disconnected notions such as EoF(in) or various end-of-file catchers. Actually, B6700 Algol had many statements also return true/false so that they could be tested in if-statements and the like, so the statement would be While Read(in) text do Process(text); except that, annoyingly, a successful read returned false and vice-versa so I would use Algol's "define" protocol to define ican to be not, so the loop became While ican Read(in) text do Process(text); This notion of returning a result in a function-like manner is sadly underused and clunkiness results. Contemplating such other languages in an Algolish way, how about if (ptr:=Allocate(stuff)) <= null then Croak("Oh dear!" + BadPtr(ptr));, supposing a failed allocation returns a bad pointer value (non-positive) whose numerical value indicates which sort of problem, for which routine BadPtr will provide explanatory text. And it is beyond me why a Free(ptr); doesn't also clear its parameter. Passed by value, huh? NickyMcLean (talk) 22:02, 19 August 2012 (UTC)

I concur that B5000 and successor Algol compilers treat scalar parameters passed by value as read-write locals, initialised at entry. If my memory serves, array (descriptor) parameters were always passed by name [not by reference as stated in the example] using a copy descriptor. A parameter such as a[i] passed by name would be implemented as a PCW to an anonymous procedure (or thunk) in case the value of i changed. I don't understand your reference to Free(ptr) - was there such a Burroughs Algol intrinsic? Shannock9 (talk) 15:12, 21 August 2012 (UTC)

This appears to be a case where Burroghs deviated from the ALGOL 60 report. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:13, 21 August 2012 (UTC)

My reference to Free(ptr) was with regard to "other languages" (such as C etc.) In the Algol style, explicit allocation and deallocation was rare, for instance, the resize array facility handled most cases not already handled by declaring arrays of some calculated size on procedure entry or in a Begin ... end; block; with this scheme, deallocation is handled automatically. I don't recall any discussion of the "resize" statement returning a value that was testable (it being less trouble to presume that there was always more (virtual) memory available), but it presumably was similar to the read and write statements that did. I have no recollection of ever needing or wanting something like C's malloc, however I didn't mess much with Algol. However, I do recall arrays being passed by reference as a part of a description of why they should not be passed by value, and the default behaviour (for arrays and simple variables) was by reference. By name was mentioned as another option to explicitly stating by value, but very seldom used except for playing games with odd ideas such as Jensen's Device. I recall amazement being expressed over a computer centre employee's question as to whether with Ackermann's function, passing by name would make a difference to execution speed compared to pass by value. Perhaps he was being sarcastic? Anyway, I'm suggesting that the criticism of the compiler should be removed, though the warning could remain. NickyMcLean (talk) 21:38, 21 August 2012 (UTC)

Not sure where the 'criticism of the compiler' is to be found. I read "...it most likely indicates an error." to be a deprecation of the coding style :) Obviously this code is here to make a point, but the author didn't want anyone to think this style was a good idea. Certainly it's fragile, since changing the parameter from value to name would break the code. In 1969 I worked alongside the B6500 compiler writers and their managers were the (ex) B5000 compiler writers. The whole ethos was to strictly implement the ALGOL60 distinction between call by value (no side-effects) and call by name (guaranteed side-effects) - and thus pass the Man or Boy test. Also, even that long ago we provided multithreading available to the user programmer. This led to several "bug" reports being answered with "it works as you coded it" :) :) Shannock9 (talk) 10:28, 22 August 2012 (UTC)

Ah, phrasing. I was seeing the criticism in "Few of Algol's successors have corrected this ... most have not", and not directed at the B.Algol which was well-regarded as with its other compilers. I recall coding test progs. to ascertain whether parameters were passed by value, copy-in, copy out (and if so, in what order: left-to-right or vice-versa, or stack push-pop), and pass by reference, but alas, I don't recall the results for B.Algol and only vaguely for B.Fortran (questions can arise if a parameter is passed twice in the same call) so that's not much help. I did most of my number crunching in fortran, and in Algol it was clear that large arrays must not be passed by value. However, if passed by name instead of reference (i.e. address given) there would be a performance difference, though mitigated by the B. hardware. Alas, I don't recall any machine code printouts of code examples that might clarify this for B.Algol. Such probes were often difficult: I recall wondering about the exact evaluation order of certain expressions (possibily minimising stack usage) and prepared some examples intending to view the code. It was merely "exit"! Since no input was read, constant values could be carried forward; since no variables had their value printed (I didn't want to wade through massive "print" code blobs), no assignments to those variables need be made nor therefore calculated. Result: nothing to do! I was most impressed! And by contrast, I look at the code from current compilers, and wonder how the mass works - the actions I had specified are lost in gibberish, and excruciatingly inane waste.

Code always expands to fill .GE. 110% of the resources available. Shannock9 (talk) 22:52, 22 August 2012 (UTC)

I do recall discussion of Man-or-Boy and the like, and came to the following view on syntax: within a function called B, references to B were to the variable B (that will be returned as the function result), not invocations of the function, as in B:=B + h*sin(theta); etc, (as allowed by Fortran, which then did not allow a function to not have parameters) whereas if a function invocation were actually desired, then it would be B(). This is the obvious situation where function B has parameters, but when the function has no parameters (as in Man-or-Boy) there is ambiguity.

With regard to the example prog. and in the absence of a ruling from the Algol60 specification, perhaps a rephrasing of "- Since this..." to "- Changing the value of a passed-by-value parameter such as p1 may be a mistake. Some compilers regard such parameters as "read-only" and will prevent this." Though really, I have always regarded a by-value parameter as being one that the subprogram is free to mess with! NickyMcLean (talk) 22:15, 22 August 2012 (UTC)

Me too. And it saves one or more stack frames. I edited the article along the lines you suggested Shannock9 (talk) 22:52, 22 August 2012 (UTC)

B5000 tag bits

I am fairly sure all the ALGOL machines had the tag bits. I thank they all 3 bits. But I know that ALGOL would not of worked with out them. Call by name was implemented iart in hardware by the tag bits --Steamerandy (talk) 01:56, 30 September 2014 (UTC)

The "Operational Characteristics Of the Processors For The B5000" manual doesn't seem to say anything about tag bits, just a single "flag" bit that is 0 for data words and 1 for descriptors or "array boundary" words. I think call-by-name was implemented by having an argument to a procedure be a program descriptor rather than an operand or data descriptor.

Not that ALGOL 60 required any descriptors or tag bits at all; call-by-name could be implemented using thunks, for example. Guy Harris (talk) 08:30, 30 September 2014 (UTC)

To clarify, there are no tag fields for character, numeric or instruction words. However, control words and descriptors do have tag bits.

Contrast this to the B6500, where every word has a tag field in addition to the basic 48 bits.

As for call by name, a simple array or scalar reference should not require a thunk, but any expression more complicated than that, an array element with a variable subscript, presumably would require a thunk; I suspect that the compiler did not distinguish the two cases. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:49, 15 October 2014 (UTC)

In principle it did not matter that the B5500 words containing instructions were not protected by flag bits, because those words could only be accessed via a descriptor [base and limit], which was so protected. However as noted elsewhere a stream procedure could get around this, so something had to be done. From the B6500 onward stream procedures were replaced by normal state opcodes working on "string" descriptors, which plugged the hole once, AND the code was tagged, which plugged it twice and was probably easier to "sell" - you can't generate the address and if you could it wouldn't work..

Once the tag bits were there, the cases you mention for call by name were implemented as follows. A scalar parameter requiring mere indirection -> a local Indirect Reference Word (tag 1) pointing to the uplevel object. An array parameter (the whole array) -> a local [unindexed] Copy Descriptor (tag=5). An array parameter indexed by a constant -> a local Indexed Copy Descriptor (also tag=5). Anything more complicated needed a thunk -> Program Control Word (tag=7) causing "accidental entry" to the thunk code. Enthusiasts may note that odd values of the tag field mean "protected", with tag=3 used for control words and code. Shannock9 (talk) 03:36, 4 April 2015 (UTC)

Doesn't seem neutral

This whole article seems to do nothing but praise the Burroughs systems. It seems unbalanced to me. — Preceding unsigned comment added by Richardthiebaud (talk • contribs) 12:44, 10 June 2015 (UTC)

Agreed 100%. The technical detail is light, but the praise is heavy. It seems more like an ode to the Burroughs than a proper description. And as much as I admire Donald Knuth, the quoted portion below sounds more like a part of a pitch for a TV show than an objective description of the machine and its history:

However, a bright young student named Donald Knuth had previously implemented ALGOL 58 on an earlier Burroughs machine during the three months of his summer break, and he was peripherally involved in the B5000 design as a consultant. 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.

That's seriously not NPOV. --Mr z (talk) 11:18, 9 February 2020 (UTC)

I disagree. While there is certainly too much fluff, the article still has a good deal of technical information. From my perspective what it needs are

• Put things in context, e.g., Algol 60 was not the first HLL used as an implementation language.
• Disentangle the B5000, B6500 and B8500 lines.
• Expand the history
• Kill or cut back on the superlatives. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:27, 9 February 2020 (UTC)

Waychoff document

I've added a second link for this, to a scanned copy held by the CHM donated by Donald Knuth [3]. The title page is annotated "HALF TRUE" in handwriting similar to Knuth's as found at [4] (look at the capital U among others).

Unfortunately there isn't visible annotation in the body of the document, so it's not immediately possible to say whether the problems are in the description of Knuth's work on the ALGOL compiler, or in the description of the politics at Stanford (in particular, McCarthy's feelings about the B5000). I note from elsewhere that the Stanford B5000 was upgraded to a B5500, and that this was apparently transferred to SRI (i.e. was no longer strictly at the university).

I don't know the provenance of Knuth's copy of the document, but the format of the handwritten date suggests that it might have come via the UK, and there was a Burroughs FE of that name in the appropriate timeframe. MarkMLl (talk) 09:07, 6 August 2015 (UTC)

searching for B6700 software to preserve the legacy of this Burroughs Large System

One of the best ways of preserving the technical details of these machines is via emulation. High quality emulators exist for the B5500 series, and work has commenced on the same for the B6700, but we're struggling to find software, particularly the Mark II.x releases. If anyone could help please let us know. Software needed is MCP+Intrinsics, ESPOL, ALGOL, DCALGOL and the supporting utilities. Mark III.x release was a significant revamp where the standalone DCALGOL and DMALGOL were rolled back into the main ALGOL compiler, and NEWP replaced ESPOL. — Preceding unsigned comment added by Nigwil (talk • contribs) 02:28, 21 August 2015‎ (UTC)

Good location for Relative Addressing table?

I've crated some text and a supporting table for relative addressing on the B5000, B5500 and B5700, but am not certain of the best place to put it within the existing article structure, which is really oriented to the B6500 et al. Ideas?

The B5000, B5500 and B5700 in Word Mode has two different addressing modes, depending on whether it is executing a main program (SALF off) or a subroutine (SALF on). For a main program, the T field of an Operand Call or Descriptor Call syllable is relative to the Program Reference Table (PRT). For subroutines, the type of addressing is dependent on the high three bits of T and on the Mark Stack FlipFlop (MSFF), as shown in B5x00 Relative Addressing

B5x00 Relative Addressing

SALF	T0 A38	T1 A39	T2 A40	MSFF	Base	Contents	Index Sign	Index Bits	Max Index
OFF	-	-	-	-	R	Address of PRT	+	T 0-9 A 38-47	1023
ON	OFF	-	-	-	R	Address of PRT	+	T 1-9 A 39-47	511
ON	ON	OFF	-	OFF	F	Address of last RCW or MSCW on stack	+	T 2-9 A 40-47	255
ON	ON	OFF	-	ON	(R+7)	F register from MSCW at PRT+7	+	T 2-9 A 40-47	255
ON	ON	ON	OFF	-	C	Address of current instruction word	+	T 3-9 A 41-47	127
ON	ON	ON	ON	OFF	F	Address of last RCW or MSCW on stack	-	T 3-9 A 41-47	127
ON	ON	ON	ON	ON	(R+7)	F register from MSCW at PRT+7	-	T 3-9 A 41-47	127
Notes:

Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:43, 19 February 2016 (UTC)

Removed notices

I've removed two identical notices that have been there forever, but belong to the talk page. The first one preceded Unique system design and the second was in the History section. I'm reproducing the notice here:

— Preceding unsigned comment added by Isanae (talk • contribs) 01:38, 22 February 2016‎

The {{Notice}} tage may or may not belong on the talk page (it certainly seems to be significant information for which a more specific template doesn't exist) but the article needs text to warn that the article has general text that does not apply to the B5000 and B8500 series. Note that Template:Notice explicitly permits {{Notice}} on an article page.

Also, please sign your edits to the talk page.Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:32, 22 February 2016 (UTC)

One thing the notice says is "and should be edited someday to keep clear the distinctions between the 5000/5500/5700 and 6500 et seq, and A Series."; if somebody were to do that, the notices could be removed, and the debate about their appropriateness in an article would be mooted. Guy Harris (talk) 19:32, 22 February 2016 (UTC)

{{Notice}} is part of the notice and warning templates category, which "is for talk page templates, not article templates". Information like "this should be edited because..." is meant for editors, not readers, and therefore belongs on the talk page. At worst, {{misleading}} could be used instead. Isa (talk) 20:59, 22 February 2016 (UTC)

Then either 1) it's in the wrong category or 2) its documentation needs to be edited to remove the "Articles" section, so that the category and the documentation are mutually consistent. Guy Harris (talk) 21:57, 22 February 2016 (UTC)

Misleading discussion of ALGOL

The article says that "most of the industry dismissed ALGOL as unimplementable". That strikes me as quite dubious in light of the fact that the first operational ALGOL compiler appeared in 1961, not long after the language was defined (Dijkstra and Zonneveld, Amsterdam, on the Electrologica X1 in 4k words). I have never seen "unimplementable" attached to ALGOL 60. Perhaps to ALGOL 68, but that is an entirely different language.

As for I/O statements, the ALGOL specification did not define those (no more than the C standard does!). But of course all implementations defined them, minimally by adding a number of builtin procedures along with a "string" data type, as Dijkstra and Zonneveld did.

And on "most other vendors could only dream..." not true either. A lot of companies implemented ALGOL 60: CDC (6000 mainframes -- and they did ALGOL 68 as well, in fact), DEC (PDP-10, PDP-8, PDP-11); IBM 360, Univac, etc. Paul Koning (talk) 16:57, 3 May 2016 (UTC)

"Most other vendors could only dream..." -- and yet it is stated that Burroughs based their dialect on Elliot Algol, which was available on the 803B, and later the 903, essentially a 16-bit minicomputer with 8K words of store. I suspect I never met a British computer that *didn't* have an Algol 60 compiler. — Preceding unsigned comment added by 173.76.121.238 (talk) 22:03, 15 May 2021 (UTC)

"most other vendors could only dream..." finally provoked a sufficiently emetic response that I just removed the dubious and un-cited claims written in un-encyclopedic and non-NPOV language. Guy Harris (talk) 01:25, 16 May 2021 (UTC)

Well, call-by-name parameters were initially an issue, but not after publication of Ingerman, P. Z. (1961), "Thunks: A Way of Compiling Procedure Statements with Some Comments on Procedure Declarations", Communications of the ACM, 4 (1), doi:10.1145/366062.366084. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:00, 3 May 2016 (UTC)

(Well, to be fair, the C standard does specify I/O functions - C has no I/O statements to specify, it does its I/O through function calls, but a "hosted implementation" of standard C is required to provide the I/O functions. So the difference between C and ALGOL here is that the C standard does define the builtin procedures for I/O. There was an IFIP report proposing I/O function, as well as a proposal from the ACM programming languages community, but that may have been a case of closing the barn door after the horses had bolted.)

Yes, it's not as if you need a Burroughs mainframe-style instruction set to implement ALGOL. The X1 compiler does appear to have implemented a subset of ALGOL 60:

We have however at one point not remained true to this principle. The declaration own cannot be applied unrestrictedly: it cannot be used during recursive use of a procedure and for array declarations the use of own dynamic upper and lower bounds for the indices is excluded ...

and at least some other implementations don't implement all of ALGOL 60, but whether any implementations were significantly limited by being implemented atop a "conventional" processor is another matter (in the extreme case, just about any processor can implement a simulator of a Burroughs large systems architecture, so obviously it's not a complete limitation; the question is how much of ALGOL 60 can be implemented by compiling to conventional machine code). Guy Harris (talk) 19:45, 3 May 2016 (UTC)

Obviously others implemented ALGOL compilers, but how much were they used? How much legacy ALGOL code is there from those systems? At that time, speed was fairly important. People would use Fortran not for the convenience (over languages like ALGOL), but because it was fast enough. How fast was (and is) code generated by the OS/360 ALGOL compiler, compared to the OS/360 Fortran compilers? Gah4 (talk) 18:19, 17 September 2018 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Burroughs large systems. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070926212659/http://www.unisys.com/products/mainframes/mcp__mainframes/earlier__mcp__models.htm to http://www.unisys.com/products/mainframes/mcp__mainframes/earlier__mcp__models.htm

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:35, 11 November 2016 (UTC)

Works, but I changed it to use {{cite web}}. Guy Harris (talk) 04:40, 11 November 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Burroughs large systems. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20060615025259/http://www.colorforth.com/HOPL.html to http://www.colorforth.com/HOPL.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:59, 27 July 2017 (UTC)

Problems with article and redirect structure

As the Burroughs large systems articles now stand, there is confusion between two very different lines. Despite the 2006 claim by User:Arch dude, the instruction set of the B5000, B5500 and B57000 is not remotely similar to that of the B6500, B7500 and successors. The article Burroughs large systems descriptors describes only the B5x00 descriptors in detail. There are several inappropriate redirects, e.g., from B5000 Instruction Set to Burroughs B6x00-7x00 instruction set. I could simply delete the bad redir3ects, but I'm hoping that someone can fill in the missing material. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:07, 30 August 2017 (UTC)

The article says inspired. I suspect it depends on how you do the comparison. The B5000 and B6700 are likely more similar than either is to IBM/360 or DEC/VAX, on the scale of instruction set similarity. On the other hand, it would be nice to have detailed descriptions of each instruction set, good enough to write an emulator. Certainly that isn't the case with the redirect mentioned. Gah4 (talk) 19:03, 17 September 2018 (UTC)

I think "good enough to write an emulator" is overkill; Bitsavers has the documents you'd use for that. Guy Harris (talk) 19:18, 17 September 2018 (UTC)

I suppose. But which details do you omit? If the description here isn't good enough, and given the title it really shouldn't be, then how much detail should go into more specific articles? Enough for assembly programmers? How about enough for someone to figure out disassembled code? (That is, not enough to write assembler, but having already written assembler to figure out what the instructions do). Gah4 (talk) 20:10, 17 September 2018 (UTC)

If you want to figure out what the B5500 instructions do, here's where you go. Do we really need to describe all 90 or so word-mode syllables and operators and all 50 or so character-mode operators? Guy Harris (talk) 20:59, 17 September 2018 (UTC)

Article needs to be split

This article tries to cover too much ground, and as a result is very long, and hard to follow. These are very important and influential machines (especially the early ones, such as the B5000), and deserve articles of their own. Noel (talk) 13:03, 4 October 2018 (UTC)

Agreed, but it should be okay to keep the B5000, B5500 and B5700 in a single article and to keep the B6x00 and B7x00 in a single article. I don't now how much the subsequent Unisys line differs from those.

The same applies to Burroughs large systems descriptors, along with the issue of whether to include, e.g., IRB, SIRB. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:12, 4 October 2018 (UTC)

Category tag?

A recent edit by user:Peter Flass added [[Category:48-bit computers|Burroughs B5000]]. The article covers all three (B5000, B6500, B8500) lines, so the tag appears inappropriate. Should it not be [[Category:48-bit computers|Burroughs B5000, B6500 and B8500]], or simply [[Category:48-bit computers]]? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:55, 22 August 2019 (UTC)

Clarification of {{dubious}} tag added by user:Yuriz

@Yuriz:To what does the {{dubious}} tag added by user:Yuriz to The Burroughs large systems implement an ALGOL-derived stack architecture, unlike linear architectures such as PDP-11, Motorola M68k, and Itanium or segmented architectures such as x86 and Texas Instruments. (This refers to the layout of the memory and how a program uses it.) refer? Does the paragraph need rewording to make it clearer? To what does X86 refer? Should the text read "PDP-11 without MMU. Motorola 68000 without MMU"? To what does Texas Instruments refer?

The facts that the paragraph should express are:

• The B5000 has a stack architecture inspired by Algol, and allows local variables and arguments to reside in the stack
• The B5000 has a segmented but not paged memory model; so does the Intel 80286
• The B5000 provides for arrays with separate segments, addressed through descriptors

— Preceding unsigned comment added by Chatul (talk • contribs) 19:29, 28 July 2020 (UTC)

"The B5000 has a stack architecture inspired by Algol, and allows local variables and arguments to reside in the stack" "Stack" can either refer to an expression stack or to a call/return stack.

If it refers here to an expression stack, it is a stack architecture in that sense, but that's not what "linear" and "segmented" appear to be referring to.

If it refers here to a call/return stack, most instruction sets "[allow] local variables and arguments to reside [on a] stack". Guy Harris (talk) 20:17, 28 July 2020 (UTC)

In this case it refers to both. The B5000 stack holds intermediate values of expressions, subroutine linkage and parameters, local variables and local control words. In a main program Operand Call and Descriptor Call can only address locations in the Program Reference Table (PRT); in a subroutine they can also address words relative to marked locations in the stack. There's a summary of the addressing in Burroughs large systems#Unique system design. Arithmetic and logical instructions pop operands from the stack and return push their results back on the stack.

In most architectures there is no stack, although software can use a register as a top of stack register. Arithmetic and logical instructions must refer to operands with register references or storage references. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:59, 28 July 2020 (UTC)

OK, so:

1. it's a stack machine, i.e, it has an expression stack (an early example - I'm not sure if it's the first example - but not unique);
2. the procedure call instructions use a call stack (again, not unique, and even without instructions that explicitly use a call stack, you can still implement a call stack - you can probably even do so, in a single-tasking OS, on a machine where the procedure call instruction dumps the return address in the first word of the subroutine, such as an IBM 1130 - no reentrancy, but you can get recursion);
3. the expression stack for a subroutine is at the top of the call stack frame (a characteristic possibly shared with other stack machines);
4. operands aren't addressed by a simple combination of zero or more register values and a constant (whether the register values include a segment number or not) - they can only be found in the PRT, the call stack, or in a location referred to by a descriptor in one of those locations.

The fourth of those is the only part that I consider significant; the others are only interesting to the extent that the B5000 was the first machine to have them or one of the earliest machines to have them. Guy Harris (talk) 04:28, 29 July 2020 (UTC)

Yes, it was the first to be stack based, and that is significant. Yes, later machines such as the English Electric KDF9 were also stack based, and the paragraph should note that.

Yes, you can implement a control stack on other machines, but in the B5000 there was no mechanism to call a procedure or take an interrupt that was not stack based.

The segmented memory model was a first, and that is significant. IMHO that belongs in a separate paragraph.

The use of zero operand operations that took the top of stack as input is to some extent part of being a stack oriented design, although I can imagine a machine that has instructions to, e.g., add a literal to the top of stack.

I can split the paragraph up and reword it, but I'd really like to know which part of it user:Yuriz disputes and why, so that I can address his issues in the rewrite. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:11, 29 July 2020 (UTC)

Texas Instruments is the name of the company. Why the name of the company is there in the first place? All other wikilinks in this paragraph refer to technologies, not company names. --Yuriz (talk) 13:52, 29 July 2020 (UTC)

Presumably the original editor had a particular product in mind. Thanks for clarifying that.

I've expanded the mention of the stack to indicate its use for both control and expressions, and am removing most of the paragraph as not being relevant to ALGOL. I probably should add references to later machines using stacks and segmentation, but am not sure where the best place to put them is. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:09, 29 July 2020 (UTC)

Notes

Please review new B5000 text

I've started describing details of the B5000 line in Burroughs large systems descriptors#B5000, B5500 and B5700 and in B5000 Instruction Set. I would appreciate anybody willing to review, correct or expand the material.

Once I've covered the B5000 descriptors, I also plan to add material to Burroughs large systems descriptors#B6500, B7500 and successors.

Should I include control words, e.g., MSCW, RCW, in the article and rename it? Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:47, 3 August 2020 (UTC)

Update needed?

The article says "The B6500[7] (delivery in 1969[8][9]) and B7500 were the first computers in the only line of Burroughs systems to survive to the present day." This sounds like something written a long time ago. Does it need to be fixed/updated? Also, it isn't always going to be the present day. Bubba73 ^{You talkin' to me?} 00:17, 29 March 2022 (UTC)

I presume what they mean is that Unisys no longer offer any descendants of the Burroughs Small Systems or Burroughs Medium Systems machine and no longer offer any descendants of the B5000 or B8500 large systems machines, and, as far as I know, offer no hardware or software support for those older machines, but they do offer support for machines capable of running software for the B6500's descendants (even if that's done these days with binary-to-binary translation on Xeon x86-64 processors and either emulating the hardware as part of that process, and running a translated MCP, or mapping MCP services to whatever OS - one or both of Linux or Windows, I suspect - is running on the underlying hardware).

So I'm not sure what update is needed. Perhaps it should note that Unisys isn't building any hardware that directly executes B6500-and-successors machine code, but that, at minimum, application code should pretty much Just Work; I don't know what level of OS customizations supported by MCP, but they probably have to continue to support that as well. Guy Harris (talk) 08:57, 29 March 2022 (UTC)

Syllables in B5000, B5500, and B6500

In this edit, a comment

On the B5000 there are 4 types of syllables, only one of which has an opcode, and on the B6500 an instruction may have multiple syllables. instruction syllable is a redirect to opcode.

was changed to

On the B5000 there are 3 types of syllables, only one of which has an opcode, on the B5500 an instruction has 2 types of syllables which appear very similar although may be different and on the B6500 an instruction has 4 syllables, however the instruction is not clear. instruction syllable is a redirect to opcode.

The Burroughs B5500 Information Processing Systems Reference Manual] says, on pages 5-1, that "...syllables are packed four to a core memory word (12 bits for each program syllable)." and, on page 5-2, that "In word mode, syllables are grouped into four categories: Descriptor Call, Operand Call, Literal Call, and Operator syllables."

It also indicates that:

• In all syllables, bits 10 and 11 contain the syllable category; presumably neither version of the comment considers those bits to be part of an opcode.
• The Literal Call (LITC) syllable uses bits 0-9 to contain "the integer value", the Operator syllable uses those bits "for determining the type of the operator syllable", and the Operand Call (OPDC) and Descriptor Call (DESC) syllables use those bits "to contain the index for relative addressing and to indicate the base address of the area which will be referenced", so presumably the Operator syllable is the only one with an opcode, the opcode being "the type of the operator syllable".

That seems to match what the original comment was saying.

However, that only describes word mode syllables. B5500 instruction processing is modal - the machine can either be in "word mode" or "character mode", and, in character mode, instructions are also made from 12-bit syllables, in which the lower 6 bits contain what appears to be an opcode.

The Operational Characteristics of the Processors for the Burroughs B 5000 says, on page 5-1 through 5-2, that:

• syllables are 12 bits long
• the processor has two modes, "word mode" and "character mode";
• the lower 2 bits indicate the syllable type for word mode syllables;
• the types are Operator, Literal, Operand Call, and Descriptor Call;
• the upper 10 bits of a Literal syllable are an immediate operand;
• the upper 10 bits of an Operand Call or Descriptor Call syllable are used as an index relative to contents of the R register;
• the upper 10 bits of an Operator are used to, among other things, indicate the operation;

and says, on page 5-9, that character mode syllables have an "operator code" in the lower 6 bits, which sounds very similar to the description of the B5500 syllables; I suspect that the two encode syllables the same way, unless there are, for example, some extensions in the B5500.

So I'm not seeing any indication that the B5000 and B5500 differ significantly here; I'm guessing that the B5500 is binary-compatible with the B5000.

As for the B6500, the Burroughs 6500 Information Processing Systems Reference Manual says, on page 6-1, that

A machine language program is a string of syllables that are normally executed sequentially. Each word in memory contains six 8-bit syllables.

On pages 6-2 through 6-3, it says that

Operations are grouped into 3 classes: Name call, Value Call, and operators. The two high-order bits (bits 7 and 6) determine whether a syllable begins a Value Call, Name Call, or operator (figure 6-3).

and figure 6-3 indicates that:

• Value Call operations contain 2 syllables, with the first syllable's upper 2 bits being 00;
• Name Call operations contain 2 syllables, with the first syllable's upper 2 bits being 01;
• operators contain 1 through 12 syllables, with the first syllable's upper bit being 1 and the value of the next bit, apparently, being 0 or 1.

On page 6-4, it says that the operator can either be word operators or string operators, so it sounds as if there's no notion of word mode or character mode, with the operator itself indicating whether it's a word or string operator.

This sounds not at all like what the comment says after the edit in question.

I'm reverting the comment change (and will see whether anything in this article or other Large System articles say anything about instruction formats). Future discussion should take place here. Guy Harris (talk) 07:12, 2 August 2022 (UTC)

B5000, B5500 and B5700 all have 12-bit syllables. As you noted, the formats are different in word mode and character mode. There is no tag. The cited text for Operand Call and Descriptor Call is oversimplified; the ten bit relative address in subroutine mode is more complicated.

B590, B6x00, B7x00, etc., have 16-bit syllables; there is a tag. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:56, 3 August 2022 (UTC)

References

Header for B6500, B7500

@Guy Harris: A recent edit changed a section header from B6500 and B7500 to B65000; I believe that the B7500 was announced concurrently with the B6500 and thus was not a successor. If that is correct then B7500 should be included in the header. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:00, 16 April 2023 (UTC)

I tried finding some stuff about the 7500 online, but didn't find anything indicating the dates when the 6500 and 7500 were either announced or introduced. Apparently there was a Burroughs B6500/B7500 Information Processing Systems Characteristics Manual dated 1967.

George Gray's "Burroughs Third-Generation Computers" doesn't mention the 7500, although it does mention both the B6700 and B7700, saying of the B7700 that "The 6500 and 6700 had been designed and produced in California, but now the east coast group also became involved.", mentioning the 7700 in the next paragraph. Was the 7500 announced, but never released? Was it delayed enough that it was contemporary with the 6700, so they decided to renumber it (and possibly add features added in the 6700)? Gray and Ronald Q. Smith's book Unisys Computers: An Introductory History, ISBN 9781257134090 (available in hardcover from lulu.com, although Wikipedia won't let me link there, and in bits from Apple), has a chapter "Burroughs Third-Generation Computers" that appears to be based on his article and some other sources, including Jack Allweiss' site; it has a diagram of the "Family Tree of Burroughs Computers 1962-1982" that shows no B7500, just a 7700 branching off from the B6500, along with a B6700 descended from the B6500, both with dates of 1971.

Allweiss's B5900 story mentions no B7500, just a B7700, on pages such as "The Soul of the new Machines" and "Evolution of Burroughs Stack Architecture – Mainframe Computers".

For now, given all that, I'll change the section header to "B6500, B6700/B7700, and successors" for now. Further information on the history of those systems would be interesting for several reasons:

• What was the rationale for a new large-scale descriptor-based/tagged-architecture stack machine incompatible with the B5xxx series? Binary compatibility either 1) not being recognized by Burroughs as being as important as it was to IBM or 2) being considered less important as everything was written in (somewhat) machine-independent higher-level languages?
• What was the history of the B7{5,7}00? Did they start out with the idea of two independent-but-binary-compatible (with the possible exception of some lower-level machine details that matter only to lower levels of the MCP) machines with different prices and performance levels, running the same OS and compilers, those being the B6500 and B7500? If so, was a B7500 ever released? If not, was it delayed enough that the B6700 was due to come out, and renumbered B7700 (and updated to support added features such as vector mode)? I assume it wasn't started after the B6500 came out, given the B6500/B7500 manual mentioned above; I suspect it was either dropped or was delayed and turned into the B7700.
• What were the instruction set differences between the machines, and what was the history of "E-mode"? Did it originate with the B5900 and, in the process of the B5900 design, get used in the design of machines earlier in the pipeline but not yet released, or was the B5900 the first machine released with that version of the ISA?
• What was the history all of those machines, up to the last Unisys machines that implemented the ISA in hardware/firmware rather than in a binary-to-binary translator generating 64-bit x86 code (I've seen stuff about Unisys doing that for the 1100/2200 machines, with LLVM as the back end for the translator, and suspect something similar was done for the Burroughs stack machines)? Guy Harris (talk) 08:10, 16 April 2023 (UTC)

Bitsavers has a reprint of Burroughs' B6500/7500 Stack Mechanism from AFIPS Conference Proceedings Volume 32, 1968, which uses the term B6500/B7500 to refer to both machines.

I believe that the incompatibility between the B5000 line and the B6500/B7500 line is because Burroughs identified deficiencies in the B5000 that they attempted to correct with a total redesign of the architecture -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:34, 17 April 2023 (UTC)

Was that paper written and published before the 6500/7500 came out, under the assumption that they'd be released at the same time? If so, did the B7500 come out? Guy Harris (talk) 18:41, 17 April 2023 (UTC)

I found this in one of the existing references. So announced but not shipped. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:35, 18 April 2023 (UTC)

References