Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

CPU Instruction Set As an Artistic Object and the History of Classic CPU Instruction Sets

The history of CPUs is an extremely interesting part of computer history. The first CPUs that I worked on (Minsk-2) had no index registers and to organize a loop one needed to modify instructions -- an interesting proof of flexibility of the Von Newman architecture.  After that I learned several other architectures and came to conclusion that actually instruction set is to certain extent is an artistic object and we can legitimately talk about beautiful/elegant and ugly CPU instruction sets.

One of the rare surviving species among early architectures is IBM/360 architecture. There is a definite elegance in the S/360 instruction set and it greatly influenced subsequent development. A lot of achievements of S/360 architecture are attributable to Gene Amdahl (the architect of earlier Stretch computers who returned to the company in 1960 and was named Manager of Architecture for the IBM System/360 family. The System/360, announced in April of 1964, was a series of instruction-set compatible machines covering a 400:1 performance range. It became the greatest success story in the history of computing and IBM's most profitable product line ever. The System/360 introduced a number of industry standards, such as:

The 360/67, first shipped in August, 1966, was the first IBM system to offer dynamic address translation  and virtual machine capabilities to its users in conjunction with its CP-67 operating system. The basic System/360 instruction set is still used in current IBM mainframe products today.

PDP11 and VAX architecture is also still interesting as it served a bases for early Unixes and you need to understand it in order to read Lions book. Actually I know that in 2000 there were production PDP 11 servers in some publishing companies in the USA !

Alpha was one of the early 64 bit architectures and it's still in use today.  UltraSparc is another interesting RISK architecture that worth studying.

As 64-Bit CPUs Alpha, SPARC, MIPS, and POWER aptly put it:

In a time when microprocessors are advertised on TV and CPU vendors have their own jingles, the fantastic technology embodied in these chips seems almost irrelevant. And it nearly is-- microprocessor marketing is drawing ever nearer to perfume advertising. All the emphasis is on packaging and marketing, branding and pricing, channels and distribution, with little left over for solid product details, features, and benefits. Little old ladies who don't know a transistor from a tarantula know the name "Pentium" and think they want "HyperThreading." It's a good thing that for some of us, the technology still matters.

Also please don't be glamorized with the performance. Performance, which common folks associate with clock rate in MHz is a tricky thing to measure and to use and it's not all the matter in chips design.  Premature optimization is the source of all evil that that's true about CPU instruction sets tuned to higher lock speeds too.

Please remember about this so called "MHz myth". Ever artificial "raw performance" benchmarks like SPECint/SPECfp are much better then MHz/GHz metric (although they are generally correlated).  This is the battle that AMD fights. They are spending big bucks trying to remind people that just because that P4 is running at 3GHz, it doesn't mean that it is faster than a 2.2GHz Athlon. Also  memory architecture influences the real world performance of CPU in a major way. Memory is much slower then CPU registers, so it is a bottleneck that designers try to resolve implementing multilevel caching L1/L2/L3trying to capitalize of the locality of references in most programs.

It's irrelevant how many times per second the chips clock says "tic-tac", what matters is how fast real chips can get real jobs done. For real-world purposes, you can compare the best (i.e., the fastest chips) or the most valuable (i.e., the ones with the best speed/price ratio).  To use a car metaphor (that most people seem to understand), not everyone needs or wants to drive a Lamborghini. It's expensive, it's hard to park, it's hard to drive, it's cramped and it drinks too much gas. Most people are better off with a "normal" car, that's fast enough and powerful enough for them, is easy to drive, and has room for the kids.

There are several classic real architectures like System 3xx, SPARC, MIPS, VAX-11, Motorola 6800, PowerPC, Intel x86. But real CPUs (other then MIPS) are always a little bit too complex. Emulators of some  ideal "teaching" architectures makes a pleasant change from real system in the same way as miniOSes are a real pleasure to work with in comparison with systems with 16-MB minimum memories and kernels that no single human being can ever comprehend :-). Also CPU manufactures always leaves some things out, but in an emulator you can try to correct their mistakes ;-).  There are also two important  "ideal" machines created by highly respected authors that definitely belong to the history of CPU instruction set development:

• DLX is an emerging academic standard and that has MIPS-like architecture. It's documented in "Computer Architecture: A Quantitative Approach" by Hennessy and Patterson. The latter is the bible of CPU architecture. The reasoning in H&P is so clear and makes so much sense that I think there is little to add to what they wrote.

  DLX instruction set format:

  • 32-bit fixed length instruction with 32 general purpose registers (actually 31 as R0 has a hard-wired zero).  Memory is Big Endian byte addressable (i.e. byte 0 is in the most significant position of the word), and all instruction accesses are aligned.
  • Lots of registers (31 general purpose registers, and an always-0 R0). R31 is used as the link register for in the JAL (jump and link) instruction.
  • Three-operand, load-store architecture.  6 bits for the opcodetwo source and one destination operands encoded each in a five bit field; immediate data limited to 16 bits so we can fit it in a 32-bit instruction
  • Its major advantage is that gcc has already been ported to it, so we don't need to write a new compiler on top of everything else. You can try to port the Linux kernel to it :-). But there are other interesting things that you can do.
  • There are very few instruction formats, and they are closely related. In fact there are only three:

    I Format

    R Format

    J Format

  • Comparatively few instructions (only 64 possible opcodes) with expanding opcodes (the opcode&func fields can be considered as a 17 bit expanded opcode).
  • Few addressing modes (only immediate and displacement - their term for indexed addressing using a constant index). Loads and stores must be aligned, but there are instructions to support unaligned data.
  • No condition codes. Branches are computed by comparing a register to zero as part of the branch instruction (eg BNEZ). There are also some ``helper'' instructions that will compare two registers and place a 1 or a 0 in the destination register depending on whether the comparison comes out true.

