Contents

Comment 1Edit

I'm worried about this page and a few others (one that I revised already) that 216.237.32.xxx has entered in today. They are suspiciously too good and comprehensive. I'm sure they are copied from somewhere, but I couldn't find them with a search engine. -- ansible

I'm -very- flattered. However, it's just me. Ray Van De Walker,

and I have assented to GPL my writing in the Wikipedia. If you really like it, add it to the "good writing" link! (Something which I think would be unethical for me to do as author.)

Computer architecture typesEdit

Should this article mention things like the von Neumann and Harvard architectures, both of which have articles?

Yes. This article needs considerable work. --Robert Merkel 13:38, 17 Sep 2004 (UTC)

Configurable computingEdit

I yanked a whole section on configurable computing. It's an interesting idea, but it's a fairly minor part of computer architecture and makes the article less readable for a non-expert. This whole article needs a rewrite. --Robert Merkel 13:38, 17 Sep 2004 (UTC)

I do not agree with the remove. The section can either be improved or titled in a way that it is recognized as not beeing escential for understanding the current style - however the outlook is important for those that are prepared to work themself inot it. By the way the rest is not for nonexperts either! Togo 02:41, 20 Sep 2004 (UTC)
You're missing my point. I am stating that a whole paragraph on configurable computing, in the context of the article as it stands, gave a very misleading view of the importance of the topic to the broader field of computer architecture. As to the reading level of the article, it *should*, at least in its introduction, be accessible to the nonexpert. --Robert Merkel 04:05, 20 Sep 2004 (UTC)
I agree with the removal. At most this page should have a brief mention and link to Reconfigurable computing. --Brouhaha 21:47, 23 Jan 2005 (UTC)

subarchitectureEdit

Should there be, somewhere in Wikipedia, discussion of subarchitecture? Right now, I am thinking of it in the context of Sun4, Sun4c, Sun4m, Sun4u, but many architectures over the years have subarchitectures worth noting. In the Sun4 case, as well as I know, it is mostly differences in MMU design, and so important for the OS, much less for users, but still should go somewhere. Gah4 (talk) 19:48, 10 June 2019 (UTC)

The Sun architectures were system architectures. Sun-1 was 68000-based, with a Sun MMU; Sun-1U/Sun-2 were 68010-based, with a Sun MMU; Sun-3 was 68020-based, with a Sun MMU; Sun-3x was 68030-based, with the on-chip MMU; Sun-4 was based on various SPARC processors, with a Sun MMU and a VMEbus (as earlier Suns did); Sun-4c was based on an LSI Logic SPARC processor, with a Sun-style MMU (as I remember) and an SBus; Sun-4e had the same CPU and MMU, but a VMEbus; Sun-4m was based either on SuperSPARC or hyperSPARC processors, with the on-chip in-memory page-table based Sun Reference MMU, and using the MBus for multi-processor systems; Sun-4d was similar, but used the XDBus for multi-processor systems; etc..
So the differences affected the ISA in some cases (68010 -> 68020, SPARC v7 -> v8 -> v9), affected the MMU in some cases (Sun MMU -> on-chip MMUs of various sorts), and affected only system buses in other cases (VME -> SBus, MBus -> XDBus).
Different Sun subarchitectures fall into different subcategories in Computer architecture#Subcategories:
  • some involve the ISA even if you don't include the MMU (68010 -> 68020, SPARC v7 -> v8 -> v9);
  • some involve the ISA if you include the MMU;
  • some involve only system design (Sun-4m -> Sun-4d, which both used SuperSPARC);
