Talk:Burroughs Large Systems

message: "...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)
replies: text: 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)
replies: text: 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)
replies: text: This document from 1987 has MCP certified as a C2-level system. Guy Harris (talk) 02:22, 13 February 2019 (UTC)
thread_title: it is a secure architecture?

message: 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)
replies: text: 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)
thread_title:   Please help with this "History" Table 

message: 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)
replies: text: 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)
thread_title:  UCSD and Burroughs large machines 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Early competitors 

message: 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)
replies: text: -) 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)
thread_title:  SCAMP card 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: Sign above 3 entries in this thread. Lycurgus (talk) 02:55, 11 December 2013 (UTC)

text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Reentrant 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: Never used it so, will defer to your experience if you did. 72.228.177.92 (talk) 14:27, 21 July 2011 (UTC)
thread_title:  ESPOL as assembler 

message: 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)
thread_title:  Facility locations for B5000, B5500 and B5700 

message: I've added a second link for this, to a scanned copy held by the CHM donated by Donald Knuth . The title page is annotated "HALF TRUE" in handwriting similar to Knuth's as found at  (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)
thread_title:  Waychoff document 

message: 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 AddressingTaken from 
SALF  	T0A38 	T1A39 	T2A40 	MSFF  	Base  	Contents                            	Index Sign	IndexBits   	MaxIndex	
OFF   	-     	-     	-     	-     	R     	Address of PRT                      	+         	T 0-9A 38-47	1023    	
ON    	OFF   	-     	-     	-     	R     	Address of PRT                      	+         	T 1-9A 39-47	511     	
ON    	ON    	OFF   	-     	OFF   	F     	Address of last RCW or MSCW on stack	+         	T 2-9A 40-47	255     	
ON    	ON    	OFF   	-     	ON    	(R+7) 	F register from MSCW at PRT+7       	+         	T 2-9A 40-47	255     	
ON    	ON    	ON    	OFF   	-     	C     	Address of current instruction word 	+         	T 3-9A 41-47	127     	
ON    	ON    	ON    	ON    	OFF   	F     	Address of last RCW or MSCW on stack	-         	T 3-9A 41-47	127     	
ON    	ON    	ON    	ON    	ON    	(R+7) 	F register from MSCW at PRT+7       	-         	T 3-9A 41-47	127     	
Notes:	Notes:	Notes:	Notes:	Notes:	Notes:	Notes:                              	Notes:    	Notes:      	Notes:  	Notes:
Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:43, 19 February 2016 (UTC)
thread_title:  Good location for Relative Addressing table? 

message: 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  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  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)
replies: text: 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)
replies: text:  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,  could be used instead. Isa (talk) 20:59, 22 February 2016 (UTC)
replies: text: 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)
thread_title:  Removed notices 

message: Hello fellow Wikipedians,
I have just modified  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 ).
Cheers.—InternetArchiveBot (Report bug) 03:35, 11 November 2016 (UTC)
replies: text: Works, but I changed it to use . Guy Harris (talk) 04:40, 11 November 2016 (UTC)
thread_title:  External links modified 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 19:59, 27 July 2017 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Problems with  article and redirect structure 

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

message: 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)
thread_title:  Please review new B5000 text