• MMIX is Donald Knuth's project for volume 4 of  The Art of Computer Programming (TAOCP).  It has RISK instruction set that can be considered as a derivative of DLX architecture (see below). It's described at http://sunburn.stanford.edu/~knuth/mmix.html. The design goal is be easy to understand, (so as not to distract from the algorithms), but still to give readers a good general idea of how high-level constructions are actually implemented. As such was not designed to be particularly fast, low-power, cheap, or any of the other things that real CPUs need to deal with. But please note that a side-effect of being easy for humans to understand is usually a fast implementation ;-).

  MMIX  operates primarily on 64-bit words. It has 256 general-purpose 64-bit registers (too many for my taste ;-) that  can hold either fixed-point or floating-point numbers. Instructions have 4-byte form `OP X Y Z', where each of OP, X, Y, and Z is a single 8-bit byte. If OP is an ADD instruction, for example, the meaning is ``X=Y+Z''; i.e., "Set register X to the contents of register Y plus the contents of register Z.'' It has only 256 possible OP codes that fall into a dozen or so categories. 

  Some people, including myself, think that 256 registers are "too many" :-). Section 42 describes a limited version of MMIX with only 32 local registers plus 32 global registers (plus the 32 special registers), that is binary compatible with most MMIX programs.

  The cycle counter, the interval counter, and the usage counter might by very useful for profiling.

  It is nice that "DIV" calculates both the quotient and the remainder, even though those 4 numbers (2 input, 2 output) don't fit in the general 2 input, 1 output scheme. I don't like special-purpose registers, but I hesitate to criticize the plethora of "special registers" in MMIX

  Subroutine linkage is, at first glance, unnecessarily complicated.

SPARC's instruction set is similar to MIPS but its register organization is unique. SPARC exposes 32 registers at any one time, but these registers are just a "window" into a larger set of physical registers. The additional registers are hidden from view until you call a subroutine or other function. Where other processors would push parameters on a stack for the called routine to pop off, SPARC processors just "rotate" the register window to give the called routine a fresh set of registers. The old window and the new window can overlap, in this case some registers are shared. As long as you're careful about placing parameters in the right registers, the windows are a very slick way to pass operands without using the memory stack at all. If we assume that  the register set is big (for example 4K registers), then overflow is not a  problem. In reality you need to deal with it, burning cycles.  Complexity of this register scheme was one of the reasons why SPARC was never a leader in benchmarks.

According to Richard Birkby ( A Brief History of the Microprocessor ) SPARC was on of the first RISK CPUs:

A new philosophy - RISC

Most commentators see RISC as a modern concept, more akin to the 1990s, yet it can be traced to 1965 and Seymour Cray's CDC (Control Data Corporation) 6600. RISC design emphasizes simplicity of processor instruction set, enabling sophisticated architectural techniques to be employed to increase the speed of those instructions. A classic example is the VAX architecture where the INDEX instruction was 45% to 60% faster when replaced by simpler VAX instructions. The CDC 6600 has many RISC features including a small instruction set of only 64 op codes, a load/store architecture and register to register operations. Also, instructions weren't variable lengths, but 15 or 30 bits long.

Although the term RISC was not used, IBM formalized these principles in the IBM 801(1975), an Emitter Coupled Logic (ECL) multichip processor. The architecture featured a small instruction set, load/store memory operations only, 24 registers and pipelining (+10).

When RISC became popular in the late eighties, IBM tried to market the design as the Research OPD (Office Products Division) Mini Processor (ROMP) CPU, but it wasn't successful. The chip eventually became the heart of the I/O processor for the IBM 3090. The term RISC first came from one of two University research projects in the USA. The Berkeley RISC 1 formed the basis for the commercial Scalable (formerly Sun) Processor Architecture (SPARC) processor, whilst Stanford University's Microprocessor (+11) without Interlocked Pipeline Stages (MIPS) processor was commercialized and is now owned by Silicon Graphics Inc. The Berkeley RISC I was begun by David A. Patterson and his colleagues in 1980. He had returned from a sabbatical at Digital Equipment Corporation in 1979 and had been contemplating the difficulties surrounding the designing of a CPU containing the VAX architecture. He submitted a paper to Computer on the subject, but it was rejected on the grounds of a poor use of silicon. The rejection made Patterson wonder what a good use of silicon was. This led him"down the RISC path" (+12).

The RISC I, II and SPARC families are unusual in that they feature register windows. A concept where a CPU has only a few registers visible to the programmer, but that set can be exchanged for another set, or window when the programmer chooses. This was intended to provide a very low subroutine overhead, by facilitating fast context switches. It was later acknowledged that a clever compiler can produce code for non-windowed machines which was nearly as efficient as a windowed processor. Windowing is difficult to implement on a processor, so the concept did not become popular on other architectures. Around the mid-eighties, the term RISC became somewhat of a buzzword. Intel applied the term to its 80486 processor although it was clearly nothing of the sort. Steve Przybylski, a designer on the Stanford MIPS project satirizes this in his definition of RISC. 'RISC: any computer announced after 1985' (+13).

Around the time the results of the Stanford and Berkeley projects were released, a small UK home computer firm, Acorn was looking for a processor to replace the 6502 used in its present line of computers. Their review of commercial microprocessors including the popular 8086 and 68000 concluded that they were not advanced enough, so in 1983 began their own project to design a RISC microprocessor. The result, ARM (Advanced RISC Machine, formerly Acorn RISC Machine) is probably the closest to true RISC of any processor available.

 Dr. Nikolai Bezroukov

News

[Nov 14, 2006] A Brief History of the Microprocessor   by Richard Birkby 1995

A new philosophy - RISC

Most commentators see RISC as a modern concept, more akin to the 1990s, yet it can be traced to 1965 and Seymour Cray's CDC (Control Data Corporation) 6600. RISC design emphasizes simplicity of processor instruction set, enabling sophisticated architectural techniques to be employed to increase the speed of those instructions. A classic example is the VAX architecture where the INDEX instruction was 45% to 60% faster when replaced by simpler VAX instructions. The CDC 6600 has many RISC features including a small instruction set of only 64 op codes, a load/store architecture and register to register operations. Also, instructions weren't variable lengths, but 15 or 30 bits long.

Although the term RISC was not used, IBM formalized these principles in the IBM 801(1975), an Emitter Coupled Logic (ECL) multichip processor. The architecture featured a small instruction set, load/store memory operations only, 24 registers and pipelining (+10).

When RISC became popular in the late eighties, IBM tried to market the design as the Research OPD (Office Products Division) Mini Processor (ROMP) CPU, but it wasn't successful. The chip eventually became the heart of the I/O processor for the IBM 3090. The term RISC first came from one of two University research projects in the USA. The Berkeley RISC 1 formed the basis for the commercial Scalable (formerly Sun) Processor Architecture (SPARC) processor, whilst Stanford University's Microprocessor (+11) without Interlocked Pipeline Stages (MIPS) processor was commercialized and is now owned by Silicon Graphics Inc. The Berkeley RISC I was begun by David A. Patterson and his colleagues in 1980. He had returned from a sabbatical at Digital Equipment Corporation in 1979 and had been contemplating the difficulties surrounding the designing of a CPU containing the VAX architecture. He submitted a paper to Computer on the subject, but it was rejected on the grounds of a poor use of silicon. The rejection made Patterson wonder what a good use of silicon was. This led him"down the RISC path" (+12).

The RISC I, II and SPARC families are unusual in that they feature register windows. A concept where a CPU has only a few registers visible to the programmer, but that set can be exchanged for another set, or window when the programmer chooses. This was intended to provide a very low subroutine overhead, by facilitating fast context switches. It was later acknowledged that a clever compiler can produce code for non-windowed machines which was nearly as efficient as a windowed processor. Windowing is difficult to implement on a processor, so the concept did not become popular on other architectures. Around the mid-eighties, the term RISC became somewhat of a buzzword. Intel applied the term to its 80486 processor although it was clearly nothing of the sort. Steve Przybylski, a designer on the Stanford MIPS project satirizes this in his definition of RISC. 'RISC: any computer announced after 1985' (+13).

Around the time the results of the Stanford and Berkeley projects were released, a small UK home computer firm, Acorn was looking for a processor to replace the 6502 used in its present line of computers. Their review of commercial microprocessors including the popular 8086 and 68000 concluded that they were not advanced enough, so in 1983 began their own project to design a RISC microprocessor. The result, ARM (Advanced RISC Machine, formerly Acorn RISC Machine) is probably the closest to true RISC of any processor available.

... ... ...

The SuperRISCs

In 1988, DEC formed a small team that would develop a new architecture for the company. Eleven years previously, it had moved from the PDP-11 to the VAX architecture, but it was seen that it would start lagging behind by the early 1990s. The project turned out to be huge with more than 30 engineering groups in 10 countries working on the Alpha AXP architecture as it came to be known (+15).

The team were given a fabulous design opportunity; an architecture that would take DEC into the 21st century. To accommodate the 15-25 year life span of the processor, they looked back over the previous 25 years and concluded a 1000 fold increase in computing power occurred. They envisaged the same for the next 25 years, and so they concluded that their designs would, in the future, be run at 10 times the clock speed, 10 times the instruction issue rate, (10 times superscalar) and 10 processors working together in a system. To enable the processor to run multiple operating systems efficiently, they took a novel approach and placed interrupts, exceptions, memory management and error handling into code called PALcode (Privileged Architecture Library) which had access to the CPU hardware in a way which microcode normally has. This enables the Alpha to be unbiased toward a particular computing style.

The Alpha architecture was chosen to be RISC but crucially focused on pipelining and multiple instruction issue rather than traditional RISC features such as condition codes and byte writes to memory, as these slow down the former techniques. The chip was released in 1992 and in that year entered the Guinness Book of Records as the world's fastest single-chip microprocessor. While the Alpha attempts to increase instruction speed by simplifying the architecture and concentrating on clock speed and multiple issue, the PowerPC from IBM and Motorola is the antithesis to this. The PowerPC was born out of the needs of IBM and Motorola to develop a high performance workstation CPU. Apple, another member of the PowerPC alliance needed a CPU to replace the Motorola 680x0 in its line of Macintosh computers. The PowerPC is an evolution of IBMs Performance Optimized with Enhanced RISC (POWER) multichip processors. Motorola contributed the bus interface from their 88110 microprocessor.

Conclusion

The microprocessor has become a formidable force in computing. From a humble beginning as a concept of reducing the price of a calculator to high powered, uniprocessor and multiprocessor machines in only two and a half decades is astounding pace. Like most classic inventions, its early years belong firmly to the start-ups and pre-pubescent companies. These didn't have the baggage of the established companies and grew quickly. However, the mid 1980s saw a changeover, mainly due to the spiralling cost of research into process technologies and the greater man-hours needed to implement hundreds of thousand transistors design. This was headed by Motorola, Intel, IBM and DEC. It is now acknowledged that the RISC concept is the superior architectural concept and all the forementioned companies have leading designs using RISC.

The microprocessor was originally designed for a calculator, yet in recent years it has found its way into a multitude of designs. A seemingly exponential growth curve for applications has occurred. From cars to personal computers, televisions to telephones, the microprocessor proliferates, and the growth curve shows no signs of abating. This essay shows just part of the large history of the microprocessor and the path designs took. There are many other fields where the microprocessor has made a huge impact, not least in the low cost market, which deserve to be investigated further.

[Mar 25, 2005] Newman College contains nice graph of where each CPU should be positioned on RISK/CISC  coordinates.

This topic is a bit of a furphy really. The great debate about Reduced Instruction Set Chips (or Computers) and Complex Instruction Set Chips (or Computers) is really irrelevant these days. They really are just two design approaches to chips that were common in the late 1970s and 1980s. The driving force toward either of these design approaches has largely gone. Most chips and therefore the computers that are run by them have always fallen in between the two extremes anyway.

[Jan 1, 2005] The year in microprocessors

64-bit Futures Part III - IBM and Sun

Well, Power architecture is increasingly going head-on against Itanium in many large deals, even sinking the good ship Itanic in some situations with - believe or not - lower prices! And improved performance with better compilers, more superdense high-bandwidth machine like the superb p655+, where two 8-way single MCM systems with 1.7+ GHz POWER4+ processors fit within a 4U space! So, 16 systems and some 880+ GFLOPs of peak 64-bit power get squeezed into a single rack - 4 times the density of HP Itanium2! Put a nice shared-memory interconnect like the increasingly popular Bristol product, Quadrics QsNet, and you got a nasty supercomputing monster.

And, these can run 64-bit Linux (almost) as well as their home OS, AIX.

The memory bandwidth of each eight-way box is 51.2 GB/s, or eight times that of a four-way Intel Itanium2, or 11 times that of a four-way Sun USIII box. Of course, Rmax (the obtainable percentage of FLOPS in Linpack FP bench) is right now far less on Power4 than on Itanium2 - 60% vs almost 90% - but the extra frequency and greater memory bandwidth more than make up for that in many apps.

Towards the end of the year, the multithreaded POWER5 will also dramatically improve the FP benchmark scores, not to mention twice the CPU density, a quarter larger cache, even higher memory bandwidth and lower latency. But don't expect major clock speed improvements, the focus was on real performance and reliability benefits - as if chip-kill memory, eLiza self-healing, and per-CPU logical partitioning was not enough...

Finally, the existing SuSE and coming RedHat Linux on POWER4 and its follow-ons, natively 64-bit of course, aim to give extra legitimacy to it being "an open platform" at least as much as Itanium is.

On the low-end, the PowerPC 970 - or POWER4 Lite, might (or pretty much will be now that Motorola G5 is down the drain) the basis of Apple's next generation Mac platform - it's 64-bit ticket to the future. With its low power - down to less than 16W in low-power mobile 1.2 GHz mode, it will also enable very dense server blades and of course POWERful 64-bit ThinkPads or PowerBooks running AIX, Linux or MacOS...

For IBM then, Opteron makes sense as an excellent tool to corner Intel, with POWER on high end and Opteron on low-end, both 64-bit and both soon manufactured by IBM Microelectronics? No, I didn't say both owned by IBM, even though that is a possibility: AMD does need a sugar daddy, not a sugar mommy. Got my hint who the feisty "sugar mommy" could be?

What about the other major vendor, from SUN-ny California? Well, UltraSPARCIIIi is finally out, no surprise there, it helps a bit but is still far behind all other major CPUs (except MIPS) in most benchmarks. Yes, Sun's mantra of something like "we don't care about speed, we focus on our brand etc" can continue, but what is computing if not about speed and performance?

Still no sign of US IV anyway, and even when it comes, don't expect much of extra per-thread performance over US III - When (and if) it really rolls out in volumes towards yearend, it will have to fight both POWER5 and Madison2, both very powerful beasts on the rise, backed by humungous ruthless megacompanies - each of which can eat Sun as an appetiser.

You can read hundreds of pages of Net discussions about the particular merits and demerits of SPARC vs other architectures, from all sides and viewpoints, but the fact remains - SPARC is the turtle of the 64-bit world, slow and maybe long-lived compared to, say, Alpha, but even turtles have to die at some point... and before they die, they become extremely slow...

64-bit Opteron is fast in some things compared to the rest of the gang, and not so fast in others, but whatever the case, current and future Opterons are vastly superior performance and feature wise to low-end and midrange SPARC offerings at umpteen times lower cost. Plus, they are as 64-bit as SPARC (or any other 64-bit CPU) is... so Sun taking Opteron would be simply common sense...

Why 64-bits are good, and why they're not

THIS ARTICLE hopes to cast some light on why 64-bit addressing, that is, the native mode of the Opteron or Itanium versus that of the Athlon or Pentium is important in 2003. It also attempts to address what the requirements are and - equally importantly - are not.

Before we start, an easy one. Why 64-bit and not 48-bit? Because it costs little more to extend a 32-bit ISA to 64-bit than to only 48-bit, and most people like powers of two. In practice, many of the hardware and operating system interfaces will be less than 64 bits, sometimes as few as 40 bits, but the application interfaces (i.e. the ones the programmers and users will see) will all be 64-bit.

There are several non-reasons quoted on the Internet; one is as arithmetic performance. 64-bit addressing does not change floating-point, and is associated with 64-bit integer arithmetic; while it is easy to implement 32-bit addressing with 64-bit arithmetic or vice versa, current designs don't. Obviously 64-bit makes arithmetic on large integers faster, but who cares? Well, the answer turns out to be anyone who uses RSA-style public key cryptography, such as SSH/SSL, and almost nobody else.

On closer inspection, such use is dominated by one operation (NxN->2N multiplication), and that is embedded in a very small number of places, usually specialist library functions. While moving from 32 to 64 bits does speed this up, it doesn't help any more than adding a special instruction to SSE2 would. Or any less, for that matter. So faster arithmetic is a nice bonus, but not a reason for the change.

File pointers are integers, so you can access only 4GB files with 32 bits, right? Wrong. File pointers are structures on many systems, and files of more than than 4GB have been supported for years on a good many 32-bit systems. Operations on file pointers are usually well localised and are normally just addition, subtraction and comparison anyway. Yes, going to 64-bits makes handling large files in some programs a bit easier, but it isn't critical.

Let's consider the most common argument against 64-bit: compatibility.

Almost all RISC/Unix systems support old 32-bit applications on 64-bit systems, as did IBM on MVS/ESA, and there is a lot of experience on how to do it almost painlessly for users and even programmers.

Microsoft has a slightly harder time because of its less clean interfaces, but it is a solved problem and has been for several decades.

Now let's get onto some better arguments for 64-bit. One is that more than 4GB of physical memory is needed to support many active, large processes and memory map many, large files - without paging the system to death. This is true, but it is not a good argument for 64-bit addressing. The technique that Intel and Microsoft call PAE (Physical Address Extension) allows 64 GB of physical memory but each process can address only 4GB. For most sites in 2003, 64GB is enough to be getting on with.

IBM used this technique in MVS, and it worked very well indeed for transaction servers, interactive workloads, databases, file servers and so on. Most memory mapped file interfaces have the concept of a window on the file that is mapped into the process's address space - PAE can reduce the cost of a window remapping from that of a disk transfer (milliseconds) to that of a simple system call (microseconds). So this is a rather weak reason for going to 64-bit addressing, though it is a good one for getting away from simple 32-bit.

Now, let's consider the second most common argument against 64-bit: efficiency. Doubling the space needed for pointers increases the cache size and bandwidth requirements, but misses the point that efficiency is nowadays limited far more by latency than bandwidth, and the latency is the same. Yes, there was a time when the extra space needed for 64-bit addresses was a major matter, but that time is past, except perhaps for embedded systems.

So 64-bit addressing is unnecessary but harmless except on supercomputers? Well, not quite. There are some good reasons, but they are not the ones usually quoted on the Internet or in marketing blurb.

The first requirement is for supporting shared memory applications (using, say, OpenMP or POSIX threads) on medium or large shared memory systems. For example, a Web or database server might run 256 threads on 16 CPUs and 32GB. This wouldn't be a problem if each thread had its own memory, but the whole point of the shared memory programming model is that every thread can access all of the program's global data. So each thread needs to be able to access, say, 16GB - which means that 32-bit is just not enough.

A more subtle point concerns memory layout. An application that needs 3GB of workspace might need it on the stack, on the main heap (data segment), in a shared memory segment or in memory set aside for I/O buffers. The problem is that the location of those various areas is often fixed when the program is loaded, so the user will have to specify them carefully in 32-bit systems to ensure that there is enough free space in the right segment for when the program needs its 3GB.

Unfortunately, this choice of where to put the data is often made by the compiler or library, and it is not always easy to find out what they do. Also, consider the problem of an administrator tuning a system for multiple programs with different characteristics. Perhaps worst is the case of a large application that works in phases, each of which may want 2GB in a different place, though it never needs more than 3 GB at any one time. 64-bit eliminates this problem.

To put the above into a commercial perspective, almost all general purpose computer vendors make most of their profit (as distinct from turnover) by selling servers and not workstations. 64-bit addressing has been critical for some users of large servers for several years now, and has been beneficial to most of them. In 2003, 64-bit is needed by some users of medium sized servers and useful to most; by 2005, that statement could be changed to say `small' instead of 'medium sized'. That is why all of the mainframe and RISC/Unix vendors moved to 64-bit addressing some time ago, and that is why Intel and AMD are following.