and they may involve microarchitecture if one subarchitecture uses one set of CPUs/MMU designs and another uses a non-overlapping set, but some subarchitectures used multiple CPUs with different microarchitectures.
So I'm not sure where this would fit. Guy Harris (talk) 21:22, 10 June 2019 (UTC)
Seems like two choices are an article of its own, or a section in this article. Gah4 (talk) 23:21, 10 June 2019 (UTC)
Computer architecture seems largely to be talking about CPU architecture. It gives two meanings of "computer architecture". For the first meaning, it speaks of "describing the capabilities and programming model of a computer", and, for the second meaning, it speaks of "instruction set architecture design, microarchitecture design, logic design, and implementation". Both of those sound CPU-centric; they don't mention, for example, I/O buses, which are at least part of the Sun-4 subarchitectures (VMEbus vs. SBus vs. various flavors of PCI for peripherals, MBus vs. XDBus vs. whatever for multiprocessor systems).
If we were to include I/O buses as part of the System/360 architecture, the architecture would be specified by at least two documents - the Principles of Operation and IBM System/360 I/O Interface Channel to Control Unit Original Equipment Manufacturers' Information plus whatever additional internal specifications they have. In that case, perhaps Bus and Tag vs. ESCON vs. FICON could be thought of as distinguishing subarchitectures of S/370, just as the I/O bus is one item distinguishing Sun-4 from Sun-4c from Sun-4e.
In addition, most if not all commodity microprocessors have, at the CPU architecture level, very little in the way of initialization specified - typically, when the CPU is reset, it clears a bunch of CPU state, including MMU state, and jumps to a given location in physical memory. The rest is up to whatever's at that location, which would typically be some firmware in non-volatile memory. There may be system architectural specifications, either explicit or implicit, that govern the behavior of the firmware.
For x86 processors, one such specification is "compatibility with the original PC BIOS plus whatever other stuff has been added on in various specifications such as Advanced Power Management, the MultiProcessor Specification, Plug and Play, and the Advanced Configuration and Power Interface". Another is the EFI specification, possibly with other industry specifications.
For SPARC processors, Sun had their original boot firmware; I don't remember whether any specification was ever published for it. They replaced that with Open Firmware; I'm not sure whether Oracle are still using that on SPARC servers or if they've adopted EFI.
For Alpha processors, the way the standard firmware worked that was originally documented only in manuals only available inside DEC (DEC Semiconductor offered their own documented firmware to customers of Alpha chips). Eventually it was documented; some functions performed by hardware on some other processors, such as page-table walks, were implemented as traps to the PALcode part of firmware on Alpha.
For MIPS processors, there was at one point the Advanced RISC Computing specification.
So there are CPU architecture specifications and system architecture specifications, with some system details relegated to the latter. Most user-mode programming only depends on the CPU architecture; OS development, and peripheral development, depends on the latter as well.
So would subarchitecture specifications would be system architecture specifications based on higher-level CPU architecture, and perhaps partial system architecture, specifications, where the subarchitecture specification standardizes some aspects of the system not covered by the higher-level specifications? And would a given subarchitecture include all machines designed to conform to that subarchitecture's specification? If so, are there examples other than the ones for SPARC-based systems (and Sun's 68k-based systems)? Guy Harris (talk) 01:15, 12 June 2019 (UTC)
I hadn't thought about I/O bus, but in the Sun case that comes when the initializing OS tries to find out which I/O devices are attached. There are sysgen options, including which device drivers to include in the kernel. Having actually done Sun sysgens some years ago, I am not so sure that is related to what Sun calls subarchitecture. For example, within the same subarchitecture, there are systems based on VME bus, and ones that are Sbus. Even more, because we used to use systems that did it, there was an Sbus to VME adapter, to connect VME devices to Sbus hosts. As I remember, the differences come in the /usr/kvm directory, which has symbolic links from the appropriate /usr/bin or /usr/sbin directory. In the case of diskless hosts, you NFS mount the /usr and appropriate /usr/kvm from the server. One server can serve more than one subarchitecture, or even more than one architecture. (Years ago, I had a 4/110 running off a 3/260 NFS server.) I am not against including I/O systems in subarchitecture, but I believe it mostly doesn't apply to Suns. For IBM, there is XA/370 and then ESA/370, which, in addition to 31 bit addressing, have a completely different I/O system. There are some system that can IMPL different microcode to run S/370, XA/370 or ESA/390. RISC-V has many optional parts, though I don't know that anyone describes them as subarchitectures. I don't know ARM well at all, but it might be that it has some. Gah4 (talk) 03:48, 12 June 2019 (UTC)
Yes, I already mentioned the I/O buses; as I indicated in my initial reply, one of the differences between Sun-4 and Sun-4c was the I/O bus (VME for Sun-4, SBus for Sun-4c) and the one difference between Sun-4c and Sun-4e was the I/O bus (VME for Sun-4e - we used it at Auspex as a host processor, so it could work with our other VME boards). So I'm absolutely certain that the I/O bus is one of the components that distinguishes SPARC-based subarchitectures. Others include, as I noted, the MMU (which was not specified as part of SPARC v7 or SPARC v8, and only semi-specified in SPARC v9, although Oracle SPARC Architecture 2015 does specify it), the firmware (Sun-4c introduced OpenBOOT/Open Firmware), and bit-width (Sun-4u introduced 64-bit processors).
So that particular notion of "subarchitectures" might be Sun-specific, meaning it can be handled on the Sun-3 and Sun-4 pages. Guy Harris (talk) 04:28, 12 June 2019 (UTC)
The reason for the question was that I wanted to link to a description of subarchitecture from the Sun pages, assuming that it wasn't just Sun. For Sun, you needed appropriate install tapes, though the differences were small in some cases. Knowing about subarchitecture saved disk space on servers for diskless hosts, as you didn't have to duplicate the parts that were not different. For OS X, each version will say which machines it works with, and which it doesn't. Those differences are most likely subarchitecture, but not specifically mentioned. Disks are big enough now, that we don't notice the wasted space, having to support more than one. I suspect that the difference show up when you try to boot off a disk that was meant for a different system. But maybe also the IA32 MMU hasn't changed over the years. Install systems figure out if they are installing 32 bit or 64 bit, which probably qualifies as a whole architecture, and don't need to know about subarchitechture. Gah4 (talk) 18:54, 12 June 2019 (UTC)

