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

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

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

News Recommended Links System 360 Microprocessors CPU History Papers Architecture issues  Etc

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  to certain extent is an artistic object and we can legitimately talk about beautiful/elegant and ugly CPU instruction sets. 

CPU instruction set should be considered to be 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 the first modern instruction set. It was actually 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:

  1. The 8-bit byte (against financial pressure during development to reduce the byte to 4 or 6 bits)
  2. Byte-addressable memory (as opposed to word-addressable memory)
  3. 32-bit words
  4. Variable length instructions (from 16  to 32 bit). Instruction counter is incremented depending of the type of instruction
  5. Two's complement arithmetic
  6. Segmented and paged memory  with memory protection based of memory keys.
  7. Commercial use of microcoded CPUs
  8. The IBM Floating Point Architecture (until superseded by the IEEE 754-1985 floating-point standard, 20 years later)
  9. The EBCDIC character set
  10. Virtualization extensions. 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 were also still quite interesting as they were the architecture on which early Unix was implemented and you need to understand it in order to read Lions book. Actually I know that in 2000 there were still production PDP 11 servers in some publishing companies in the USA !

Alpha was one of the early 64 bit architectures but it dies quickly in Compaq hands after DEC acquisition. UltraSparc is another early RISK architecture and probably the only one of early architectures that survived the turn of the century.

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 or GHz 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/L3 trying to capitalize of the locality of references in most programs. But there is only so much you can do with caching, so increasing speed and lowering latency of memory has more dramatic effects on the performance then any increases in CPU speed (outside small number of tasks that fit cache).

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 half gigabyte 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:

According to Richard Birkby  ( A Brief History of the Microprocessor ) SPARC was one 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


Top updates

Softpanorama Switchboard
Softpanorama Search


NEWS CONTENTS

Old News ;-)

[Jun 04, 2010] Intel's tiny problem - Jun. 3, 2010 By David Goldman

June 3, 2010 | CNNMoney.com

Decades of booming personal computer sales helped Intel become a chipmaking behemoth, but consumers' rapid shift away from PCs may leave the tech giant out in the cold.

As Intel's old marketing campaign proclaimed, the company's chips are "inside" practically every kind of computer, from PCs to Macintoshes to netbooks. But PCs are yesterday's news. Mobile Internet devices like smart phones and tablets are where all of the growth is but Intel (INTC, Fortune 500) hasn't been able to gain much traction.

Where Intel has so far failed, a little-known British company called ARM has had roaring success. ARM is to mobile devices what Intel is to computers -- the company develops and licenses the basic chip designs for practically all of the world's cell phones, smart phones and Apple's (AAPL, Fortune 500) iPad.

Tech analysts left and right are proclaiming that the mobile device market will outpace or perhaps even replace the PC market in the next five years. In fact, the market grew 56.7% during the first quarter, according to IDC.

Could a tiny British company that took in just less than $500 million in sales last year really be in a better position to take advantage of that forecasted growth than Intel, which had over $35 billion in revenue during the same period?

"Few companies have championed and invested in the shift to wireless computers and PC-like devices like Intel has," said Intel spokesman Bill Kircoss.

Analysts also say it's premature to dismiss Intel. "ARM is ahead right now, but I've become smart enough to know that Intel can't be counted out," said John Bruggeman, CMO of Cadence Design Systems. "Intel will figure it out, or it'll spend its way out."

How we got here

Next to Microsoft (MSFT, Fortune 500), Intel has perhaps been the greatest benefactor of the PC boom of the past three decades. Intel's patent on the x86 processor, which is required to run Windows, helped it become the biggest chipmaker in the world. Intel designed its chips for performance and power, making PCs lightning-fast and able to perform multiple complex tasks simultaneously.

ARM, meanwhile targeted a different, smaller market. By designing chips that use as little power as possible, ARM made its way into practically every cell phone on the market (about 20 billion mobile devices over the past 19 years, according to the company). Unlike Intel, ARM doesn't actually make chips, but licenses designs to 220 companies around the world, including giants like Qualcomm (QCOM, Fortune 500), Texas Instruments (TXN, Fortune 500), Nvidia (NVDA), Samsung and Apple.