On the other hand, if you are interested primarily in ordinary, single user workstations, what does 64-bit addressing give you today? The answer is precious little. The needs of workstations have nothing to do with the matter, and the move to 64-bit is being driven by server requirements. µ

Nick Maclaren has extensive experience of computing platforms

Chronology of Digital Computing Machines by Mark Brader (Usenet posting). Many mirrors. see for example A Chronology of Digital Computing Machines (to 1952) or http://www.davros.org/misc/chronology.html

A Chronology of Digital Computing Machines (to 1952)

Sep 1947

A moth (?-1947) makes the mistake of flying into the Harvard Mark II. A whimsical technician makes the logbook entry "first actual case of bug being found", and annotates it by taping down the remains of the moth.

(The term "bug" was of course already in use; that's why it's funny.)

Jun 1948

Newman, Freddie C. Williams, and their team at Manchester University, Manchester, England, complete a prototype machine, the "Mark I" (also called the "Manchester Mark I"). This is the first machine that everyone would call a computer, because it's the first with a true stored-program capability.

It uses a new type of memory developed by F. C. Williams (possibly after an original suggestion by Presper Eckert), which uses the residual charges left on the screen of a CRT after the electron beam has been fired at it. (The bits are read by firing another beam through them and reading the voltage at an electrode beyond the screen.) This is a little unreliable but is fast, and also relatively cheap because it can use existing CRT designs; and it is much more compact than any other memory then existing. The Mark I's main memory of 32 32-bit words occupies a single Williams tube. (Other CRTs on the machine are less densely used: one contains only an accumulator.)