───────────────────────── For Sun-3 and Sun-4, the subarchitectures required different kernels and may have required different versions of some platform-dependent system commands and libraries. The bulk of userland code didn't care.

For Macs, the only things that might qualify as "subarchitectures" would be based on the CPU type, e.g. 32-bit PowerPC, 64-bit PowerPC, 32-bit x86, 64-bit x86, and maybe the rumored 64-bit ARM in the future, but those have different instruction set architectures, so I don't see them as "subarchitectures". A given OS release includes all the code necessary to support the Macs it supports, with instruction-set differences handled by fat binaries with executable code for multiple ISAs. Apple eventually drops support for older machines, so they don't bother to include in a release drivers for peripherals that only appear in no-longer-supported machines, and they may compile with the compiler set to generate code using instruction set features that are in currently-supported machines but not in no-longer-supported machines, but it's not as if the dropped machines have a different subarchitecture from the supported machines; I didn't work in the low-level platform group, but I don't think there was any notion of "subarchitectures" at all similar to Sun's, just a notion of particular platform families and platforms within them, e.g. the machine on which I'm typing this is a MacBookPro11,5, with the family being "MacBookPro".

The only major changes to the IA-32 MMU was the addition of the Physical Address Extension (PAE) feature and of the NX bit. Apple never supported 32-bit machines that lacked PAE; if they ever supported machines without the NX bit, that would have been handled at runtime (in the pmap layer), so there weren't any separate kernels for no-NX and NX machines. Guy Harris (talk) 19:56, 12 June 2019 (UTC)

