This is the
talk page for discussing improvements to the
Burroughs Large Systems article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
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)
quoted from http://retro-b5500.blogspot.com/ Peter Flass ( talk) 00:06, 11 April 2012 (UTC)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.
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)
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)
"...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)
This is a good article, but it needs some improvement.
- 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)
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
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)
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(?) [1] | |
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) [2] | |
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 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)
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 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)
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)
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)
I wrote DCALGOL in 1970, long before DMALGOL existed, and also the first B6500 CANDE. The cited business about timesharing a single stack across multiple users was mine, although having multiple stacks with controllable loads was added later by other hands. DCALGOL was an extension to regular Burroughs Algol, with support for messages and queues. Algol of the day had no "struct" construct with named fields (you used an array and named numeric indexes), and DCALGOL messages were the first implementation of what today would be a struct or object type with pointer links, although extremely ad hoc. —Preceding unsigned comment added by Igodard ( talk • contribs) 02:55, 2 September 2008 (UTC)
Did no-one notice this little gem, on the end of the description of the SCAMP card?
[um, a what? a PCI card for an "Intel" x86 PC? :)]
Liam Proven ( talk) 04:13, 12 April 2008 (UTC)
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)
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:
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)
This sentence frustrates me (Language support section):
( 195.14.165.61 ( talk) 15:32, 30 March 2009 (UTC))
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)
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)
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)
The title Burroughs large systems lumps together three very different families
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)
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)
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)
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.
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
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)
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 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)
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)
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)
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.
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)
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)
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
SALF [a] | T0 A38 [b] |
T1 A39 [b] |
T2 A40 [b] |
MSFF [c] | Base | Contents | Index Sign | Index Bits [b] |
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 [d] or MSCW [e] on stack | + | T 2-9 A 40-47 |
255 | |
ON | ON | OFF | - | ON | (R+7) [f] | F register from MSCW [e] at PRT+7 | + | T 2-9 A 40-47 |
255 | |
ON | ON | ON | OFF | - | C [g] | Address of current instruction word | + | T 3-9 A 41-47 |
127 | |
ON | ON | ON | ON | OFF | F | Address of last RCW [d] or MSCW [e] on stack | - | T 3-9 A 41-47 |
127 | |
ON | ON | ON | ON | ON | (R+7) [f] | F register from MSCW [e] at PRT+7 | - | T 3-9 A 41-47 |
127 | |
Notes:
Cite error: A
list-defined reference named "A" is not used in the content (see the
help page). |
{{
cite book}}
: Cite has empty unknown parameter: |sectionurl=
(
help); Missing pipe in: |ref=
(
help)
Shmuel (Seymour J.) Metz Username:Chatul ( talk) 20:43, 19 February 2016 (UTC)
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:
![]() | In the following discussion, the machine designations, B5000, A Series, and ClearPath/MCP are used interchangeably although this needlessly conflates the features and concepts of the various machines and should be edited someday to keep clear the distinctions between the 5000/5500/5700 and 6500 et seq, and A Series. |
— Preceding unsigned comment added by Isanae ( talk • contribs) 01:38, 22 February 2016
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)
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 ...
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:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 03:35, 11 November 2016 (UTC)
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:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 19:59, 27 July 2017 (UTC)
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)
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)
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)
@
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.
dubious –
discuss (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
[a] does X86 refer? Should the text read "PDP-11 without MMU. Motorola 68000 without MMU"? To what
[b] does Texas Instruments refer?
The facts that the paragraph should express are:
— Preceding unsigned comment added by Chatul ( talk • contribs) 19:29, 28 July 2020 (UTC)
Notes
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)
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)
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:
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:
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:
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)
References
@ 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)
Burroughs' B6500/7500 Stack Mechanismfrom AFIPS Conference Proceedings Volume 32, 1968, which uses the term
B6500/B7500to refer to both machines.
References
Because of problems that Burroughs,in common with other manufacturers, experienced with its larger machines, the B 7500, B 8300, B 85OO were, either not delivered or not operational at customer locations, and the B 6500 was delivered late. ... In 1967 Burroughs announced the B 7500. Burroughs reported that its release "stimulated interest in other EDP products and strengthened the Company's position in this highly competitive field". (DX 10263, p. 11.) However, the B 7500 was never delivered. (PX 5048-0 (DX 14506), Pierce, p. 62.)Alt URL
This is the
talk page for discussing improvements to the
Burroughs Large Systems article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
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)
quoted from http://retro-b5500.blogspot.com/ Peter Flass ( talk) 00:06, 11 April 2012 (UTC)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.
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)
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)
"...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)
This is a good article, but it needs some improvement.
- 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)
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
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)
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(?) [1] | |
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) [2] | |
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 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)
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 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)
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)
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)
I wrote DCALGOL in 1970, long before DMALGOL existed, and also the first B6500 CANDE. The cited business about timesharing a single stack across multiple users was mine, although having multiple stacks with controllable loads was added later by other hands. DCALGOL was an extension to regular Burroughs Algol, with support for messages and queues. Algol of the day had no "struct" construct with named fields (you used an array and named numeric indexes), and DCALGOL messages were the first implementation of what today would be a struct or object type with pointer links, although extremely ad hoc. —Preceding unsigned comment added by Igodard ( talk • contribs) 02:55, 2 September 2008 (UTC)
Did no-one notice this little gem, on the end of the description of the SCAMP card?
[um, a what? a PCI card for an "Intel" x86 PC? :)]
Liam Proven ( talk) 04:13, 12 April 2008 (UTC)
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)
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:
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)
This sentence frustrates me (Language support section):
( 195.14.165.61 ( talk) 15:32, 30 March 2009 (UTC))
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)
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)
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)
The title Burroughs large systems lumps together three very different families
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)
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)
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)
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.
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
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)
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 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)
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)
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)
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.
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)
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)
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
SALF [a] | T0 A38 [b] |
T1 A39 [b] |
T2 A40 [b] |
MSFF [c] | Base | Contents | Index Sign | Index Bits [b] |
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 [d] or MSCW [e] on stack | + | T 2-9 A 40-47 |
255 | |
ON | ON | OFF | - | ON | (R+7) [f] | F register from MSCW [e] at PRT+7 | + | T 2-9 A 40-47 |
255 | |
ON | ON | ON | OFF | - | C [g] | Address of current instruction word | + | T 3-9 A 41-47 |
127 | |
ON | ON | ON | ON | OFF | F | Address of last RCW [d] or MSCW [e] on stack | - | T 3-9 A 41-47 |
127 | |
ON | ON | ON | ON | ON | (R+7) [f] | F register from MSCW [e] at PRT+7 | - | T 3-9 A 41-47 |
127 | |
Notes:
Cite error: A
list-defined reference named "A" is not used in the content (see the
help page). |
{{
cite book}}
: Cite has empty unknown parameter: |sectionurl=
(
help); Missing pipe in: |ref=
(
help)
Shmuel (Seymour J.) Metz Username:Chatul ( talk) 20:43, 19 February 2016 (UTC)
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:
![]() | In the following discussion, the machine designations, B5000, A Series, and ClearPath/MCP are used interchangeably although this needlessly conflates the features and concepts of the various machines and should be edited someday to keep clear the distinctions between the 5000/5500/5700 and 6500 et seq, and A Series. |
— Preceding unsigned comment added by Isanae ( talk • contribs) 01:38, 22 February 2016
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)
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 ...
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:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 03:35, 11 November 2016 (UTC)
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:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 19:59, 27 July 2017 (UTC)
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)
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)
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)
@
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.
dubious –
discuss (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
[a] does X86 refer? Should the text read "PDP-11 without MMU. Motorola 68000 without MMU"? To what
[b] does Texas Instruments refer?
The facts that the paragraph should express are:
— Preceding unsigned comment added by Chatul ( talk • contribs) 19:29, 28 July 2020 (UTC)
Notes
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)
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)
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:
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:
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:
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)
References
@ 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)
Burroughs' B6500/7500 Stack Mechanismfrom AFIPS Conference Proceedings Volume 32, 1968, which uses the term
B6500/B7500to refer to both machines.
References
Because of problems that Burroughs,in common with other manufacturers, experienced with its larger machines, the B 7500, B 8300, B 85OO were, either not delivered or not operational at customer locations, and the B 6500 was delivered late. ... In 1967 Burroughs announced the B 7500. Burroughs reported that its release "stimulated interest in other EDP products and strengthened the Company's position in this highly competitive field". (DX 10263, p. 11.) However, the B 7500 was never delivered. (PX 5048-0 (DX 14506), Pierce, p. 62.)Alt URL