Talk:Burroughs large systems descriptors

C compiler?

Is there really a C compiler for the B5000?

The text makes it sound like Pascal came before ALGOL, and that ALGOL improved on the malloc() system used by C.

I am pretty sure that there wasn't a C compiler for the B5500 that I used in 1967.

Gah4 (talk) 09:40, 23 February 2008 (UTC)

The Pascal compiler was in development in ~1983, when I was at Burroughs. I left in 1984. The C compiler was developed after I had left. So we can safely assume the Pascal and C compilers were available for the A-series machines. Not sure if (or which) older machines were supported. pbannister (talk) 19:53, 7 September 2016 (UTC)

Not for the B5000, but there is currently a C compiler developed probably late 1980s for the slice compiler system.

Around 1983, the Pascal compiler might have been the Uni of Tasmania one. Slice did not come until later. I remember seeing the source of the UTas compiler. Ian.joyner (talk) 10:42, 30 September 2024 (UTC)

General accuracy

The text mixes up statements about specific machines (B5000) with bit layouts from later members of the architecture (e.g. 20-bit memory addresses). It also refers to the B5000 bit 47 as the P bit, without explicitly warning that that bit numbering is ambiguous (the B5000 numbered the MSB as 0, not 47).

Apart from that, as noted above, there are minor issues relating to allusions to Pascal, C etc. which could possibly be improved. MarkMLl (talk) 09:12, 9 March 2014 (UTC)

I yanked the whole text about the presence bit out of the B6xxx series and put it at the top of the "Details" section, as it applies to all of the machines, and replaced references to "bit 47" with references to the "p-bit" (the fact that, on some machines, it happens to be bit 47, with some particular bit numbering, is not of general interest; it can be covered by the layouts in the sections below). Guy Harris (talk) 06:05, 29 July 2022 (UTC)

Yes, there was far too much tied to the B5000. I have attempted to make it more contemporary with current Unisys MCP systems. Ian.joyner (talk) 10:44, 30 September 2024 (UTC)

Did you verify that the B000 material you change is valid for the B6500 through clearpath? The B5000 and B6500 are radically different, so the Devil is in the details.

NTW. I reluctantly reverted your tense changes due to MOS:TENSE. I actually prefer your style, but ... -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:41, 30 September 2024 (UTC)

the Burroughs Slice compiler

Few know of it, but they remember it. Searches like Slice Burroughs -"bit-slice" find almost no mention, mixed in with many false hits (many things and people are called "slice"/"slicing" and "Burroughs"). One Quora answer confirms several details in the article (I bolded) and extends it somewhat:

Wait, I'm not finished with Pascal yet. Really wanting an Eiffel compiler in environments I worked in, I set to work on a Burroughs (Unisys MCP) Eiffel compiler. Burroughs had a generalised compiler system called Slice (probably the equivalent of LLVM). This separated out syntax analysis, from semantics to intermediate tree structures of programs, to code generator. Guess what – it was all written in an extended Pascal. Scotsman Matt Miller had written the Pascal compiler and was keen for me to do Eiffel. I started with the C compiler (written by Steve Bartels) and adapted it (C was an interesting beast on the Burroughs machines, Steve made it so it had bounds checks, and we discovered a whole lot of problems in [C] programs we ported from quite large and well-known companies, even today!)

— a Quora answer by Ian Joyner at Macquarie University, 2018-08-18

Searches like this might find some more mentions: Unisys "Slice compiler" - A876 (talk) 20:54, 28 August 2019 (UTC)

"This separated out syntax analysis, from semantics to intermediate tree structures of programs, to code generator." - not just in Slice and LLVM; DEC's GEM compiler system (originally developed for DEC PRISM processor and DEC MICA operating system) had such a split, and the GNU Compiler Collection also works in that fashion (I don't know whether the original GNU C compiler did). In addition, the VAX PL/I compiler's backend, the VAX Code Generator, later was used for DEC's VAX C compiler, although I don't know whether it was originally designed to support multiple front ends.. Slice may have been the first such compiler, or one of the first such compilers, but the idea was used elsewhere long before LLVM. Guy Harris (talk) 06:38, 29 July 2022 (UTC)