The Mark I's programs are initially entered in binary on a keyboard, and the output is read in binary from another CRT. Later Turing joins the team (see also the "Pilot ACE", below) and devises a primitive form of assembly language, one of several developed at about the same time in different places.

Text of History of Supercomputing exhibit (DOE accomplishments are in italics).
 

***** A Seymour Cray Perspective by Gordon Bell -- an extremly interesting slides about one of the most important computer architecture pioneers (89 slides). Some interesting notes are reproduced below [ Feb 06, 2002]

Cray was the penultimate "tall, thin man"*. I viewed him as being the greatest computer builder that I knew of as demonstrated by his designs and their successors that operated at the highest performance for over 30 years. He created the class of computers we know as supercomputers.

His influence on computing has been enormous and included: circuitry, packaging, plumbing (the flow of heat and bits), architecture, parallelism, and programming of the compilers to exploit parallelism… and the problems themselves.

... Cray worked at every level of integration from the packaging, circuitry, through the operating system, compiler and applications. Part of his success was his ability and willingness to work at all levels and understand every one of them deeply. He excelled at five P’s: packaging, plumbing, parallelism, programming and understanding the problems or apps.

By plumbing I include both the bits and heat flow. A lot of computing is a plumbing problem: deciding on bit pipes, reservoirs or memories, and interchanges (switches). Are there big enough pipes? And are the reservoirs big enough? After all what is a processor other than just a pump. Memory is a storage tank. Gene Amdahl’s rules state that for every instruction per second you need a byte of memory to hold it and one bit per second of I/O. That carries into Cray’s rule for every flops or floating-point operation per second you need a word of memory for holding the results and two memory accesses of bandwidth!