Both companies were humming along until Apple introduced the iPhone in the summer of 2007. The iPhone was years ahead of any other phone on the market at the time, allowing users to carry a device in their pockets that performed PC tasks.

"There was a huge technological disruption that took place at the launch of the iPhone," said Bruggeman. "Now, mobile is the high volume category and it's the only one that matters. The only question is will it be Intel-based or ARM-based?"

Because of its vast experience in the mobile sector, ARM won the contract to design the iPhone's processor and has since appeared in a large number of smart phones. Apple's iPad also uses an ARM-licensed chip.

Atom bomb

The Intel vs. ARM battle is far from over. Mobile devices are rapidly improving, but none yet offer the same deep, rich Internet experience of a PC or run all of the complex tasks of a computer.

Next year, Intel plans to unveil a new "Atom" mobile device processor (code named "Moorestown"), which Intel thinks can outperform competitors and help it give ARM a run for its money.

First-generation Atom chips can be found in just about every netbook on the market. Though Intel offers the chips for smart phones, most devices with Intel inside only run the unsuccessful MeeGo platform. Intel so far has not been able to tap into the rampant success of Apple's iPhone OS or Google's (GOOG, Fortune 500) Android platform.

But the Atom 2 might change that. Though experts say Atom chips won't soon be found in an iPhone, Intel recently demonstrated its Moorestown chip seamlessly running Android 2.1 at the Computex technology expo in Taipei.

"In just the past 30 days alone, we've expanded this chip line to cars, TVs, tablets and smartphones and plan to keep bringing new, and even more power-sipping Atoms to market," said Intel's Kircoss.

Even ARM admits that its market dominance doesn't mean that it has won.

"People don't care what's underneath, they just want to buy stuff that they think is cool," said Bob Morris, director of mobile computing at ARM. "Intel eventually will be successful in this area, though they'll be one of many."

But there's one potential hang up for Intel: Compared to its traditional PC chips, the profit margins for the Atom chip are atrocious. A small number of analysts even suggested that Intel would like the mobile market to go away.

"Maybe Intel doesn't care who wins the mobile space," said Phani Saripella, analyst at Primary Global Research and a former Intel manager. "It might be better off defending its turf [on the higher end devices]."

[Jun 04, 2010] Intel vs. AMD gets interesting again - Big Tech - Fortune Tech

If AMD has indeed turned a corner, much of the credit will go to Meyer, an understated engineer who took the reins two years ago. Until he arrived, AMD's fight with Intel had begun to take on near-religious overtones (see Apple (AAPL) vs. Microsoft (MSFT) in the 1990s); former CEO Hector Ruiz rarely missed an opportunity to call out Intel's alleged wrongdoings.

Meyer has taken a subtler approach. He began talking more diplomatically about Intel (INTC), and opened up conversations with the company. Then late last year, he made a move that would have been almost unthinkable under previous leadership: He settled AMD's antitrust complaints with Intel, to the tune of $1.25 billion.

The settlement rolled back AMD's status as head anti-Intel cheerleader in the courts. But from Meyer's perspective, it also brought several benefits: The settlement removed a costly distraction for AMD management, and supplied the hefty cash payment from Intel, which Meyer could immediately use to settle AMD debts.

It also gave PC makers a reason to consider using more of his chips, since Intel pledged not to punish customers who also bought from AMD. (Intel said it never did that in the first place.) "We never expected an instantaneous night-and-day change. There's a mindset amongst OEMs that's formed over 20 years," Meyer told me. "But I'm hopeful that with every quarter that goes by, we'll see opportunities that we used to not see."

Judging by the reception PC makers are giving AMD's latest chips, things are coming together. HP told reporters that AMD's advances in battery life made the chips good enough to include in more laptops. During a recent meeting with Acer, I was shocked at the number of AMD-based models the Taiwanese PC maker is rolling out this month. It's going from a netbook lineup that was Intel-only to one with two AMD-based machines and three Intel; not quite parity, but close.