I fixed it to no longer mention LLVM. Guy Harris (talk) 03:13, 1 October 2024 (UTC)

I think there could be some confusion here between bit-slice systems and slice compilers. As far as I know there is no connection. I don't know why the compiler system was named 'slice'. Perhaps Matt Miller knows, wherever he is these days. Ian.joyner (talk) 10:47, 30 September 2024 (UTC)

The -"bit-slice" is Google search notion for "...but don't show me anything that mentions bit-slice computers", i.e. "bit-slice" is only mentioned here because the user who did the search didn't want Google to confuse this with bit-slicing.Guy Harris (talk) 03:25, 1 October 2024 (UTC)

References

Other descriptor-base systems?

I added this sentence "However, other systems are not descriptor based and have added virtual memory above the basic processor architecture." at the end of the history section I added, but it might not be entirely correct. Multics may well have had some form of descriptor based on GE systems. I'm fairly certain IBM systems did not have descriptors. Ian.joyner (talk) 09:57, 30 September 2024 (UTC)

Other manufacturers used the term descriptor with different semantics. I don't know whether there are any with the same semantics, but see Capability-based addressing.. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:06, 30 September 2024 (UTC)

Thanks. I did an online and literature review (about 8 books I have on OS and 5 on processor/system architecture) after I wrote that and while the word descriptor is used, it was at best a very watered-down meaning. That in itself could be quite a review topic to address here. (It is rather like the phrase OO has been misused and applied to languages like C++.)

By the way, did you accidentally hit the 'undo' button on my changes to past tense about the B5000? My intent is to show that the B5000 was a long time in the past, but carried through to modern machines which have removed the limitations raised. Using present tense implies that the B5000, even though long gone, is the current state of these machines, which further suggests this whole article is not relevant.

These articles on Burroughs are relevant for three reasons, the first and least is historical interest in Burroughs systems, secondly that the ideas are still mostly current in Unisys Clearpath, and thirdly, that future system architectures should include some kind of descriptor/capability security mechanism, which you are aware of. Ian.joyner (talk) 23:29, 30 September 2024 (UTC)

I reverted to present tense because of MOS:TENSE. I prefer past tense for discontinued machines, but believe that we should not knowingly deviate from the house style. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:24, 1 October 2024 (UTC)

The main thing the text should indicate is that there are two instruction set architectures involved, the B5000/5500/5700 ISA and the B6500-and-successors ISA, the first of which was discontinued and the latter of which persists to the present day (albeit implemented in software on x86-64 processors). Once you do that, the past tense isn't needed when talking about the B5000/5500/5700 machines. Guy Harris (talk) 01:27, 1 October 2024 (UTC)

I tweaked Burroughs large systems descriptors § Integration in memory architecture to mention the B5500 and B5700 as well when talking about the B5000, to indicate that it's a series of machines. I changed the sentence about the B6500 not to say it "extended" it, as that could be read as saying the B6500 was a B5xxx with a larger address size, rather than the first of a completely new line of machines (which has a larger address size, but also a completely different instruction set etc.).

The next sentence is talking about the 20-bit address being insufficient by the mid-70s, and talks about two solutions - the "Swapper", which "implements another layer on top of memory management, moving large clusters of related data in and out of memory at once", and "address space number memory". I'm assuming both of those were done in the B6500-and-successors series; that should be made clear, and more detail should be given for both of them.

After that, it says that "With the advent of the A Series in the early 1980s, the meaning of this field was changed to contain the address of a master descriptor"; it should say what that field is. Guy Harris (talk) 02:55, 1 October 2024 (UTC)

Depends on what you mean by "descriptor".

I don't think any of the GE 600 series, including the 645, or its immediate successors referred to operands through Burroughs-style descriptors that 1) contained bounds information and 2) were protected from user modification; the address space on the GE 645 consisted of a set of segments, each of which had a length, but data within the segment was referred to directly. (I think there was some "new architecture" for later systems - it didn't support Multics - but I don't know whether it was a radical change that added something similar to Burroughs descriptors.)

IBM's System/38 is an... interesting system. All compilers offered to customers, and some internal IBM compilers, produce a very high-level instruction set called "MI", for "Machine Interface", which is, as far as I know, never directly executed. Instead, it is translated to native binary code, in an instruction set called "IMPI".