Cray came to the the University of Minnesota under the WW II G.I. Bill, got a BSEE, then a masters the next in Math. He went to Electronic Research Associates (ERA) and virtually started designing computers and leading and teaching others the day he arrived. He was given the job of designing the control for the ERA1103, a 36-bit scientific computer that Unisys still produces.

He was the chief architect and designer for Univac’s Navy Tactical Data System computer. ERA was bought by Remington-Rand, became part of Univac, and now Unisys. The first merger created the impetus for the ERA founders to form Control Data.

In 1957, when CDC started, Cray put together the “little character”, a six bit computer to test circuits for the first CDC computer, the 160 --- the IO computer for the 1604. So here’s an idea that Cray pioneered: use little computers to do IO for larger computers. The 3600 series followed and held CDC until the 6600 was born in the mid-60s.

The 6600 influenced architecture probably more than any other computer. It was well plumbed in every respect: it had tremendous bandwidth that interconnected all the components. All computer designers would do well to study it.

CDC built a number of compatible versions, including a dual processor. The 7600 was upward compatible and heavily pipelined. It was to be a prelude to the vector processor.

The Cray 1 was the first successful vector processor. Others had tried with the Illiac IV, CDC Star; TI ASC, and IBM array processor. The Cray 1 was extended with various models before Steve Chen extended it in the XMP as a shared memory multiprocessor. This became the new basis for improving speed through parallelism with each new generation.