I don't have a running Sun, but I do have a running NFS server with export files for diskless Suns. Looking in /export/exec/sun3/kvm, the main general user commands are ps, pstat, and w. These need to look into some kernel specific data structures, it seems enough that they are different for different subarchitecture. Also, config, eeprom, and format, but those are not normally for general use. Using subarchitecture allows only the parts that have that dependence to be different. /usr/bin/ps is then a symbolic link to /usr/kvm/ps. Looking at an OS X system, there is /bin/ps. On the other hand, looking in /usr/bin there are some files specifying x86-64, some i386, and some dual architecture. It seems that they don't install completely different file sets for 32 bit and 64 bit installs. Gah4 (talk) 21:23, 12 June 2019 (UTC)
ps, pstat, and w might look at HAT layer ("MMU driver", similar to the Mach pmap layer I mentioned) data structures, which would differ between Sun-3 (Sun MMU) and Sun-3x (on-chip PMMU), and between Sun-4 (as I remember, 8KB-page Sun MMU), Sun-4c/Sun-4e (as I remember, 4KB-page Sun MMU), and Sun-4m/Sun-4d (SPARC Reference MMU); it's been a while.
On macOS, however, ps uses sysctls that should hide whatever per-platform dependencies exist and 2) there aren't, as far as I know, any such dependencies in any case. Whether a binary is fat or not, and how fat it is, might depend on the build process for that particular program; there's no reason to ship fat binaries in recent versions of macOS, as they only run on 64-bit x86 Macs, but maybe nobody got around to changing the build rules for those particular programs. That probably changes in Catalina, as fat libraries aren't going to be shipped, because support for 32-bit applications is being dropped. Guy Harris (talk) 21:55, 12 June 2019 (UTC)
So, one of the reasons to use Sun style subarchitecture is to save disk space, and also keep the kernel small. Both more important in the Sun days than now. Otherwise, I believe that changes to the user-mode instruction set, that aren't a whole new architecture, would qualify as subarchitectures. Back to S/360 days, there was the commercial instruction set (decimal), scientific instruction set (floating point), which were each optional on some models. IBM ESA/390 and System/z have, over the years, added instructions. Users (and compiler writers) have to then decide when to support the new ones. The IBM term for this seems to be ARCHLVL, I suspect for for Architectural Level. These are changes to the user mode instruction set. Gah4 (talk) 21:50, 12 June 2019 (UTC)
So there's "subarchitectures" in the sense of system architecture differences that don't affect normal user-mode code (Sun-3 vs. Sun-3x, Sun-4 vs. Sun-4c vs. Sun-4e vs. Sun-4m vs. Sun-4d), and there's "subarchitecture" in the sense of instruction set architecture differences in the form of backwards-compatible additions (SPARC v7 -> SPARC v8, IA-32 from the 80386 to the 32-bit Pentium 4's, x86-64 from the first Opterons/Pentium 4s to the current AMD and Intel processors, S/370 picking up various instructions, z/Architecture ARCHLVL updates, ARM vX.Y, various MIPS/PA-RISC/Alpha extensions, etc.).
S/360 was an example of a third case, where some instructions are add-on options; the PDP-11 had that as well. That continued into the microprocessor era until floating-point units got incorporated into the CPU chip.
I'd consider 32-bit -> 64-bit as a fourth case; it's an "addition" but it's a lot bigger than, say, various streaming SIMD extensions.
So I don't see any straightforward single unifying concept of "subarchitectures" here. Guy Harris (talk) 22:07, 12 June 2019 (UTC)

optionsEdit

Continuing the subarchitecture discussion, but with a different name. Some differences are not so big as to create an entirely new architecture, but are big enough to know about. For VAX, tradition is for options that are not in the hardware to be emulated in OS software, transparent to the user. IBM did some of that, but not quite as much. There is software emulation for S/360 extended (quad) precision floating point, but implemented through user mode (SPIE) code. As noted, optional floating point for x86 was done in software, usually through user mode INT instructions, which might be patched over (self modifying code) for systems with FP hardware. In some cases, users are supposed to know which options are available on their system. IBM's ARCHLVL is one way to describe them to users. Also as noted above, other architectures have optional features, described to users in different ways. Is this something that the article should include? Gah4 (talk) 23:12, 12 June 2019 (UTC)