Even so, Intel doesn't have to worry much. Industry analysts generally agree that AMD's current chip lineup and manufacturing capabilities are not as strong as Intel's; Intel leads in battery life and raw performance, which allows it to charge a premium for its chips.

Bob, Brampton, Ontario

Owen, you talk about the downward spiral of price but the fact is that it's not a matter of AMD charging too little, it's a matter of Intel charging too much. There is no reason why Intel charges what they do except for pure greed. They know that people buy Intel because it is advertised, familiar, etc. AMD stopped being a "me-too" company when Intel paid them licencing fees to use AMD's x64 architecture. AMD is the one who is responsible for the 64-bit x86 CPU, not Intel. Intel could have released the first x86-64 CPU but they saw no reason to. They were making good money and don't give a damn about the consumer, they only want to maximize profits. Right now, there is no reason for private consumers to purchase Intel CPUs at all because for all tasks that the home individual would perform on a PC, including high-end gaming, AMD makes a CPU that will do the same task with equal or better performance compared to Intel for less money. The i7 is a chip that was designed for high-end machine virtualization and massive computational functions that only commercial software like video encoders can really take advantage of. The home user would never see a difference except saving enough money on a home system that they could also afford to go to the Dominican on vacation that year. I'll take the equal-or better computer and the trip, thank you very much. Winters in Canada suck...lol