Shared memory vector multiprocessors became the formula for scientific computing that is likely to continue well into the 21st century.

This has been modified to interconnect vector computers, forming a giant multicomputer network to gain even more parallelism at even higher prices. I don’t know whether Cray Research will continue with the vector architecture but certainly Fujitsu, NEC and Hitachi continue to believe it is the future..

Let’s look at his amazing 45 year creative and productive career. He was the undisputed designer of Supercomputers… He created the supercomputer class because he didn’t take cost as a design constraint… the design goal was to build the fastest possible machine.

Many contributions in the form of circuits, packaging, and cooling.

I was influenced by the 160 to create the minicomputer industry. This was a 12 bit computer when the Von Neumann architecture for scientific computing called for long words. UNIVAC said computers had to be decimal because people didn’’t understand binary.

DEC started out with 18 bit computers, and when an application came up that could have been hard wired logic, I said “a tiny computer is a better alternative”. He saw the 160 as an IO computer.

[Feb 24, 2001] 360/370 architecture overview

History of Computing Information assembled by Mike Muuss the author of ping.

ENIAC The Army-Sponsored Revolution by William T. Moye ARL Historian, January 1996. That might help the public remember that it was the military research which initiated the computer revolution. Few inventions have had as big an impact on our civilization as the computer, and all modern computers are descended from machines build for military needs.