If by "this article" you mean the instruction set architecture article, yes, that might make sense.
If by "this article" you mean computer architecture, I'd say "no", as this article isn't focused on instruction sets, nor should it be, given the existence of the instruction set architecture article, and those options are instruction set options. Guy Harris (talk) 01:33, 13 June 2019 (UTC)
Hmmm. Can you remind me why there are two articles? In the Sun case, the differences are mostly MMU, which I suppose isn't strictly instruction set architecture. Gah4 (talk) 13:40, 13 June 2019 (UTC)
Two articles as in instruction set architecture and computer architecture? Probably because there's more to computer architecture than instruction set architecture. Whether or not it's considered part of the ISA, at least some architecture specifications include the way memory mapping works (S/370 and later Principles of Operation and Intel's x86 manuals, for example). Others explicitly don't specify it at all, or don't specify it completely, e.g. the SPARC v7/v8/v9 specifications. The 68k manuals originally didn't, because the 68000, 68010, and 68020 had separate MMU chips. Motorola had the 68451 MMU, and later the 68851 paged MMU; the 68030 implemented a (subset of?) the 68851 functionality on chip.
So you have ISAs such as S/370 and its successors, and x86, where an OS can rely on the MMU working a particular way, and you have ISAs such as 68k and SPARC, where an OS can only do so if the system designer, or system architecture specification, specifies a particular MMU architecture. Thus there were no subarchitectures for the Sun386i, but were subarchitectures for Sun-3 (Sun MMU vs. 68030 MMU) and Sun-4 (8K page Sun MMU, 4K page Sun MMU, SPARC Reference MMU, various other MMUs for SPARC v9 processors).
There are other aspects of the architecture that might or might not be specified by whatever architecture manual(s) there are for the processor. The x86 manual may specify how the MMU works, but it doesn't specify how the ROM monitor works (I can think of at least 3 different ROM monitor styles used on x86 machines - classic BIOS, EFI/UEFI, and Open Firmware as used on some NetApp appliances), or what buses there are on the system (again, x86 systems have used whatever bus the original PC used, the ISA bus, the EISA bus, the Micro Channel bus, various flavors of PCI (parallel and serial), and possibly others. Most merchant microprocessors have, I suspect, had systems built with multiple different buses as well. S/3x0, as noted, has implemented the channel interface with different physical layers (bus and tag, ESCON, FICON), but I think a lot of the way programs perform I/O operations is independent of the physical layer, being specified in the Principles of Operation. On the other hand, recent z/Architecture models also support a different I/O bus; it's called "PCI" or something such as that. :-) (IBM didn't document the "bang on the PCI bus" instructions, but they're used in some Linux kernel source files.)
So the line between "instruction set architecture" and "system architecture" are somewhat blurry; S/3x0 has the broadest official specification I know of (which is easier if the company that specifies the architecture is also the only company making systems using that architecture, as IBM was except during the plug-compatible era). x86's architecture covers less, although Intel have been involved in other specifications that, when combined with the x86 manuals, form a de facto system architecture specification that most systems based on x86 chips implement (even my Mac could have Windows installed on it, booting on the raw hardware, and at least one x86 Mac at Apple when I was there had Solaris on it, as I remember).
But none of that applies to the options being discussed in this section; those are optional instructions, so clearly part of the ISA, and thus appropriate to instruction set architecture. Guy Harris (talk) 19:49, 13 June 2019 (UTC)
Historical note for your information: the Elliott 4100 series of computers (1965 onwards) also used unimplemented operation traps in various ways: the Elliott 4130 model had hardware floating point but the 4120 model did not, so use of floating point instructions on a 4120 caused an unimplemented operation trap to a (system) routine which emulated the required operation; ditto for hardware subscript checking for arrays. The Fortran compiler generated opcodes for complex arithmetic which were then handled in a similar way; it was reported that the 4150 model (development halted when firm taken over by ICT) would have had hardware for complex arithmetic. Murray Langton (talk) 09:09, 14 June 2019 (UTC)

SPIEEdit

In the discussion above, I mentioned SPIE, which in IBM terms is Specify Program Interrupt Exit. SPIE allows programs to take control when specific interrupts occur, such as the one for an undefined opcode. This allows, in user space, for emulation of features not implemented in hardware, such as instructions added to newer systems. I thought this, or similar ideas, should be discussed somewhere in Wikipedia, but I couldn't find anything even close. It also allows for addressing interrupts, fixed and floating point overflow and divide by zero, and similar exceptions. It is done such that the program can fix the problem, and continue. (Except that imprecise interrupts complicate everything.) Yes this is too specific for this article, but I didn't think of where else to ask. Gah4 (talk) 13:52, 13 June 2019 (UTC)