MI is described in IBM System/38 Functional Reference Manual-Volume 1 and IBM System/38 Functional Conceptsts. Instructions reference objects through an object definition table. One type of object is a "data pointer", which "contains scalar data element attributes and addressability to a location in a space."

IMPI is described in IBM System/38 Internal Microprogramming Instructions Formats and Functions Reference. "Microprogramming" here is a bit of a legal term of art; according to Frank Soltis, one of the architects of System/38, IBM didn't want to have to make the low-level system software for S/38 available to clone makers if they were the subject of an antitrust suit and lost the suit, so they called that software "vertical microcode" and made the group developing it a part of the hardware group, but it's really just native machine code, run out of main memory, and the MI code is executed by translating it to IMPI code (and saving the translation results, so it's ahead-of-time rather than just-in-time) and running that code. The microcode that implements IMPI is called the "horizontal microcode".

IMPI is a fairly conventional architecture, with 16 16-bit GPRs (the lower 16 of those can be treated as pairs of 16 8-bit registers) and 16 32-bit segment identifier registers that are paired with the corresponding GPRs to make 48-bit addresses. Addresses are stored in memory as 64-bit values, containing the 48-bit address and 16 other bits; they are stored in memory inside a region that's tagged as containing addresses, so that they can't be modified by unprivileged code. The addresses are translated to physical addresses via an (inverted) page table, so virtual memory is paged.

AS/400 was a follow-on, with the same MI and, initially, possibly a similar IMPI. IBM then redid it with an extended version of PowerPC, with tag bit support, replacing IMPI; programs for which the original MI was available would just be re-translated into extended PowerPC code. That continues to the IBM Power Systems machines when running IBM i.

I'm not sure to what extended the object definitions serve as something like descriptors, but those definitions are, I think, mainly used at binary-translation time, with bounds and other checks done, as necessary, by the generated code. (Customers can't directly write IMPI or PowerPC/Power ISA code, or compile code to IMPI or PowerPC/Power ISA code.) Guy Harris (talk) 23:06, 30 September 2024 (UTC)

Thanks Guy. I just posted this for Chatul: I did an online and literature review (about 8 books I have on OS and 5 on processor/system architecture) after I wrote that and while the word descriptor is used, it was at best a very watered-down meaning. That in itself could be quite a review topic to address here. (It is rather like the phrase OO has been misused and applied to languages like C++.)

Thus I think most other machines used the word descriptor, but not in the sense of Burroughs descriptors. Perhaps the closest might be the ICL 1900 and 2900 since they were influenced by JK Iliffe who was at the same session as Barton in 1958. His book 'Basic Language Machine' outlines very similar ideas to Barton and Burroughs.

Perhaps that also goes back to Elliott and Ferranti?

For now it is a bit of a loose end as to exactly where descriptors came from and how else they have been used. They certainly should be an idea rediscovered for future system architectures and supporting processors. Ian.joyner (talk) 04:39, 1 October 2024 (UTC)

Sadly, Bitsavers appears to not to have any instruction set reference manual for the 1900 series, but the ICT 1900 series page suggests that it's a fairly standard machine with a base and bounds register. However, according to The ICL 2900 Series, the ICL 2900 series does appear to have descriptors that may be similar, in some ways, to the Burroughs large system descriptors, although the descriptors contain a virtual address and length, with the virtual address being in a segmented address space, with the segment possibly being paged. The Burroughs machines are cited as an influence; the Basic Language Machine was, according to John Iliffe (computer designer) § The Basic Language Machine, considered as an option for the next-generation ICL machines but rejected in favor of what ended up as the 2900 design.

As for Elliott and Ferranti, perhaps people had some of those ideas in mind, but did any of them show up in Elliott or Ferranti products?

Some capability-based machines to check out:

• the Plessey 250;
• the iAPX 432;
• the BiiN processor (a/k/a the original version of the first-generation Intel i960, with the other versions of it omitting various features - I almost said "various capabilities", but that's a bit too snarky :-));
• CHERI;

some of which use the term "descriptor" and some of which don't. Guy Harris (talk) 08:59, 1 October 2024 (UTC)

Notes