Fifty years ago, the U.S. Army unveiled the Electronic Numerical Integrator and Computer (ENIAC) the world's first operational, general purpose, electronic digital computer, developed at the Moore School of Electrical Engineering, University of Pennsylvania. Of the scientific developments spurred by World War II, ENIAC ranks as one of the most influential and pervasive.

The origins of BRL lie in World War I, when pioneering work was done in the Office of the Chief of Ordnance, and especially the Ballistics Branch created within the Office in 1918. In 1938, the activity, known as the Research Division at Aberdeen Proving Ground (APG), Maryland, was renamed the Ballistic Research Laboratory. In 1985, BRL became part of LABCOM. In the transition to ARL, BRL formed the core of the Weapons Technology Directorate, with computer technology elements migrating to the Advanced Computational and Information Sciences Directorate (now Advanced Simulation and High-Performance Computing Directorate, ASHPC), and vulnerability analysis moving into the Survivability/Lethality Analysis Directorate (SLAD).

The need to speed the calculation and improve the accuracy of the firing and bombing tables constantly pushed the ballisticians at Aberdeen. As early as 1932, personnel in the Ballistic Section had investigated the possible use of a Bush differential analyzer. Finally, arrangements were made for construction, and a machine was installed in 1935 as a Depression-era "relief" project. Shortly thereafter, lab leadership became interested in the possibility of using electrical calculating machines, and members of the staff visited International Business Machines in 1938. Shortage of funds and other difficulties delayed acquisition until 1941, when a tabulator and a multiplier were delivered.

[Apr. 30, 2000] History of Computing It's Not Easy Being Green (or Red) The IBM Stretch Project

The first machine (now officially named the IBM 7030) was delivered to Los Alamos on April 16, 1961. Although far short of being 100 times faster than competing machines, it was accepted and ran for the next ten years, with the then-astonishing average reliability of 17 hours before failure.

While customers were generally happy with the machine's performance, Stretch was considered a failure within IBM for not meeting its speed benchmark—with the consequence that IBM had to reduce the price from $13.5 million to $7.78 million, thus guaranteeing that every machine was built at a loss. Dunwell's star within IBM fell dramatically, and he was given fewer responsibilities—IBM's version of a gulag.

As time went on, however, attitudes within IBM changed about the lessons Stretch had to offer. From a lagging position in industry, IBM had moved into the forefront through the manufacturing, packaging, and architectural innovations Stretch had fostered. Dunwell's exile ended in 1966, when the contributions Stretch had made to the development of other IBM machines—including the monumentally successful System/360 product line—became evident. Dunwell was made an IBM Fellow that year, the company's highest honor.

A Successful Failure

Hundreds of IBM engineers had dramatically pushed the industry forward during the Stretch project, and Stretch alumni went on to contribute to some of the most important technologies still in use today. (One example is John Cocke, originator of the RISC architectural concept). Harwood Kolsky, designer of Stretch's lookahead unit, now emeritus professor at UC Santa Cruz, notes: "In the early 1950s the time was right for a giant step forward in computing. It was technology that pulled the computing field forward... This is where Stretch really stood out. It was an enormous building project that took technologies still wet from the research lab and forced them directly into the fastest computer of its day."

George Michael, a physicist and Stretch user at the Lawrence Livermore National Laboratory, notes that staff were very surprised that Stretch did not crash every twenty minutes. He calls the system "very reliable... it paid for itself in supporting the 1962 nuclear test series at Christmas Island."

The Stretch story is only one of many chapters in the history of computing demonstrating that our industry's triumphs are built upon the ashes of its "failures." Stretch is one of the hallmark machines—despite its being largely invisible to history—that defined the limits of the possible for later generations of computer architects. Looking at a list of Stretch milestones, you may recognize these many innovations in present-day products:

• Multiprogramming
• Memory protection
• Generalized interrupt system
• Pipelining
• Memory interleaving
• Speculative execution
• Lookahead (overlap of memory and arithmetic ops)
• Concept of a memory bus
• Coupling two computers to a single memory
• Large core memory (1MB)
• The eight-bit character (the "byte")
• Variable word length Standard I/O interface

Not heeding the lessons of history, microprocessor companies twenty or thirty years later "re-invented" most of these innovations.

Papers