That's an OS/360^Wz/OS-specific feature. Unix has signals; the Windows NT equivalent is Structured Exception Handling. The general notion of the OS doing callbacks for errors of that sort is discussed in Exception handling#Exception handling facilities provided by the operating system, but that section is a bit of a stub - it seems to give details only about Unix signals, and not many such details. Guy Harris (talk) 20:00, 13 June 2019 (UTC)
I was trying to figure out where to make a redirect for appropriately disambiguated SPIE. One that is done with SPIE is to emulate, in user space, instructions not implemented on a given model. The routine can find the instruction, extract the fields, get the register values, and change the saved registers. Another old favorite (S/360 days) is to fix up misaligned data access. Do unix signals allow one to modify memory and registers, and then return to continue on? Yes with Unix signals described, and without details, it didn't seem appropriate for redirect. Gah4 (talk) 21:16, 13 June 2019 (UTC)
POSIX says signal handlers shouldn't do that, but that's because arbitrary operations, in the general case, might, for example, modify data structures that were in the middle of being updated when the signal occurred (signals can result either from traps such as illegal instruction traps or external signals such as typing ^C). In particular cases, it might happen to be safe; that's how the V6 UNIX floating-point emulator worked - it caught the SIGILL signal, delivered on an illegal instruction trap, and proceeded to decode and interpret instructions until it saw a non-floating-point instruction (so you didn't get the trap handling overhead on every floating-point instruction). (I seem to remember having to tweak that for the PDP-11/34, and spending some time looking at PDP-11/34 microcode listings to figure out what needed to be tweaked.)
Tru64 UNIX on Alpha, as I remember, emulated unaligned accesses in the kernel, rather than handing them to userland to emulate; some other UN*Xes on processors that trapped on unaligned accesses may have done so. Guy Harris (talk) 22:06, 13 June 2019 (UTC)
For IBM, the Fortran library optionally (sysgen select) did the alignment fixup, unless your model had imprecise interrupts, such that it can't find the instruction. (And if it could, too much else might have happened since.) IBM also wrote the routine for extended precision (quad) floating point called by SPIE routines. Gah4 (talk) 22:42, 13 June 2019 (UTC)
Also, Exception_handling_syntax#Assembly_language mentions IBM and the STXIT macro, which seems to come from DOS/VSE. STXIT mentions SPIE and STAE as OS/VS1 additions, but I am pretty sure they trace back to OS/360. The exact order that they were added to the respective systems, I don't know. Gah4 (talk) 21:31, 13 June 2019 (UTC)
STXIT comes from DOS/360; DOS/VSE had it because DOS/360 had it. See the DOS Release 26.2 edition of DOS Supervisor and I/O Macros.
SPIE/STAE date all the way back to OS/360, and OS/VS1 (and VS2 SVS, and VS2 MVS, and...) had it because OS/360 had it. The two OSes just happened to do things differently. See a 1966 edition of IBM System/360 Operating System Control Program Services.
I removed the mention of SPIE/STAE from STXIT because they referred to it as a "later development", replacing STXIT with SPIE/STAE, which is nonsense - as far as I know, OS/360 was originally intended to be the only OS for S/360, with DOS/360 developed as a stopgap when OS/360 was late and too big for smaller machines, so maybe SPIE/STAE existed before STXIT. OS/360 has no sign of STXIT in that earlier OS/360 documentation.
So if STXIT has its own Wikipedia page, I don't see why SPIE/STAE couldn't have their own page as well (preferably not talking about it as an OS/VS1 invention or something ahistorical such as that). It could be mentioned in Exception handling syntax#Assembly language - and probably should be, so nobody thinks STXIT was the one and only such mechanism in S/3x0 operating systems. Guy Harris (talk) 22:27, 13 June 2019 (UTC)
So SPIE and STAE should be one page, or two? Gah4 (talk) 22:42, 13 June 2019 (UTC)
I might be tempted to have one page. On UN*X, SPIE is roughly equivalent to catching the SIGILL, SIGSEGV, SIGBUS, and SIGFPE signals, while STAE is roughly equivalent to catching the SIGABRT and maybe SIGTERM signals, so they're both part of the general "catch abnormal event" mechanism. I could also see separate pages, however, as one is for hardware traps and one is for software abnormal termination indications. Guy Harris (talk) 23:06, 13 June 2019 (UTC)
Return to "Computer architecture" page.