[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. 

[May 15, 2006] Reviewing the mainframe  by Paul Murphy 

ZDNet.com

The word "mainframe" originally referred to the physical layout of the IBM System 360 series because the primary CPU was mounted in a separate wiring cabinet or "main frame." Today's mainframe, although a direct descendant of that 360 in terms of software, differs dramatically from it in internal architecture.

That divergence started in the late nineties when IBM decided to standardize its AIX, OS/400, and zOS hardware on the same basic components and same basic plug together design. Thus today's z9 "enterprise" and "business" class servers look a lot like older iSeries and pSeries machines internally and are really distinguished from those at the hardware level only in terms of packaging and accommodations made to legacy mainframe software and related ideas.

The latest z9 series CPU board, called an MCM in IBMese, is embedded in what IBM calls "a book" and comes with up to 16 enabled CPU cores (aka processing units) and up to 128GB of enabled memory. Single z9 machines now max out at four books, or 64 CPU cores. Of these, however, at least two cores per board have to be dedicated to "storage assist processing" (i.e. I/O support), and at least two per machine have to be set aside as spares -i.e. the machine offers a maximum of 54 processing units, and 512GB of accessible memory.

The CPU used is the 1.65Ghz dual core Power5+ with some changes in the enabling firmware and socket wiring to support traditional mainframe features like CPU sparing and up to 40MB of shared cache per MCM. Interconnects across the MCM have relatively low latency, enabling dual, eight-way, SMP blocks in the pSeries and allowing zOS to co-ordinate up to four, eight way, blocks to form a 32 processor virtual machine - the largest logical partition yet supported on the IBM mainframe.

The z9 supports up to 32 way clustering via processor dedication. It also offers a very wide range of external I/O capabilities built around a maximum of 64 standardized ("self timing") interface boards each capable of handling up to 2.7GB/Sec in flows from plug in Ethernet, disk, or other controllers.

All of this comes in a nicely packaged "mainframe" drawing from 6 to 19 KVA and typically taking up about a square meter of floor space.

In many ways this is an entirely admirable machine: physically small, relatively power efficient, reasonably fast for many small tasks done in parallel; capable of connecting to a lot of legacy storage; and, capable of supporting hot plug replacement for almost everything from I/O devices to processor books.

IBM stresses both reliability and virtualization in its sales presentations on this product line. Of these two, the reliability claims are mostly a case of saying what the customers want to hear - because, in reality, things like having spare CPUs on line are just costly hangovers from the System 360 and there's nothing otherwise significant in the architecture that isn't matched in IBM's other high end Power products.

Notice that this doesn't mean that Z9 machines aren't highly reliable, they are; but the reliability gains over the comparable AIX and OS/400 machines are due to the management methods and software that go with the box, not the hardware.

The heart of the system lies in its virtualization capabilities. The maxed out z9 can be broken up into 60 logical partitions each of which looks like an entire machine to its operating systems code. Load VM on one of these and it, in turn, can host a significant number of concurrent guest operating systems like Linux or one of the older 360 OS variants.

This structure reflects the machine's data processing heritage in which it assumed that all jobs are batch (even the on-line ones), all batches are computationally small and severable, and real work consists of sequential read, manipulate, and write operations on each of many very small data sets. Thus most jobs need fractional CPU shares, eight way SMP more than suffices for the largest jobs, and the use of logical partitioning and guest operating systems offers a proven way to both enforce job severability for scheduling and to protect one job from another during run-time.

This role conceptualization also has many consequences for hardware and software licensing. In particular software is usually licensed by the processor count and relative performance - meaning that limiting licensed code to a particular logical partition size or resource constrained guest operating system reduces costs significantly. Since it's difficult to apply this logic to software IBM wants to promote or stuff that can use the whole machine, IBM has developed licenses based on specified uses for processors. Thus the IFL (integrated facility for Linux) is an ordinary CPU licensed only to run Linux, while the zAAP (zSeries Application Assist Processor) is one licensed only to run JAVA, and SAPs (CPUs used as storage assist processors) don't usually count for licensing.

An ultra-low end machine, with a fractional single CPU license, starts at about $100,000 before storage and application licensing.

A maxed out, 54 processor, 1.65Ghz, 2094-754 z9 "enterprise" machine with 5124GB of accessible memory is thought to cost about $22.5 million at list plus about $92,700 per month in maintenance before software and storage.

According to an IBM TPC filing, an IBM p5-595 with AIX, 2048GB of accessible RAM, and 64 cores at 1.9Ghz lists at about $12.4 million -or about 48% ($10 million) less than the mainframe.

Similarly, list price on an IBM 9133-1EB 550Q rackmount P550 with eight cores and 16GB of memory is about $37,100. In other words, four racks filled with a total of 64 of these machines would provide about twice the total memory offered by the z9, about eight times the total CPU resource, about eight times the total I/O bandwidth, four more "hard wired" logical partitions, and just over $20 million (90%) in change.

Tomorrow I'm going to talk about running Linux on the z9, but the conundrum to ponder here is a simple one: if the value of the mainframe lies in its virtualization capabilities, why doesn't the 64 way rackmount offer a better solution?

Virtualization exists in the AIX line as well

Re: your last paragraph "...the value of the mainframe lies in its virtualization capabilities", I have to point out that fractional cpu virtualization exists in the AIX line as well (probably an inheritance from the z series).

I'm not an AIX pro - my experience is dated, but I did get a chance to evaluate a "Regatta" 690 high end server for a few months. One of the truly interesting abilities was its use of HACMP with virtual machines. You could create a "stub" environment with a fraction of a CPU -- just enough to keep the OS running -- and then on failover, it (as the failover target) would be dynamically expanded to a pre-defined amount of cpu, memory, interfaces, etc. Think of the expense of a typical active-passive cluster and you'll see the appeal. This was very efficient, very slick, and IBM got there first.

It's not advocacy of IBM, just acknowledgement of a nice feature set. But I also think it runs against your comment the other day about virtualization as "a palliatve for shoddy systems design and sloppy thinking." Too broad a characterization, I think.

(Ok, now that I'm contrarian, does this make me "hugely valuable" in the "loyal opposition" ? : )

[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.
Panel 1 -- 1939-1945 Panel 2 -- 1946-1949

Panel 3 -- 1950-1955

Panel 4 -- 1956-1960

Panel 5 -- 1961-1965

Panel 6 -- 1966-1970

Panel 7 -- 1971-1975

Panel 8 -- 1976-1983

Panel 9 -- 1984-1989

Panel 10 -- 1990-1996

Panel 11 -- 1997-1999

[ Feb 06, 2002] ***** 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

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:

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


Papers


Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

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.


Microprocessors history



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Created May 16, 1996; Last modified: February 19, 2014