• History of Computing Lecture - Prepared for an introductory Computer Science class about the history of computing devices, starting from the development of computing and progressing through to the late 80s. Includes nice colour slides.
•  Bye Bye Cyrix -- very interesting and insightful paper [added June 14, 1999]
• Multics History - Multics, one of the first timesharing projects.
• Charles Babbage Institute - CBI is a research center at the University of Minnesota dedicated to the preservation of the history of information processing.
• Wilkes Mauris Early Digital Computer Developments in England
• Sendov Bl. Rozov N. J.V.Atanasoff-Creator of the First Electronic Computer in the World (Windows-1251)
• Apokin I.The Nature of Innovation Process at the Stage of Creation of the First Computers (Windows-1251)
• Richards B. The Manchester Mark I The Turing-Richards Era  here is local copy
• P.-E. Mounier-Kuhn History of Computing in France A Brief Sketch
• By Maurice V. Wilkes Cmos Workstations and Servers-How Far Can Evolution and Innovation Take Us

Recommended Links

Virtual Museum of Computing - A collection of WWW hyperlinks connected with the history of computing and on-line computer-based exhibits from around the world.

German Web Computer museum. Developments and stories about computers, with descriptions of historic computers like the Altair 8800, Apple LISA, and the IBM PC. It also provides a chronology of microcomputers and personal computers from about 1974 until 1990.

History of Computing Resources - Bibliography of works dealing with computing up to 1950 by historian Brian Randell.

History of Computing Material and Links - Compiled and maintained by the editor of the Annals of the History of Computing- J.A.N. Lee.

WWW Computer Architecture Home Page[July 7, 1999]

Chronology of Digital Computing Machines by Mark Brader (Usenet posting). Many mirrors. see for example A Chronology of Digital Computing Machines (to 1952) or http://www.davros.org/misc/chronology.html

A Chronology of Digital Computing Machines (to 1952)

Computer Museum - Everything you need to know about the original, the venerable Computer Museum in Boston, U.S.A.

• The Colossus Rebuild Project A British WWII-era vacuum-tube programmable logic calculator.
• Konrad Zuse: a guided tour of his computers. The Z3 was build with relays and finished in 1941. While never used in production, it was the world's first program controlled computer, pre-dating ENIAC by two years.
• ENIAC 50th Anniversary Celebration (Events)
• ENIAC: Celebrating the birth of modern computing (Penn Printout)
• The John Vincent Atanasoff Archive
• Computer History and Development - Jones Multimedia Encyclopedia
• The History of Computing, notes from "The Machine That Changed The World"
• The National Archive for the History of Computing (UK)
• John von Neumann
• Commercial Computing Museum - Computer History Web Sites
• Smithsonian Computer History
• The History of Modern Computing In General (Zuse, Bell, Aiken, Eckert)
• History of Computers BAE 221 course notes.
• There's a supercomputing race between --- The Chickens and the Ox
• Mechanical Calculating Machines
• A Comparison Between Intel Paragon and ENIAC
• The ENIAC Papers UPenn Archives & Records Center, Index to court testimony regarding ENIAC.
• ENIAC Exhibit
• The Historical Context for the Eniac
• The Lost Museum of Sciences Computer Exhibit
• ENIAC and The Growth of Television
• Looking Back At ENIAC: Computers Hit Half-Century Mark, by Neeraja Sankaran, The Scientist V9#16, 1995.
• Landmarks in Digital Computing: The ENIAC
• ENIAC II in The Journal of the PK Institute for Information Engineering (Fantasy/Humor).
• Photo Gallery - ENIAC
• Eckert Obituary
• Information Science Hall of Fame
• Manhattan Project produced new group of superheroes ... physicists, By Kirk Saville, Fort Lauderdale Sun-Sentinel.
• First Generation Electronic Computers (1937-1953) From An Overview Of Computational Science.
• Atanasoff Obituary
• Exhibits viewable in the American History Museums Information Age Gallery
• Biography of John W. Mauchly
• The Origins and Future of the Internet: Of Secret Codes, Superhighways, and Sputnik (and ENIAC)
• History of Mathematics and Related Fields
• The Development of the Computer
• Computing The Media History Project Connections Pages
• Hobbes' Internet Timeline

• WWW Computer Architecture Home Page [July 7, 1999]

  System 360

  System-360 - Wikipedia, the free encyclopedia

  Computer History IBM 360-370-3090-390

  The IBM Journal of Research and Development recently reprinted the 1964 paper Architecture of the IBM System/360 by Gene Amdahl, Fred Brooks and G A Blaauw. (16 pages, PDF).

Microprocessors history

• A Brief History of the Microprocessor by Richard Birkby
• Chip Directory by Jaap van Ganswijk
• List of Chips 7.1 by Aad Offerman
• [Jan. 17, 2000] www.cs.uregina.ca Great Microprocessors of the Past and Present (V 11.4.3)
• COMMPUTERSEUM - Commercial Computing Museum - Preserving the History of Data Processing and Office Automation, and Promoting Related Activities.
• Computer History Assoc. of California - One of the first "grass-roots" preservation efforts. Great pages containing many more links.
• Computer History Project - Interesting material about museums and exhibits in Europe and North America.
• Computers and Emulation Page maintained by Marat Fayzullin
• History of Computing by Lexikon Publishing - An encylopaedia of the people and machines that made computing history.
• History of Microcomputers - Chronology of Events." - Rich in references.
• Software Archives - Amsterdam (microcomputer oriented)
• United States Army Historic Computer Images

Last modified: June 05, 2008