Great Microprocessors of the Past and Present
J. Bayko
from the very beginning to today. Not necessarily the first of their kind,
or the best.
Anyway, I've done my best to be accurate, but I'm sure there are
dozens of bugs in it. I'd appreciate comments and corrections (I'll try
and add whatever feedback I get into the next version).
John Bayko.
---
Great Microprocessors of the Past and Present (V 3.0.0)
Section One: Before the Great Dark Cloud.
---------------------------
Part I: The Intel 4004 (1972)
The first single chip CPU was the Intel 4004, a 4-bit processor meant for
a calculator. It processed data in 4 bits, but its instructions were
8 bits long. Internally, it featured eight 4 bit registers which acted as an
internal evaluation stack. The Stack Pointer pointed to one of these
registers, not a memory location. There were also sixteen 4-bit general
purpose registers
The 4004 had 46 instructions. Intel created an 8-bit version of this, the
8008.
[for additional information, see Appendix A]
Part II: The Intel 4040 and 8080
The 4040 was compatible with the 4004 instruction set - the 4040 had 60
instructions, which included the 45 4004 instructions. The 8080 was similar to
the 4040, except being 8 bits wide.
The 8080 had a 16 bit address bus, and an 8 bit data bus. Internally it
had six 8 bit registers, a 16 bit stack pointer (the stack was stored in
memory, not in an internal register set), and 16 bit program counter. It also
had several I/O ports - 512 of them, so I/O devices could be hooked up without
taking away or interfering with the addressing space.
Part III: The Zilog Z-80 - End of the 8-bit line (July 1976)
The Z-80 was intended to be an improved 8085, which was an improved 8080,
and it was - vastly improved. It also used 8 bit data and 16 bit addressing,
and could execute all 78 of the 8085 op codes, but included 80 more,
instructions that included 1, 4, 8 and 16 bit operations and even a block move
instruction. The register set was doubled, with two banks of registers that
could be switched between. This allowed fast operating system or interrupt
context switches.
But the thing that really made the Z-80 popular was actually the memory
access - the CPU generated it's own RAM refresh signals, which meant easier
design and lower system cost. That and it's 8085 compatability, and CP/M, the
first standard microprocessor operating system, made it the first choice of
many systems.
Part IV: The 650x, Another Direction (1975-ish)
Shortly after the 8080, MOS Technologies introduced the 650x series,
including the 6502 used in Commodores, Apples and Ataris. Steve Wozniak
described it as the first chip you could get for less than a hundred dollars.
Unlike the 8080 and its kind, the 6502 had very few registers. It was an
8 bit processor, with 16 bit address bus. Inside was one 8 bit data register,
and two 16 bit index registers and a 16 bit stack pointer. It used these
index and stack registers effectively, with more addressing modes, including
a fast zero-page mode that accessed memory addresses from address 0 to 255
with an 8-bit address that speeded operations (it didn't have to fetch a
second byte for the address).
As a side point, Apples, which were among the first computers introduced,
have continued, now using the 65816, which is compatable with the 6502, but
has been expanded to 16 bits. The Apple II line, which actually includes the
Apple I, is the longest existing line of microcomputers.
Back when the 6502 was introduced, RAM was actually faster than CPUs, so
it made sense to optimize for RAM access rather than increase the number of
registers on a chip.
Part V: The 6809, extending the 650x
The 6800 from Motorolla was essentially the same design as the 6502, but
with some tweaking here and there. But the successor was a major advance - at
least relatively.
The 6809 had two 8 bit accumulators, rather than one in the 6502, and
could combine them into a single 16 bit register. It also featured two index
registers and two stack pointers, which allowed for some very advanced
addressing modes. The 6809 was object compatible with the 6800, even though
the 6800 had 78 instructions and the 6809 only had around 59. Some
instructions were replaced by more general ones which the assembler would
translate, and some were even replaced by addressing modes.
Other features were one of the first multiplication instructions of the
time, 16 bit arithmatic, and a special fast interrupt. But it was also highly
optimized, gaining up to five times the speed of the 6800 series CPU.
The 6800 lived on as well, becoming the 6803, which included ROM, some
RAM, a serial I/O port, and other goodies on the chip. It was meant for
embedded controllers, where the part count was to be minimized. The 6803 led
to the 68HC11, and that was extended to 16 bits as the 68HC16. But the 6809
was a much faster and more flexible chip, particularly with the addition of
the OS-9 operating system.
Of course, I'm a 6809 fan myself...
As a note, Hitachi produced a version called the 6309. Compatible with the 6809, it added 2 new 8-bit registers that could be added to form a second 16 bit register, and all four 8-bit registers could form a 32 bit register. It also featured division, and some 32 bit arithmatic, and was generally 30% faster in native mode. This information, suprisingly, was never published by Hitachi.
Part VI: Advanced Micro Devices Am2903, a few bits at a time
Bit slice processors were modular processors. Mostly, they consisted of an
ALU of 1, 2, 4, or 8 bits, and control lines (including carry or overflow
signals usually internal to the CPU). Two 4-bit ALUs could be arranged side by
side, with control lines between them, to form an ALU of 8-bits, for example.
A sequencer would execute a program to provide data and control signals.
The Am2903, from Advanced Micro Devices, was a popular 4-bit-slice
processor. It featured sixteen 4-bit registers and a 4-bit ALU, and operation
signals to allow carry/borrow or shift operations and such to operate across
any number of other 2903s. An Am2910 address sequencer could provide control
signals with the use of custom microcode in ROM.
Section Two: Forgotten/Innovative Designs before the Great Dark Cloud
--------------------------------------------------------
Part I: RCA 1802, wierdness at its best (1974)
The RCA 1802 was an odd beast, extremely simple and fabricated in CMOS,
which allowed it to run at 6.4 MHz, very fast for 1974. It was an 8 bit
processor, with 16 bit addressing, but the major features were it's extreme
simplicity, and the flexibility of it's large register set. Simplicity was the
primary design goal, and in that sense it was one of the first RISC chips.
It had sixteen 16-bit registers, which could be accessed as thirty-two
8 bit registers, and an accumulator D used for arithmatic and memory access -
memory to D, then D to registers, and vice versa, using one 16-bit register
as an address. This led to one person describing the 1802 as having 32 bytes
of RAM and 65535 I/O ports. A 4-bit control register P selected any one
general register as the program counter, while control registers X and N
selected registers for I/O Index, and the operand for current instruction. All
instructions were 8 bits - a 4-bit op code (total of 16 operations) and 4-bit
operand register stored in N.
There was no real conditional branching, no subroutine support, and no
actual stack, but clever use of the register set allowed these to be
implimented - for example, changing P to another register allowed jump to a
subroutine. Similarly, on an interrupt P and X were saved, then R1 and R2 were
selected for P and X until an RTI restored them.
Apart from the COSMAC microcomputer kit, the 1802 saw action in some
video games from RCA and Radio Shack, and legend has it the chip is the heart
of the Voyager and Viking probes. One reason for this is that the 1802 was
also fabricated mounted on saphire, which leads to radiation and static
resistance, ideal for space operation.
A later version, the 1805, was enhanced, giving it several Forth language
primitives, which could explain the high usage of Forth in control
applications.
Part II: Fairchild F8, Register windows
The F8 was an 8 bit processor. The processor itself didn't have an address
bus - program and data memory access were contained in separate units, which
reduced the number of pins, and the associated cost. It also featured 64
registers, accessed by the ISAR register in cells (windows) of eight, which
meant externam RAM wasn't always needed for small applications. In addition,
the 2-chip processor didn't need support chips, unlike others which needed
seven or more.
The use of the ISAR register allowed a subroutine to be entered without
saving a bunch of registers, speeding execution - the ISAR would just be
changed. Special purpose registers were stored in the second cell (regs 9-15),
so the first window would be used for global variables.
The windowing concept was useful, but only the register pointed to by the
ISAR could be accessed, limiting usefulness - to access another register the
ISAR was incremented or decremented through the window.
Part III: SC/MP, early advanced multiprocessing (April 1976)
The National Semiconductor SC/MP, (nicknamed "Scamp") was a typical
well-designed 8 bit processor. It featured 16 bit addressing, with 12 address
lines and 4 lines borrowed from the data bus (it was common to borrow lines
from the data bus for addressing). Internally, it included three index
registers.
The unique feature was the ability to completely share a system bus with
other processors. Most processors of the time assumed they were the only ones
accessing memory or I/O devices. Multiple SP/MPs could be hooked up to the
bus, as well as other intelligent devices, such as DMA controllers. A control
line could be chained along the processors to allow cooperative processing.
This was very advanced for the time, compared to other CPUs. However, the
SC/MP had no stack or subroutine instructions, though a stack could be
emeulated to some degree.
Part IV: F100-L, a self expanding design
The Ferranti F100-L was designed by a British company for the British
Military. It was an 8 bit processor, with 16 bit addressing, but strangely it
could only access 32K of memory.
The unique feature of the F100-L was that it had a complete control bus
available for a coprocessor that could be added on. Any instruction the F100-L
couldn't decode was sent directly to the coprocessor for processing.
Applications for coprocessors at the time were limited, but the idea is still
used in modern processors. This coprocessor design was adapted by other
processors, such as the National Semiconductor 16000 series, which included
FPU, MMU, and other coprocessors that could just be added to the CPU's
coprocessor bus in a chain. Other units not forseen could be added later.
The NS 16000 series was the predecessor of the Swordfish processor,
described later.
Part V: The Western Digital 3-chip CPU (June 1976)
The Western Digital MCP-1600 was probably the most flexible processor
available. It consisted of at least four separate chips, including the control
circutry unit, the ALU, two or four ROM chips with microcode, and timing
circuitry. It doesn't really count as a microprocessor, but neither do bit-slice processors.
The ALU chip contained twenty six 8 bit registers and an 8 bit ALU, while
the control unit supervised the moving of data, memory access, and other
control functions. The ROM allowed the chip to function as either an 8 bit
chip or 16 bit, with clever use of the 8 bit ALU. Even more, microcode allowed
the addition of Floating Point routines, simplifying programming (and possibly
producing a Floating Point Coprocessor).
Two standard microcode ROMS were available.
Part VI: Intel 8048, Harvard bus
The MCS-48 was a microcontroller familly, not a single microprocessor, but
did feature a separate data and program bus, known as Harvard Architecture. In theory, It allows simultaneous reading of data while the next instruction is fetched, allowing an increase in speed. In this case, its purpose was to allow different size data (RAM) and program (usually ROM) memory.
In other aspects as well, the MSC-48 series was small, featuring only a
single 8 bit register, around 4K of program memory, and 256 bytes of data
memory (organized in register pages, like the F8 processor). It did have stack
and subroutine operations, but the 256 byte memory limit made that limited.
Section Three: The Great Dark Cloud Falls: IBM's Choice.
----------------------------------------
Part I: TMS 9900, first of the 16 bits (June 1976)
One of the first true 16 bit microprocessors was the TMS 9900, by Texas
Instruments. It was designed as a single chip version of the TI 990
minicomputer series, much like the 12 bit Intersil 6100 was a single chip
PDP-8E, used in the DECmate, DEC's competition for the IBM PC. Because of
this, the TMS 9900 had a mature, well thought out design.
It had a 15 bit address space and two internal 16 bit registers. One
unique feature, though, was that all its registers were actually kept in
memory - this included stack pointers and the program counter. A single
workspace register pointed to the register set in RAM, so when a subroutine
was entered or an interrupt was processed, only the single workspace register
had to be changed - unlike some CPUs which required dozens or more register
saves before acknowleging a context switch.
This was feasable at the time because RAM was faster than the CPUs. A few
modern designs, such as the INMOS Transputers, use this same design using
caches or rotating buffers, for the same reason of improved context switches.
Some chips of the time, such as the 650x series had a similar philosophy,
using index registers, but the TMS 9900 went the farthest in this direction.
That wasn't the only positive feature of the chip. It had other good
interrupt handling features and very good instruction set. In typical
comparisons with the Intel 8086, the TMS9900 had smaller and much faster
programs. The only disadvantage was the small address space.
Despite the very poor support from Texas Instruments, the TMS 9900 had
the potential at one point to surpass the 8086 in popularity.
Part II: Zilog Z-8000, another direct competitor.
The Z-8000 was introduced not long after the 8086, but had superior
features. It was basically a 16 bit processor, but could address up to 23
bits in some versions by using segmentation. The segment simply held the
upper 7 bits for the register. There was also an unsegmented version, but both
could be extended further with an additional MMU that used paging and 64
segment registers.
Internally, the Z-8000 had sixteen 16 bit registers, but register size
and use were exceedingly flexible. The Z-8000 registers could be used as
sixteen 8 bit registers (only the first half were used like this), sixteen
16-bit registers, eight 32 bit registers, or four 64 bit registers. They were
all general purpose registers - the stack pointer was typically register 15,
with register 14 holding the segment (you could just access it as a 32 bit
register for address calculations.
The Z-8000 featured two modes, one for the operating system and one for
user programs. The user mode prevented the user from messing about with
interrupt handling and other potentially dangerous stuff.
Finally, like the Z-80, the Z-8000 featured automatic RAM refresh
circuitry. Unfortunately it was somewhat slow, but the features generally made
up for that.
A later version, the Z-80000, was expanded to 32 bits internally.
Part III: Motorolla 68000, a refined 16/32 bit CPU
The 68000 was actually a 32 bit CPU internally, but 16 bit externally for
lower costs. It also included 24 bit addressing, without the use of segment
registers. That meant that a single directly accessed array or structure could
be larger than 64K in size. Addresses were computed as 32 bit, but the top 8
bits were cut to reduce costs. No segments made programming the 68000 easier
than competing processors.
Looking back, it was logical, since most 8 bit processors featured direct
16 bit addressing without segments.
The 68000 had sixteen registers, split into data and address registers.
One address register was reserved for the Stack Pointer. Both types of
registers could be used for any function except for direct addressing. Only
address registers could be used as the source of an address, but data
registers could provide the offset from an address.
Like the Z-8000, the 68000 featured a supervisor and user mode. There
were two Stack Pointers, one for supervisor and one for user mode. The Z-8000
and 68000 were similar in capabilities, but the 68000 had 32 bit units
internally, making it faster and eliminating forced segmentations. It was
designed for expansion, including specifications for floating point and string
operations that weren't implimented on chip until the 68040.
Part IV: Intel 8086, IBM's choice (1978)
The Intel 8086 was based on the design of the 8085, but with enhancements
and as a 16 bit processor. It had a similar register set, and featured a 6
byte prefetch instruction queue for additional speed.
It featured four 16 bit general registers, which could be accessed as
eight 8 bit registers or four 16 bit index registers, and four 16 bit segment
registers.
The segment registers allowed the CPU to access 1 meg of memory through
an odd process. Rather than just supplying missing bytes, as most segmented
processors, the 8086 actually added the segment registers ( X 16, or shifted
left 4 bits) to the address. As a strange result, segments overlapped, and it
was possible to have two pointers to two different memory locations with the
same value, or two pointers with different values pointing to the same
location.
Although this was largely acceptable for assembly language, where control
of the segments was complete (it could even be useful then), in higher level
languages it caused constant confusion. Even worse, this made expanding the
address space to more than 1 meg difficult. A later version, the 80386,
expanded the design to 32 bits, and 'fixed' the segmentation, but required
multiple modes (supressing the new features) for compatability.
So why did IBM chose the 8086 when most of the alternatives were so much
better? Apparently IBM's own engineers wanted to use the 68000, and it was
used later in the forgotten IBM Instruments 9000 Laboratory Computer, but IBM
already had rights to manufacture the 8088 (an 8086 with 8-bit external data
bus for fewer pins), in exchange for giving Intel the rights to it's bubble
memory designs. Apparently IBM was using 8088s in electric typewriters or
word processors of some sort.
Intel bubble memory was on the market for a while, but faded away as
better and cheaper memory technologies arrived.
Section Four: Unix and RISC, a New Hope
-------------------------
Part I: SPARC, an origional RISC
SPARC, or the Scalable Processor ARChitecture was designed by Sun
Microsystems for their own use. Sun was a maker of workstations, and used
standard 68000-based CPUs and a standard operating system, Unix. Research
versions of RISC processors had promised a major step forward in speed, but
existing manufacturers were slow to introduce a RISC type processor, so Sun
went ahead and developed its own. In keeping with their open philosophy, they
licensed it to other companies, rather than manufacture it themselves.
SPARC was not the first RISC processor. The MIPS R2000 came before it,
and so did the Hewlitt-Packard Precision Architecture RISC CPU. However,
SPARC embodied more of the fundimental RISC philosophies.
SPARC follows the RISC philosophy rather literally, even forgoing useful
multiple cycle instructions like multiply and divide. SPARC contains 128
registers, compared to 16 for previous CISC designs, and windows them. At each
time 32 registers are available. 8 come from the calling process, 8 are local
variables, and 8 are used to pass arguments to the next function, and 8 are
global variables. A function call simply slides the window down eight
registers without requiring register saves and loads, resulting in a function
call in as little as 1 cycle. Only when going beyond the top or bottom of the
register stack is it necessary to load and save registers. In addition, SPARC
is pipelined for performance.
SPARC has undergone revisions, and now has multiply and divide
instructions. It is scalable mainly because the register stack can be
expanded, for fewer loads and saves between functions, but has the
disadvantage during interrupts and context switches, when the entire 128
register set has to be written to memory. Function calls are far more
frequent than context switches, so this is usually a plus, but can be a
problem in some designs dealing with interrupts. In this case, the register
set can be scaled down for efficiency. Unfortunately, the register windows
themselves limit the maximum clock speed of the processor.
SPARC is not a chip, but a specification, and so there are various
designs of it. Most are 32 bits, but there are specifications for 64 bit
and superscalar versions. SPARC was submitted to the IEEE society to be
considered for the P1754 microprocessor standard.
Part II: Acorn ARM, RISC for home use (1985)
ARM (Advanced RISC Microprocessor) is often praised as one of the most
elegant modern processors in existance. It was meant to be "MIPs for the
masses", and designed as part of a family of chips (ARM - CPU, MEMC - MMU and
DRAM/ROM controller, VIDC - video and DAC, IOC - I/O, timing, interrupts,
etc), for the Archimedes home computer (multitasking OS, windows, etc). It's
made by VLSI Technologies Inc.
The origional ARM2 was 26 bits, but the newer ARM6xx spec is 32 bits. It
has user, supervisor, and various interrupt modes (including 26 bit modes for
ARM2 compatability) and only 16 registers (many registers are shadowed in
other modes for speed, to avoid saving during interrupts, for example). The
ARM series consists of the ARM6 CPU core, which can be used as the basis for a
custom CPU, the ARM60 base CPU, and the ARM600 which also includes 4K cache,
MMU, write buffer, and coprocessor interface. It can also be big- and
little-endian.
A unique feature of ARM is that every instruction features a 4 bit
condition code (including 'never execute'). This easily eliminates many
branches and can speed execution. Every instruction has a bit to indicate if
condition codes should be set - an instruction can set them, and several
intervening ininstructions can execute before the codes are used. Addressing
also features a very useful mode (base register indexed by index register
shifted by a constant - ra + rb << k) found in few other processors.
The ARM hasn't had the development put into it that others have, so there
aren't superscalar or superpipelined versions, and the clock rate is not
breathtaking. However it wasn't meant to break speed records, and is a very
elegant, fast and low cost CPU.
Part III: Motorolla 88000, a conservative RISC
A design that is typical of most current RISC processors is the Motorolla
88000 (Originally named the 78000). It is a 32 bit processor with Harvard
architecture (separate data and instruction buses), for faster operation. Each
bus has a separate cache, so simultaneous data and instruction access doesn't
conflict. It is similar to the Hewlett Packard Precision Architecture in
design, though slightly more elegant.
The chip contains thirty two 32 bit registers, and is organized with
separate function units internally - an ALU and a floating point unit in the
88100 version. Other special function units, such as graphics, vector
operations, and such can be added to the design to produce a custom design for
customers. Additional ALU and FPU units can allow a superscalar operation of
the CPU (as in the 88110 version, for example). The function units of the
88000 share the same register set, while most chips have separate register
sets for the ALU and FPU.
The ALU typically operates in 1 cycle, but it or the FPU can take several
clock cycles to complete an addition or multiplication. For performance, the
units are pipelined, so one instruction can be issued each cycle, with the
result appearing five or seven cycles later. To keep track of this latency,
the 88000 has a scoreboard register which keeps track of registers waiting for
results, and ensures the result arrives before operation continues. If R4 is
awaiting the result of a multiplication, and the next instruction tries to
save R4 to memory, the save operation will halt while the FPU finishes its
job. In the superscalar 88110, the result from one ALU can be fed directly
into another, saving an execution cycle.
The more advanced 88110 version can speculatively execute conditional
branches in the pipeline. If the speculation is true, there is no branch delay
in the pipeline. Otherwise, the operations are rolled back from a history
buffer, and the other fork of the branch is taken, and the loss is the same as
for a regular pipelined processor.
Part IV: DEC Alpha, Designed for the future
The DEC Alpha architecture is designed, according to DEC, for a
operational life of 25 years. It doesn't contain particular innovations
(although the PALcall operation is unusual), but is an elegant blend of
features, selected to ensure no obvious limits to future performance - no
special registers, etc.
It is a 64 bit chip that doesn't support 8- or 16-bit operations, but
allows conversions, so no functionality is lost (Most processors of this
generation are similar, but have instructions with implicit conversions).
Alpha 32-bit operations differ from 64 bit only in overflow detection. Oddly,
Alpha does not provide a divide instruction.
One reason for Alpha is to replace DEC's two previous architectures - the
VAX and MIPS CPUs. To do this, the chip provides both IEEE and VAX floating
point operations. It also features a Privleged Architecture Library calls, a
set of programmable macros written in the Alpha instruction set, similar to
the programmable microcode of the Western Digital MCP-1600 or the AMD Am2910
CPUs. It provides support of various operating systems - VMS, Unix or
Microsoft NT.
Alpha was also designed for the future, including superscalar,
multiprocessing, and high speed clock. Because of this, superscalar
insturcions may be reordered and trap conditions are imprecise. Special
instructions are available to control both occurrences when needed. SPARC also
has a specification for instruction ordering.
Section Five: Real Burnin' Chips
------------------
Part I: Intel 860, "Cray on a Chip"
The Intel 860 wasn't Intel's first RISC chip - that was the 960, but the
960 was slow, and better suited for embedded control applications. The 860 is
one of the more impressive chips currently available, able at top speed to
perform close to 66 MFLOPS at 33 MHz, compared to a more typical 5 or 10
MFLOPS.
The 860 has several modes, from regular scaler mode to a superscaler mode
that executes two instructions per cycle and a pipelined mode that can use
the entire 8K data cache as a vector register, in the same way that
supercomputers like Crays do.
The 860 is a 64 bit processor essentially - though it normally uses thirty
two 32 bit registers it has sixteen 64 bit floating point registers. It
contains not only an integer ALU but a FPU, and even more unusual, a 3-D
graphics unit that performs lines, Gouraud shading, Z-buffering for hidden
line removal, and other operations, all in conjunction with the FPU. It has
separate instruction and data busses, and can access 4 G of memory, with
segments. It also includes a Memory Management Unit for virtual storage.
In a single cycle, the 860 can do an integer operation, and a special
multiply and add floating point operation, for a total of three instructions.
Actually getting the chip at top speed usually requires using assembly
language - using standard compilers gives it a speed similar to other
processors. Because of this, it's best used as a coprocessor, either for
graphics, like the NeXTdimension board, or floating point acceleration, like
add in units for workstations.
Another problem is the difficulty handling interrupts. It is extensively
pipelined, having as many as four pipes going at once, and when an interrupt
occurs, the pipes can spill and lose data unless complex code is used to
clean up. Delays range from 62 cycles (best case) to 50 microseconds (almost
2000 cycles)
Part II: IBM RS/6000 POWER chip
When IBM decided to become a real part of the workstation market, it
decided to produce a new innovative CPU, based partly on the 801 project that
pioneered RISC theory. RISC normally stands for Reduced Instruction Set
Computing, but IBM calls it Reduced Instruction-Cycle Set Computing, and
implimented a complex processor with more instructions than most CISC
processors. They ended up with was a CPU that actually contains five or seven
separate chips.
The chips are the branch unit, fixed point unit, floating point unit, and
either two or four cache chips.
The branch unit is the heart of the CPU, and actually enables up to five
instructions to be executed at once, though three is more common. It contains
the condition code register, performs checks on this register, and also
performs branches. It also dispatches instructions to the fixed or floating
point units. For added speed, it contains its own loop register (for
decrement and branch on zero). The condition code register has eight fields -
two reserved for the fixed and floating point units, the other six settable
separately. This allows a field to be set, then a branch can occur several
instructions later. In addition, the branch unit can speculatively execute
conditional branches, and then cancel the instructions if the branch is not
taken.
The fixed point unit performs integer operations, as well as some complex
string instructions and multiple load and store. The fixed unit contains
thirty two 32 bit registers.
The floating point unit contains thirty two 64 bit registers and performs
all typical floating point operations. In addition, like the Intel 860, the
floating unit has a special multiply and add instruction. The floating unit
performs this operation with up to 162 bits of precision before truncating it
to 64 bits. Often this type of operation can produce over +/-100% error if
too few bits are used. The registers are loaded and stored by the fixed point
unit.
Unlike the Intel 860, the POWER CPU does not need a special mode - the
branch unit actually reschedules instructions to operate faster. It also
handles interrupts reasonably well, and is overall a very good design. It
does, however, violate the RISC philosophy of fewer instructions at over a
hundred, versus only about 34 for the ARM and 52 for the Motorolla 88000
(including FPU instructions). A single chip POWER CPU is being designed, to be
manufactured by IBM and Motorolla, qualifying it as a microprocessor.
Part III: National Semiconductor Swordfish
The Intel 860 is a superscaler chip, but is essentially a VLIW, or Very
Long Instruction Word processor, which means that more than one instruction
is contained in a single instruction word - in this case, two. The IBM POWER
CPU reshedules instructions on the run, which gives it more flexibility, but
it can only execute different types of instructions at the same time - one
integer and one floating point, for example.
The Swordfish chip contains two separate integer units, allowing two
integer instructions to execute at once, along with one floating point
add/subtract and yet another DSP unit for multiplies, for a theoretical total
of four instructions at once.
The CPU is a 32 bit processor, but has a 64 bit data bus for fetching
multiple instructions at once. It features an instruction loader which
functions like the branch unit in the IBM POWER CPU, but lacks the extended
functions - it can't branch concurrently. It also features a Digital Signal
Processing (DSP) unit to perform multiplies and other DSP operations, and a
separate FPU. The DSP also performs single cycle integer multiplies, a task
that usually takes around seven cycles for most integer ALUs.
It is RISC in the sense that it executes instructions in one cycle, but
it doesn't use register windowing like the SPARC processor. It performs 20
MFLOPS at 50 MHz, which is good compared to other RISC chips, but slow
compared to dedicated DSPs. Still, the FPU and integer units result in most
processing tasks being faster - at 50 MHz the chip runs about 100 MIPS. The
POWER CPU is about as fast, but operates at half the clock speed.
The Swordfish's neatest features, though, are it's hardware. It
automatically can adjust it's data bus size, from 64 bits to 32, 16, or even
8 bits, making it very easy to design for. In addition, it can run from a
50MHz clock, or a 25 MHz clock in which case it multiplies the clock
internally back to 50 MHz. This allows 25MHz parts to be used with it. It
also features two DMA channels and a timer unit.
Section Six: Wierd and Innovative Chips
--------------------------
Part I: T-9000, parallel computing (1990)
The INMOS T-9000 is the latest version of the Transputer architecture, a
processor designed to be hooked up to other processors for high speed
parallel processing. The previous versions were the 16 bit T-212 and 32 bit
T-414 and T-800 processors (1985). The T-800 included a 64 bit floating point
unit. They used some RISC principles before it became fashionable, but the
most important feature was that each chip contained 4 serial ports to connect
the chips in a network.
Although the previous chips were fast, the T-9000 is a much enhanced
design. It starts with an architecture like the T-800. It contains only three
registers that are used as an evaluation stack - they are not general purpose.
Instead, like the TMS 9900, it uses memory for registers, and points to the
workspace using a workspace register and cache based on 32 word rotating
buffers. This allows very fast context switching, less than a microsecond.
Unlike when the TMS 9900 was created, the T-9000 is far faster than
memory access, so the CPU has several levels of very high speed caches and
memory levels. It not only speeds process scheduling, is simplifies it enough
that task switching is automated in hardware, unlike most processors. The
Intel 432, described later, also attempted hardware process scheduling, but
was unsuccessful at it. The main cache is 16 K, and is designed for 3 reads
and 1 write simultaneously. The workspace cache allows 2 reads and 1 write
simultaneously.
The T-9000 contains 4 main internal units, the CPU, the VCP, which
performs the communications between chips, the PMI, which manages memory, and
the Scheduler. There's also an instruction grouper which can schedule five
instruction stages in the most efficient manner. The grouper can start an
instruction in any stage (bypassing unneeded stages) and instructions don't
need to pass through every stage, and can leave when finished, freeing the
pipeline for other instructions. Instructions themselves are unique in that
frequently used instructions are stored in only a byte, but other instructions
are represented by multiple bytes.
The serial links allow communications at close to the speed of direct
memory access, and the VCP unit allows this to take place without the CPU
being aware of it. Even larger networks can be created with the C104 crossbar
switch, which can connect 32 transputers or other C104 switches into a
network hundreds of thousands of processors large. The C104 acts like a
instant switch, not a network node, so the message is passed through, not
stored.
Like the Swordfish CPU, the T-9000 PMI (Programable Memory Interface) can
adapt to a 64, 32, 16, or 8 bit bus.
Part II: Intel 432, Extraordinary complexity (1980)
The Intel iAPX 432 was a complex, object oriented 32-bit processor that
included high level operating system support in hardware, such as process
scheduling and interprocess messaging. It was intended to be the main Intel
microprocessor - the 80286 was envisioned as a step between the 8086 and the
432. The 432 actually included four chips. The GDP (processor) and IP (I/O
controller) were introduced in 1980, and the BIU (Bus Interface Unit) and MCU
(Memory Control Unit) were introduced in 1983.
The GDP was exclusively object oriented - normal linear memory access
wasn't allowed. It was designed with the Ada programming language in mind. It
had hardware support for data hiding, methods, and access protection.
Unfortunately this meant that every memory access was checked, which slowed
execution. Because of the object oriented approach, the GDP had no local data
registers. It supported up to 2^24 segments, each limited to 64K in size, but
the object oriented nature of the design meant that was not a real limitation.
Instructions were bit encoded, ranging from 6 bits to 321 bits long (like the
T-9000) and could be very complex.
The BIU defined the bus. BIUs were designed for multiprocessor support,
allowing up to 63 BIUs on a bus, and up to 8 independent buses, allowing
memory interleaving, to speed access. The MCU did automatic pairity checking
and single bit error correcting. The total system was designed to be fault
tolerant to a large degree, and each of these parts contributes to that
reliability.
Despite these advanced features, the 432 didn't catch on. The main reason
was that it was slow, about five to ten times slower than a 16-bit 68000. Part
of this was the lack of local data registers, or a cache. Part of this was the
fault-tolerant BIU, which defined an asyncronous bus that resulted in 25% to
40% of the access time being used by wait states. The instructions weren't
aligned on bytes or words, and took longer to decode. In addition, the
protections imposed on the objects required multiple memory accesses for
permission checks everytime data was accessed.
It's high level architecture was similar to the Transputer systems, but it
was implimented in a way that was much slower than other processors, while the
T-414 was actually much faster than other processors of the time.
Part III: Rekursiv, an object oriented processor
The Rekursiv processor is actually a processor board, not a
microprocessor, but is neat. It was created by a manufacturing company called
Linn, to control their manufacturing system. The owner was a believer in
automation, and had automated the company as much as possible with Vaxes, but
wasn't satisfied, so hired software experts to design a new system, which
they called LINGO. It was completely object oriented, like smalltalk (and
unlike C++, which allows some object concepts, but handles them in a
conventional way), but too slow on the VAXes, so Linn commissioned a
processor designed for the language.
This is not the only processor designed specifically for a language that
is slow on other CPUs. Several specialized LISP processors, such as the
Scheme-79 lisp processor, were created, but this chip is unique in its object
oriented features. It also manages to support objects without the slowness of
the Intel 432.
The Rekursiv processor features a writable instruction set, and is highly
parallel. It uses 40 bits for objects, and 24 bit addressing, kind of. Memory
can't be addressed directly, only through the object identifiers, which are
40 bit tags. The hardware handles all objects in memory and on disk, and
swapping them to disk. It has no real program - all data and code/methods are
embedded in the objects, and loaded when a message is sent to them. There is
a page table which stores the object tags and maps them into memory.
There is a 64k area, arranges 16k X 128 bit words, for microcode,
allowing an instruction set to be constructed on the fly. It can change for
different objects.
The CPU hardware creates, loads, saves, destroys, and manipulates
objects. The manipulation is accomplished with a standard AMD 29203 CPU, but
the other parts are specially designed. It executes LINGO entirely fast
enough, and is a perfect match between language and CPU, but it can execute
more conventional languages, such as Smalltalk or C if needed - possible
simultaneously, as separate complete objects.
John Bayko (Tau).
Appendix A:
==========
RISC and CISC definitions:
-------------------------
RISC refers to a Reduced Instruction Set Computer. IBM pioneered many RISC
ideas in their 801 project. RISC designs call for each instruction to execute
in a single cycle, which is done with pipelines, no microcode (to reduce chip
complexity and increase speed). Operations are performed on registers only
(with the only memory access being loading and storing). Finally, RISC design
uses a large windowed register set to speed subroutine calls (see the entry on
SPARC for a description).
But despite these specifications, RISC is more a philosophy than a set of
design criteria, and almost everything is called RISC, even if it isn't.
Pipelines are used in the 68040 and 80486 CISC processors to execute
instructions in a single cycle, even though they use microcode, and
experiments have shown that windowed registers can be added to CISC designs,
speeding them up in a similar way. Basically, RISC asks whether an instruction
is necessary, or whether it can be replaced by several simpler instructions
without a major performance loss. Typically multiply and divide instructions
are necessary, despite the fact they require multiple cycles to execute. The
advantage is that a simpler chip can run at a higher clock speed.
CISC refers to a Complex Instruction Set Computer. There's not really a
set of design features to characterize it like there is for RISC, but small
register sets, large instruction sets, and use of microcode are common. The
philosophy is that if a complex instruction can result in an overal increase
in speed, it's good. The disadvantage is that it's harder to increase the
clock speed of a complex chip.
Microcode was a way of simplifying processor design. Even though it
resulted in instructions that are slower requiring multiple clock cycles, it
was thought it would allow more complex instructions to better support high
level languages, leading to better performance. However, most complex
instructions are seldom used.
Processor Classifications:
-------------------------
Arbitrarily assigned by me...
___CISC_________________________________________________________RISC
|
4-bit | Am2903
| 4004
| 4040
8-bit | 1802
| 8008
| 8080 2650,SC/MP F8
| F100-L 650x,6800
|
| MCP1600 Z-80 6809
16-bit|
| 8086 TMS9900
| Z8000 65816
|
| 68000
32-bit| ARM SPARC
| 432 R2000
| Z80000 68040
| ---<T9000>-Swordfish-- HP-PA 88100
| Rekurs RS/6000 88110
64-bit| -------<860>------
| Alpha
|
Appendix B:
==========
Appearing in IEEE Computer 1972:
-------------------------------
NEW
PRODUCTS
FEATURE PRODUCT
COMPUTER ON A CHIP
Intel has introduced an integrated CPU complete with
a 4-bit parallel adder, sixteen 4-bit registers, an accumula-
tor and a push-down stack on one chip. It's one of a
family of four new ICs which comprise the MCS-4 micro
computer system--the first system to bring the power and
flexibility of a dedicated general-purpose computer at low
cost in as few as two dual in-line packages.
MSC-4 systems provide complete computing and con-
trol functions for test systems, data terminals, billing
machines, measuring systems, numeric control systems
and process control systems.
The heart of any MSC-4 system is a Type 4004 CPU,
which incudes a set of 45 instructions. Adding one or
more Type 4001 ROMs for program storage and data
tables gives a fully functioning micro-programmed com-
puter. Add Type 4002 RAMs for read-write memory and
Type 4003 registers to expand the output ports.
Using no curcuitry other than ICs from this family of
four, a system with 4096 8-bit bytes of ROM storage and
5120 bits of RAM storage can be created. For rapid
turn-around or only a few systems, Intel's erasable and
re-programmable ROM, Type 1701, may be substituted
for the Type 4001 mask-programmed ROM.
MCS-4 systems interface easily with switches, key-
boards, displays, teletypewriters, printers, readers, A-D
converters and other popular peripherals. For further
information, circle the reader service card 87 or call Intel
at (408) 246-7501.
Circle 87 on Reader Service Card
COMPUTER/JANUARY/FEBRUARY 1971/71
Appearing in IEEE Computer 1975:
-------------------------------
The age of the affordable computer.
MITS announces the dawning of the Altair 8800
Computer. A lot of brain power at a price that's
bound to create love and understanding. To say
nothing of excitement.
The Altair 8800 uses a parallel, 8-bit processor
(the Intel 8080) with a 16-bit address. It has 78
basic machine instrcutions with variences ofer 200
instructions. It can directly address up to 65K bytes
of memory and it is fast. Very fast. The Altair
8800's basic instruction sysle time is 2 microseconds.
Combine this speed and power with Altair's
flexibility (it can directly address 256 input and 256
output devices) and you have a computer that's
competitive with most mini's on the market today.
The basic Altair 8800 Computer includes the
CPU, front panel control board, front panel lights
and switches, power supply (enough to power any
additional cards), and expander board (with room
for 3 extra cards) all enclosed in a hansome, alum-
inum case. Up to 16 cards can be added inside the
main case.
Options now available include 4K dynamic mem-
ory cards, 1K static memory cards, parallel I/O
cards, three seial I/O cards (TTL, R232, and TTY),
octal to binary computer terminal, 32 character
alpha-numeric display terminal, ASCII keyboard,
audio tape interface, 4 channel storage scope (for
testing), and expander cards.
Options under development include a floppy disc
system, CRT terminal, line printer, floating point
processor, vectored interrupt (8 levels), PROM
programmer, direct memory access controller and
much more.
PRICE
Altair 8800 Computer: $439.00* kit
$621.00* assembled
prices and specifications subject to change without notice
For more information or our free Altair Systems
Catalogue phone or write: MITS, 6328 Linn N.E.,
Albuquerque, N.M. 87108, 505/265-7553.
*In quantities of 1 (one). Substantial OEM discounts available.
[Picture of computer, with switches and lights]
Appendix C:
==========
Bubble Memories:
---------------
Certain materials (ie. gadolinium gallium garnet) are magnetizable easily
in only one direction. A film of these materials can be created so that it's
magnetizable in an up-down direction. The magnetic fields tend to stick
together, so you get a pattern that is kind of like air bubbles in water
squished between glass, half with the north pole facing up, half with the
south, floating inside the film. When a vertical magnetic field is imposed on
this, the areas in opposite alignment to this field shrink to circles, or
'bubbles'.
A bubble can be formed by reversing the field in a small spot, and can be
destroyed by increasing the field.
The bubbles are anchored to tiny magnetic posts arranged in lines. Usually
a 'V V V' shape or a 'T T T' shape. Another magnetic field is applied across
the chip, which is picked up by the posts and hods the bubble. The field is
rotated 90 degrees, and the bubble is attracted to another part of the post.
After four rotations, a bubble gets moved to the next post:
o o o
\/ \/ \/ \/ \/ \/ \/ \/
o
o_|_ _|_ _|_ _|_ _|_o _|_ _|_ o _|_ _|_ o_|_
| o | | | |
I hope that diagram makes sense.
These bubbles move in long thin loops arranged in rows. At the end of the
row, the bits to be read are copied to another loop that shift to read and
write units that create or destroy bubbles. Access time for a particular bit
depends on where it is, so it's not consistant.
One of the limitations with bubble memories, why they were superceded, was
the slow access. A large bubble memory would require large loops, so accessing
a bit could require cycling through a huge number of other bits first. The
speed of propagation is limited by how fast magnetic fields could be switched
back and forth, a limit of about 1 MHz. On the plus side, they are
non-volatile, but eeproms, flash memories, and ferroelectric technologies are
also non-volatile and and are faster.
Ferroelectric and Ferromagnetic (core) Memories:
-----------------------------------------------
Ferroelectric materials are analogous to ferromagnetic materials, though
neither actually need to contain any iron. Ferromagnetic materials, used in
core memories, will retain a magnetic field that's been applied to it.
Core memories consist of ferromagnetic rings strung together on tiny
wires. The wires will induce magnetic fields in the rings, which can later be
read back. Usually reading this memory will erase it, so once a bit is read,
it is written back. This type of memory is expensive because it has to be
constructed physically, but is very fast and non-volitile. Unfortunately it's
also large and heavy, compared to other technologies.
Legend reports that a Swedish jet prototype (the Viggen I believe) once
crashed, but the flight recorders weren't fast enough to record the cause of
the crash. The flight computers used core memory, though, so they were hooked
up and read out, and the still contained the data microseconds before the
crash occurred, allowing the cause to be determined.
Ferroelectric materials retain an electric field rather than a magnetic
field. like core memories, they are fast and non-volatile, but bits have to be
rewritten when read. Unlike core memories, ferroelectric memories can be
fabricated on silicon chips in high density and at low cost.
Don Stokes
> The Z-80 was intended to be an improved 8085, which was an improved 8080,
> and it was - vastly improved. It also used 8 bit data and 16 bit addressing,
> and could execute all 78 of the 8085 op codes, but included 80 more,
Not quite. The 8085 and Z80 were separate developments of the 8080. The
8085 improved the I/O (but introduced multiplexed address/data lines).
> Unlike the 8080 and its kind, the 6502 had very few registers. It was an
> 8 bit processor, with 16 bit address bus. Inside was one 8 bit data register,
> and two 16 bit index registers and a 16 bit stack pointer. It used these
The program counter was the only 16 bit register. All others -- accumulator,
two index registers, stack pointer and processor status were 8 bits wide.
The zero page was used in conjuction with the index registers to provide
16 bit addressing.
> Part V: The 6809, extending the 650x
>
> The 6800 from Motorolla was essentially the same design as the 6502, but
> with some tweaking here and there. But the successor was a major advance - at
> least relatively.
Other way around -- the 6502 was "based" on the 6800 (which has the dubious
distinction of having a "halt and catch fire" instruction). The 6809 was an
improvement on the 6800 series, maybe borrowing things from other processors.
Note also that there was a whole family of 680x processors before the 6809.
> Part VI: Advanced Micro Devices Am2903, a few bits at a time
I tend to think of the AM2901 as the ubiquitous bit-slicer found damn near
everywhere driving peripherals etc.
Another interesting point is that the VAX 11/730 is actually built out of
multiple (I think -- I haven't pulled one to bits to look) AM2901s. Sort
of a parallel processed emulation of a VAX (and allegedly quite a bit faster
than the VAX 11/780 for some operations -- ie when it didn't need to go
anywhere near the memory bus, which on a VAX isn't often).
How could you _possibly_ leave out the DEC processors? These were the
LSI-11, F-11, J-11 & T-11. The LSI-11 was a strictly 16 bit version of
the pdp11 architecture, no memory managment. The F-11 gave 22 bit extended
addressing (although the first revisions of the KDF11 board only brought
out 18 bits, since DEC weren't building 22 bit Qbus backplanes yet.) The
J-11 was/is effectively an 11/70 on a chip (well, sort of), and provides
split instruction & data spaces and supervisor mode (the F-11 only had user
and kernel modes, the LSI-11 has no protection whatsoever). The T-11 is
(I gather -- I've not seen one) a cut down J11 for use in controllers.
Systems built with theses chips were the PDP-11/03, PDT-11, VT103 (LSI-11),
PDP-11/23, /23+, /24, Pro 325, Pro 350 (J-11), PDP-11/73, /83, /84, /93, /94,
Pro 380. Various third parties used these as well.
Then there's the 78032(?) -- the MicroVAX II processor. (The MicroVAX I was
actually not strictly a microprocessor, but a two board set.) That was
followed by the MicroVAX 3xxx (78034(?)) process and so-on into recent
history.
Nobody should of course forget the Intersil 6100 and 6120 -- PDP-8s on a chip.
> Part IV: DEC Alpha, Designed for the future
>
> It is a 64 bit chip that doesn't support 8- or 16-bit operations, but
Nononononono.... Alpha is an _architecture_, not a chip. The 21064 is the
first (and so far only announced) chip conforming to the Alpha architecture.
Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand +64-4-495-5052
Torben AEgidius Mogensen
> This is a list of interesting, unique, or important microprocessors
>from the very beginning to today. Not necessarily the first of their kind,
>or the best.
> Anyway, I've done my best to be accurate, but I'm sure there are
>dozens of bugs in it. I'd appreciate comments and corrections (I'll try
>and add whatever feedback I get into the next version).
Here's a few of those bugs and some other comments.
>John Bayko.
...
>Part IV: The 650x, Another Direction (1975-ish)
> Unlike the 8080 and its kind, the 6502 had very few registers. It was an
>8 bit processor, with 16 bit address bus. Inside was one 8 bit data register,
>and two 16 bit index registers and a 16 bit stack pointer. It used these
>index and stack registers effectively, with more addressing modes, including
>a fast zero-page mode that accessed memory addresses from address 0 to 255
>with an 8-bit address that speeded operations (it didn't have to fetch a
>second byte for the address).
The stack and index registers are only 8 bits wide. The stack register
always refers to page 1. The index registers are used in combination
with 16 bit addresses that are either supplied as immediate constants
or through a zero-page address. Using index register y with a
zero-page address D, results in the final address (@D)+y (post
indexed). Using index register x with a zero-page address D, results
in the final address @(D+x) (pre indexed). The latter is of limited
use. The 6502 used few cycles per instruction compared to its main
competitors, the Z80 and 8080.
...
>Part I: RCA 1802, wierdness at its best (1974)
Another interesting feature is a flag bit that connects to a pin. This
can be used for primitive I/O, and was used in the COSMAC to generate
signals for the tape interface.
>Part III: Motorolla 68000, a refined 16/32 bit CPU
It is spelled "Motorola".
>Part II: Acorn ARM, RISC for home use (1985)
> ARM (Advanced RISC Microprocessor) is often praised as one of the most
>elegant modern processors in existance. It was meant to be "MIPs for the
>masses", and designed as part of a family of chips (ARM - CPU, MEMC - MMU and
>DRAM/ROM controller, VIDC - video and DAC, IOC - I/O, timing, interrupts,
>etc), for the Archimedes home computer (multitasking OS, windows, etc). It's
>made by VLSI Technologies Inc.
ARM was originally an acronym for "Acorns RISC Machine", and is now
"Advanced RISC Machine".
> The origional ARM2 was 26 bits, but the newer ARM6xx spec is 32 bits. It
>has user, supervisor, and various interrupt modes (including 26 bit modes for
>ARM2 compatability) and only 16 registers (many registers are shadowed in
>other modes for speed, to avoid saving during interrupts, for example). The
>ARM series consists of the ARM6 CPU core, which can be used as the basis for a
>custom CPU, the ARM60 base CPU, and the ARM600 which also includes 4K cache,
>MMU, write buffer, and coprocessor interface. It can also be big- and
>little-endian.
Only the addresses in the ARM2 are limited to 26 bits - data is 32
bits. Another novel feature is the save/load multiple registers
instructions. These allow any subset of the 16 registers to be
transferred to or from memory. This takes advantage of fast sequential
access to dynamic memory, and makes procedure calls fairly efficient.
Torben Mogensen (tor...@diku.dk)
Matthias Neeracher
>Only the addresses in the ARM2 are limited to 26 bits - data is 32
>bits. Another novel feature is the save/load multiple registers
>instructions. These allow any subset of the 16 registers to be
>transferred to or from memory. This takes advantage of fast sequential
>access to dynamic memory, and makes procedure calls fairly efficient.
In what way is this feature "novel" ? Is it any different from the 68000 MOVEM
instruction ?
Matthias
-----
Matthias Neeracher ne...@iis.ethz.ch
"I came to the conclusion that sex is a sublimation
of the work instinct" -- David Lodge, _Small World_
leic...@zodiac.rutgers.edu
mentioned. A couple of additions/corrections to his comments:
- The T-11 was not a reduced J-11. It was a separate design, aimed
for very low cost, both for the chip and the system it was
plugged into. It's closer to the LSI-11 than the J-11 -
your basic PDP-11, with no extensions. I'm not sure if it
even had a kernel mode. A unique feature of the chip was
that it could use either an 8-bit or a 16-bit bus - config-
urable by software. There must have been some hackery to
get the thing to boot! The 8-bit bus made it possible to
produce cheap systems; the individual chips were available
in plastic rather than the more expensive ceramic. A LOT
of T-11's are out in the world to this day - the VT240 uses
two, if I remember right. There's one in the RQDX3, the
disk controller for pre-SCSI MicroVAXes. (The firmware for
the RQDX3 was written in C and compiled using DECUS C!)
F-11, and later J-11, chips have appeared in such DEC devices
as terminal servers and HSC's (disk controllers for clusters).
- The original MicroVAX II chip was ahead of its time in many ways.
Recall the competition at the time it came out: 8086's,
68000's (the original ones), maybe a few National Semi chips.
The MicroVAX II chip was a full 32-bit implementation, with
full on-chip virtual memory support, and a closely coupled
FP unit. (In theory, you could buy a system without the FP
chip. I don't know if any were actually built.) Some of the
competing chips might have one or the other of these, but it
would be several years before any had both.
- The lastest VAX chips are pushing into the RISC performance range.
Since these chips and the first Alpha chips are being built
with the same technology, we can (as in the case of the Intel
386 and 860) factor that out an calculate the speed advantage
of RISC. It seems to come out at a factor of 2 to 3 at the
moment.
What gave RISC one big initial push into the market was that
it was beating MicroVAX performance - taken as the standard
for CISC - by a factor of 10. Part of the reason for this was
that the original MicroVAX II chip was done in NMOS, a techno-
logy that reached a dead end. Thus, there was a very long gap
between the MicroVAX II and the first CMOS MicroVAX, and of
course that first CMOS product represented a new technology
for DEC and so wasn't fully competitive at the time with
other CMOS processes. One can speculate about what would
have happened if DEC had started building its CMOS experience
sooner, so that it could have moved up the learning curve
earlier. A factor of 2 or 3 speedup for a new technology is
MUCH harder to sell than a factor of 10....
-- Jerry
Charles Lasner
of a PDP-8 in a VT-52 box, and is based on the 6100. All DECmates are based
on the 6120, which is a different, and faster chip. While PDP-8's execute
all cycles in normal memory, possibly with interrupts, the 6100 and 6120
support a "supervisory" mode known as control-panel memory because it was
thought by Intersil to be useful to implement a front-panel console in
software. The context is saved even if the machine was halted, and the
CP memory routines are enterred to service the source of CP interrupt,
which may be a deliberate trapped "panel request" from knowledgable PDP-8
software that realizes it's running on a 61x0 machine as opposed to an -8.
The CP rouitnes service the interrupt and return control to the main-memory
PDP-8 routine and its normal interrupts, which are ignorant of the CP stuff.
The DECmates use CP memory to fake the console interface of a PDP-8, including
a built-in emulator of a VT-100 (DM I) or VT-220 (DM II and up). Carefully
constructed PDP-8 code can blindly run in this environment or on an actual
PDP-8 with a VT-100/220 terminal console device.
cjl
Dan Swartzendruber
> ba...@hercules.cs.uregina.ca (J. Bayko) writes:
[stuff deleted]
>
> >Part V: The 6809, extending the 650x
>
> > The 6800 from Motorolla was essentially the same design as the 6502, but
> >with some tweaking here and there. But the successor was a major advance - at
> >least relatively.
>
> The 6500 *was* essentially, a 6800. The 6502 was similiar but
> not identical.
>
Say what? The 650x was about as unrelated to the 6800 as you could get, except
for their both being 8-bit machines!
[more stuff deleted]
--
Dan S.
Stephen Melvin
>...
>RISC and CISC definitions:
>...
>Basically, RISC asks whether an instruction
>is necessary, or whether it can be replaced by several simpler instructions
>without a major performance loss.
>The [CISC]
>philosophy is that if a complex instruction can result in an overall increase
>in speed, it's good.
Let's see, RISC says optimize the instruction set for maximum performance
and CISC says optimize the instruction set for maximum performance. Wait,
something's wrong!. Could it be that there's really not a "philosophical"
issue here!!?? No, that's impossible, that would contradict everything
we've been told.
Jeffrey T. Hutzelman
user J. Ba...@hercules.cs.ure writes:
> Unlike the 8080 and its kind, the 6502 had very few registers. It was an
>8 bit processor, with 16 bit address bus. Inside was one 8 bit data register,
>and two 16 bit index registers and a 16 bit stack pointer. It used these
>index and stack registers effectively, with more addressing modes, including
>a fast zero-page mode that accessed memory addresses from address 0 to 255
>with an 8-bit address that speeded operations (it didn't have to fetch a
>second byte for the address).
Ummm.. That 6502 has 2 _8_ bit index registers (X and Y), and an _8_ bit
stack pointer - the stack is always kept on page $01 of memory.
> As a side point, Apples, which were among the first computers introduced,
>have continued, now using the 65816, which is compatable with the 6502, but
>has been expanded to 16 bits. The Apple II line, which actually includes the
>Apple I, is the longest existing line of microcomputers.
The 65816 has a number of interesting features, including the expansion
of all 3 registers to 16 bits, plus a 16-bit stack pointer and a 16-bit
"Direct Page Register", which controlled the base address of the direct
page addressing mode, so that ANY 256 locations in the first 64K of
memory could be accessed with greater speed. The 65816 also has a
24-bit address bus, increasing addressable memory to 16MB.
jh...@andrew.cmu.edu, jh...@drycas.BITNET
JeffreyH11 on America Online
Ralph Becker-Szendy
forgotten in the marketplace for workstation-type use): The NS 32x32
series. Great CISC machines, wonderful instruction set (VAX and then
some, the link instructions look great on paper), instruction set
compatible CPUs from 8 through 32 bit bus interface (initially they
were called 16008, 16016 and 16032, later the numbering system
flipped, or maybe the other way round), the last version of the series
to be unleashed was the 32532, which is an amazingly nice chip
according to the manual (ask some owners of the PC532 whether it is
really that nice in practice, I don't know). At least according to
the spec's, this was the climax of the generic CISC microprocessors
... and it flopped in the marketplace. Surviving today by having spun
off graphics imaging processors (32GX32 or some such number comes to
my feeble mind). Also somewhere I have a rumor of a 32732 with a
different instruction set stored in the back of my brain.
Disclaimer: Never used one of these things (I still have a 32032
developers kit in the closet, but haven't gotten around to doing
anything with it). Also my employer wouldn't recognize a 32032 if it
jumped out of a shrub and bit it in the behind.
--
Ralph Becker-Szendy RA...@SLACVM.SLAC.STANFORD.EDU
Stanford Linear Accelerator Center RA...@SLACVM.BITNET
M.S. 95, P.O. Box 4349, Stanford, CA 94309 (415)926-2701
My opinion. This is not SLAC, Stanford U, or the US DoE speaking. Just me.
Jack Dietz
> They didn't. They chose the 8088. The 8806 was already in use
> in the Displaywriter. Rumor has it that Boca was forced to use
> the slower (4.88 MHz) 8088 to prevent the PC from competing with
> the Displaywriter. Can anyone confirm or deny this? (Come on,
> the statute of limitations for these things must have passed by
> now.)
BYTE magazine had a short article in their '10th Anniversary of the
PC' issue a year or two back by the head of the PC design group. In
it, he stated that the PC was a very simple reworking of an earlier
CP/M machine (called the System/27, I think) which was never very
broadly marketed. The 8085-based machine had a monochrome text-only
display with a resolution of 720x348, an 84-key keyboard with an odd
layout, 5 1/4" floppies...
Essentially the group was told to take the machine and a) upgrade it
to an 8088, and b) make it salable to home users. a) just required
dropping the chip in and upgrading a couple of support chips.
(It's amazing how similar the 8088 and 8085 are on the outside...)
b) forced them to use the odd clock frequency (for cheap NTSC
compatability) and to move the monochrome display adapter onto a
card.
The motherboard had 64K because the 8085 could only access 64K.
The 640K limit was imposed because they never dreamed anyone would
want more memory than that -- it was supposed to be an overblown
CP/M machine at a time when 64K was still a lot of memory.
(Actually not a CP/M machine, because Digital Research had their
heads screwed on wrong, instead it had a cheap clone of CP/M-86 by a
programmer in Seattle who reportedly has regretted it ever since...
But, if IBM didn't realize what they had, how could DR expect to?)
Some other design decisions were conditioned by the fact that the
group was told they might sell fifty thousand of these boxes...
The article also had pictures of the System/27 inside and out, and a
photo of the prototype wire-wrap PC motherboard.
>--
>Motorola Semiconductor Inc. Hunter Scales
>Austin, Texas hun...@prometheus.sps.mot.com
>#include <disclaimer.h>
--
Jack Dietz
// jdi...@ucsd.edu
Chris Dollin
In article <1992May14.1...@odin.diku.dk> tor...@diku.dk (Torben AEgidius Mogensen) writes:
>Only the addresses in the ARM2 are limited to 26 bits - data is 32
>bits. Another novel feature is the save/load multiple registers
>instructions. These allow any subset of the 16 registers to be
>transferred to or from memory. This takes advantage of fast sequential
>access to dynamic memory, and makes procedure calls fairly efficient.
In what way is this feature "novel" ? Is it any different from the 68000
MOVEM instruction ?
The 68K isn't advertised as a RISC (yet :-). I am given to understand that
load/store multiple instructions are not usually found on RISC processors - for
example, PA-RISC hasn't got them.
For my money, the *novel* feature of the ARM is that every instruction is
conditional. But then, I'm hooked.
--
Regards, | "If taking devious pains was a sign of laziness, he was quite
Kers. | prepared to call Hazelton the laziest man alive." Blish (m-o-l)
Dik T. Winter
> ke...@hplb.hpl.hp.com (Chris Dollin) writes:
> ] For my money, the *novel* feature of the ARM is that every instruction is
> ] conditional. But then, I'm hooked.
> I know it's a little different, but isn't the idea of a "skip" instruction,
> that causes the next instruction to not be executed, both older than
> ARM's conditional instructions ( and RISC in general ), and semantically
> identical, if one considers the skip-next_inst sequence to actually be a
> single instruction ?
If one considers them as a single instruction, yes they are semantically
identical. But older? From what time dates the skip instruction?
The condition on every instruction is old, the 1965 vintage Electrologica
X8 had it, as its predecessor the X1 (of 1960 vintage). So it is certainly
not *novel*.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
d...@cwi.nl
Tim McCaffrey
>Section One: Before the Great Dark Cloud.
> ---------------------------
>Part I: The Intel 4004 (1972)
>
>Part II: The Intel 4040 and 8080
>
> The 8080 had a 16 bit address bus, and an 8 bit data bus. Internally it
>had six 8 bit registers, a 16 bit stack pointer (the stack was stored in
>memory, not in an internal register set), and 16 bit program counter. It also
>had several I/O ports - 512 of them, so I/O devices could be hooked up without
>taking away or interfering with the addressing space.
The 8080 had 7 8 bit registers, 3 of which could be concatenated to
form 3 16 bit regs. The 512 ports are actually 256 in and 256 out..
>
>Part III: The Zilog Z-80 - End of the 8-bit line (July 1976)
>
> The Z-80 was intended to be an improved 8085, which was an improved 8080,
>and it was - vastly improved. It also used 8 bit data and 16 bit addressing,
>and could execute all 78 of the 8085 op codes, but included 80 more,
>instructions that included 1, 4, 8 and 16 bit operations and even a block move
>instruction. The register set was doubled, with two banks of registers that
>could be switched between. This allowed fast operating system or interrupt
>context switches.
The Z-80 was an improved 8080, the 8085 came out a little after the Z-80, and
included two instructions that neither the Z-80 or 8080 had.
> But the thing that really made the Z-80 popular was actually the memory
>access - the CPU generated it's own RAM refresh signals, which meant easier
>design and lower system cost. That and it's 8085 compatability, and CP/M, the
>first standard microprocessor operating system, made it the first choice of
>many systems.
>
>Part IV: The 650x, Another Direction (1975-ish)
>
> Shortly after the 8080, MOS Technologies introduced the 650x series,
>including the 6502 used in Commodores, Apples and Ataris. Steve Wozniak
>described it as the first chip you could get for less than a hundred dollars.
Ack! The time line is: 6800->650x->65816, 6800->6809. The 6800 had 2
8 bit accumulators (A&B), one 16 bit index (X) and one 16 bit stack (S). The
6502 had one 8 bit accumulator (A), two 8 bit index registers (X&Y), and one 8
bit stack pointer (S). Both CPUs use the first 256 bytes of memory as the
direct page. The 6502 uses the DP much more effectively to expand the number
of addressing modes, and reduce the impact of having small registers.
>
>Part V: The 6809, extending the 650x
>
> The 6800 from Motorolla was essentially the same design as the 6502, but
>with some tweaking here and there. But the successor was a major advance - at
>least relatively.
Like I said, the 6800 was first, not the 6502.
>Part VI: Advanced Micro Devices Am2903, a few bits at a time
>
>Section Two: Forgotten/Innovative Designs before the Great Dark Cloud
> --------------------------------------------------------
>Part I: RCA 1802, wierdness at its best (1974)
>
> The RCA 1802 was an odd beast, extremely simple and fabricated in CMOS,
>which allowed it to run at 6.4 MHz, very fast for 1974. It was an 8 bit
Only if you ran the CPU at 10V, and usually not even then. It was usually run
at 1.79 Mhz (half of a color burst crystal). BTW, I saw one these running
of a lemon once.
>processor, with 16 bit addressing, but the major features were it's extreme
>simplicity, and the flexibility of it's large register set. Simplicity was the
>primary design goal, and in that sense it was one of the first RISC chips.
> It had sixteen 16-bit registers, which could be accessed as thirty-two
>8 bit registers, and an accumulator D used for arithmatic and memory access -
>memory to D, then D to registers, and vice versa, using one 16-bit register
>as an address. This led to one person describing the 1802 as having 32 bytes
>of RAM and 65535 I/O ports. A 4-bit control register P selected any one
>general register as the program counter, while control registers X and N
>selected registers for I/O Index, and the operand for current instruction. All
>instructions were 8 bits - a 4-bit op code (total of 16 operations) and 4-bit
>operand register stored in N.
> There was no real conditional branching, no subroutine support, and no
>actual stack, but clever use of the register set allowed these to be
>implimented - for example, changing P to another register allowed jump to a
>subroutine. Similarly, on an interrupt P and X were saved, then R1 and R2 were
>selected for P and X until an RTI restored them.
Not quite true, there are conditional skips, conditional long skips, conditional
short jumps (on current 256 byte page), and conditional long jumps. Some of
these instructions were up to 3 bytes long.
> Apart from the COSMAC microcomputer kit, the 1802 saw action in some
>video games from RCA and Radio Shack, and legend has it the chip is the heart
>of the Voyager and Viking probes. One reason for this is that the 1802 was
>also fabricated mounted on saphire, which leads to radiation and static
>resistance, ideal for space operation.
There are several (6 to 10?) 1802s running on the Galileo space craft, along
with a couple of rad hard 2900 bit slice computers.
> A later version, the 1805, was enhanced, giving it several Forth language
>primitives, which could explain the high usage of Forth in control
>applications.
>
>Part II: Fairchild F8, Register windows
>
>Part III: SC/MP, early advanced multiprocessing (April 1976)
>
>Part IV: F100-L, a self expanding design
>
>Part V: The Western Digital 3-chip CPU (June 1976)
>
>Part VI: Intel 8048, Harvard bus
>
Let's see, you missed: The Signetics 2650 (another odd CPU). The
General Instrument 1600, an LSI-11 look alike. There was a
Fairchild chip (can't remember the number) that was a subset of
the Data General NOVA. The Intersil IM6100 which was an implemtation
of the PDP-8. There was also a chip set implementation (I think from
WD) of the UCSD P-Code.
Good summary.
Tim McCaffrey
NOT speaking for Unisys.
Dennis O'Connor
ba...@hercules.cs.uregina.ca (J. Bayko) writes:
]
] This is a list of interesting, unique, or important microprocessors
Which means a relatively arbitrary list. Some important ones where missed.
] from the very beginning to today. Not necessarily the first of their kind,
] or the best.
If not the first, the best, or the most succesful, what criteria IS used ?
] Anyway, I've done my best to be accurate, but I'm sure there are
] dozens of bugs in it. I'd appreciate comments and corrections (I'll try
] and add whatever feedback I get into the next version).
What it really needs is more, footnoted, references. Lacking references,
it's not verifiable enough to be of any real use.
As it is, I'd give it a C. Fix the bugs, especially the definitions, maybe
you'll get a B. If you want an A, you'd better add footnoted references.
] RISC and CISC definitions:
] -------------------------
Actually, I think you need to think about defining "microprocessor".
You've got single-chip, multi-chip, and bit-slice components in your list.
If you don't use single-chip as the "micro?" discriminent, what do you use ?
And there IS a single-chip VAX : few would argue that VAX's importance.
] RISC refers to a Reduced Instruction Set Computer.
] IBM pioneered many RISC ideas in their 801 project.
"801" should not be the only computer listed as a "pioneer of RISC ideas".
You need to find an archive of recent comp.arch discussions.
] RISC designs call for each instruction to execute in a single cycle,
Well, they don't usually COMPLETE in a single cycle, so what do you mean ?
Don't say "issues in a single cycle" : superscalar confuses that too much.
Besides, given a long enough "cycle", and a (say) 64-phase clock, I could
probably create "single-cycle" implementations of some CISC architectures
( tho not the venerable VAX, I'd wager ).
] which is done with pipelines,
AHA ! If true, this PROVES that RISC instructions don't "execute" in one cycle!
] no microcode (to reduce chip complexity and increase speed).
Lack of microcode doesn't neccesarily do either of these things.
On-chip vertical microcode is essentially equivalent to a fixed
library of standard "inlined" subroutine calls. The details of
implementing it are well understood.
One could try to argue that microcode doesn't provide enough
performance to justify the silicon it uses, but given how
dense ROM is, it's a tough argument to make, I think.
] [ ... Load/Store Architecture ... that's one right ... ] Finally, RISC design
] uses a large windowed register set to speed subroutine calls
Bzzt ! Sorry, that's NOT the answer we were looking for. RISC generally
means lots of registers ( CISC can have that too, tho ), but reg-windows
is NOT a sine-qua-non of RISC.
] But despite these specifications, RISC is more a philosophy than a set of
] design criteria, and almost everything is called RISC, even if it isn't.
Not at all true. No one calls the Intel486(tm) a RISC, nor the Motorola 68K
series, nor DEC's VAX architecture. All though there are "RISCy" VAXEN...
[ ... much wrong stuff deleted ... ]
I'd tell you MY opinion of what's distinctive about the RISC design
philosophy, but I think comp.arch's already played that record to death.
Your "definition" of CISC is just as flawed. I think John Mashey did
an magazine article recently on the subject that was good ( but not
indisputable ). Maybe he'll point it out to you, I've forgotten the mag.
] Appendix C:
] ==========
] Bubble Memories:
] ---------------
This discussion of "bubble" is completely irrelevant to the subject given.
] Ferroelectric and Ferromagnetic (core) Memories:
] -----------------------------------------------
Also irrelevant to the stated subject.
--
Dennis O'Connor doco...@sedona.intel.com
D John McKenna
>Say what? The 650x was about as unrelated to the 6800 as you could get, except
>for their both being 8-bit machines!
I was under the impression that the 6500 was designed by ex-Motorola
people, who wanted to build a better 6800. I heard that the original
6500 was actually pin-compatible with the 6800 (can anyone verify
this?). They removed the second accumulator, added another index
register, shrunk the index and stack registers, and added some more
addressing modes, but the basic philosophy was pretty much the same
(learn 6502, 6800 and 8085, and you'll see what I mean).
Later, there was a largish family of 650x chips - smaller than the 680x
family, but still more than you'd expect. Most of them were 6502s with
various bits missing (the 6507, used in the Atari 2600 had only 13
address lines and no IRQ pin). It looks like they were making cheap
chips for the microcontroller market.
But they were related, and the 6502 *definately* came after the 6800.
Oh yeah - there was also a 65808. This was (or is, really) a 65816
without the extra address lines. It could be plugged straight into a
6502 socket, and gave you most of the 65816 features - big registers (a
whole 16 bits!), more instructions, more addressing modes (stack pointer
relative at last). But it only had 16 bits of address, so some of the
extended addressing modes were of limited use. I know of nothing that it
was used in.
John West
--
gu...@uniwa.uwa.edu.au For the humour impaired: insert a :-) every 3 words
Dennis O'Connor
ke...@hplb.hpl.hp.com (Chris Dollin) writes:
] For my money, the *novel* feature of the ARM is that every instruction is
] conditional. But then, I'm hooked.
I know it's a little different, but isn't the idea of a "skip" instruction,
that causes the next instruction to not be executed, both older than
ARM's conditional instructions ( and RISC in general ), and semantically
identical, if one considers the skip-next_inst sequence to actually be a
single instruction ?
Chris Dollin
Hmm. Interesting ... but I don't think so [*1]. Trivially, of course, the
skip-sequences are ``much'' bigger than single instructions. And skips had a
built-in test, which the skipped instruction might change, if it *wasn't*
skipped. On the ARM you can have sequences like:
LDR R0, p
BL parker
LDR R1, q
TEQ R0, R1 if (parker(p) == q)
LDREQ R0, x
LDREQ R1, y
BLEQ witherspoon witherspoon( x, y);
where the last three instructions are all conditional on the result of the TEQ
(none of them set the condition flags); the comparison, if repeated at each
stage, would have different results as R0 and R1 were (re-)loaded. I don't
think this would be done with skip+next sequences, although oif you were
sufficently determined you *might*.
[*1] I agree that skip instructions are Venerable, of course.
--
Regards, "If anything anyone locks, they'll find it all ready in stocks."
Kers. ----------------------------------------------------------------
Anthony Shipman
>Part III: SC/MP, early advanced multiprocessing (April 1976)
> The National Semiconductor SC/MP, (nicknamed "Scamp") was a typical
>well-designed 8 bit processor. It featured 16 bit addressing, with 12 address
>lines and 4 lines borrowed from the data bus (it was common to borrow lines
>from the data bus for addressing). Internally, it included three index
>registers.
> The unique feature was the ability to completely share a system bus with
>other processors. Most processors of the time assumed they were the only ones
>accessing memory or I/O devices. Multiple SP/MPs could be hooked up to the
>bus, as well as other intelligent devices, such as DMA controllers. A control
>line could be chained along the processors to allow cooperative processing.
> This was very advanced for the time, compared to other CPUs. However, the
>SC/MP had no stack or subroutine instructions, though a stack could be
>emeulated to some degree.
A feature of the SC/MP that distinguished it from the rest is that it was
bit serial internally. Data was shifted through the ALU serially ie
with 1 bit wide buses. This made the chip very small and cheap.
The marketing push was to sell it as an embedded controller for commodity
stuff like washing machines, ovens and toys. In these applications price
mattered more the speed.
I vaguely recall something about a novel serial external interface too.
--
Anthony Shipman "You've got to be taught before it's too late,
CP Software Export Pty Ltd, Before you are six or seven or eight,
19 Cato St., East Hawthorn, To hate all the people your relatives hate,
Melbourne, Australia, 3121 You've got to be carefully taught." R&H
Joseph J. Kubicky
>>Part IV: Intel 8086, IBM's choice (1978)
>> So why did IBM chose the 8086 when most of the alternatives were so much
>>better? Apparently IBM's own engineers wanted to use the 68000, and it was
> They didn't. They chose the 8088. The 8806 was already in use
> in the Displaywriter. Rumor has it that Boca was forced to use
> the slower (4.88 MHz) 8088 to prevent the PC from competing with
> the Displaywriter. Can anyone confirm or deny this? (Come on,
> the statute of limitations for these things must have passed by
> now.)
According to Cringley's book, IBM chose the 808x because it was the only
16 bit processor of the time that had a full complement of support chips
(i.e. interrupt controller, I/O, etc.) available. He says that the
equivalent chips from Motorola, etc. weren't developed or available yet.
IBM wanted to get the PC out FAST (well, fast for IBM - 18months), so
they needed to be able to use all off-the-shelf type parts (although,
if you take a look at the schematics for the PC, you'll see IBM didn't
skimp on the discrete logic any).
The rumor I had heard (before I read Cringley's book) was that IBM owned
a bunch of Intel stock at the time so it was basically a business decision.
Jay Kubicky
jkub...@cco.caltech.edu
(P.S. Cringley's book is called Accidental Empires and I highly recommend it!)
Don Stokes
> Don Stokes has already pointed out that some of the DEC chips should be
> mentioned. A couple of additions/corrections to his comments:
>
> - The T-11 was not a reduced J-11. It was a separate design, aimed
> for very low cost, both for the chip and the system it was
Thanks for the correction on that one. I was only dimly aware of the T-11.
(I'm not even 100% sure which chip it is on an RQDX3.)
The VT240 is based on the 8085 (like the GIGI), and is as slow as a wet week.
Are you thinking of later graphics terminals (eg the VT330/VT340)?
> F-11, and later J-11, chips have appeared in such DEC devices
> as terminal servers and HSC's (disk controllers for clusters).
Yup. The ones I'm aware of are the DECSA, which was based on the PDP-11/24
(F-11) but with a custom backplane and the more recent DECserver 5xx servers,
which are basically Qbus PDP-11/73 (J-11) systems in BA213 boxes.
> - The original MicroVAX II chip was ahead of its time in many ways.
It was 25MHz for a start. Didn't get a hell of a lot done in all those
cycles, but the VAX architecture is *hell* to make fast!
> - The lastest VAX chips are pushing into the RISC performance range.
> Since these chips and the first Alpha chips are being built
> with the same technology, we can (as in the case of the Intel
> 386 and 860) factor that out an calculate the speed advantage
> of RISC. It seems to come out at a factor of 2 to 3 at the
> moment.
The 21064 (Alpha) does introduce some major changes in how CMOS is done,
notably 3.something volt operation (as opposed to the normal 5V).
One thing that DEC haven't said much about are the chips that drive the
VAX 4000/500 and 6000/600 processors. These little suckers are getting
up to 36 MIPS (on the 6000) at 65(?) MHz. That's an instruction issue rate
of one every two clocks. Not spectacular you say? Take a look at what you
have to do to decode a VAX instruction. The format goes like this:
[byte prefix] byte opcode [byte operand [byte,word or longword constant] ...]
The byte operand fields contain either a small constant or a mode and register
(4 bits each), followed by the actual operand value if the operand is not
contained in the byte.
That is, not only do you not know how large the operand fields are until
you decode the instruction, but you don't know where you are until you decode
individual operands as well. You have to have decoded all this stuff,
sequentially, before you know where the next instruction is. In short, it's
hell to pipeline properly.
2 clocks per instruction is "easy" on a RISC (well, a RISC tries to keep
things inder 1 clock per instruction), but not a in VAX. I'd love to
see some hard info on these chips.
--
John Nagle
16-bit machine. This was the first 16-bit microprocessor (?), but
due to weak marketing by TI, never took off. It appeared in the
TI 99/4 personal computer, which never took off either. It was
truly 16 bits, unfortunately, and could only address 64K of memory
effectively, although with some kludges one could do bank-switching
and get beyond that limit. Architecturally, it looked very much
like a PDP-11.
National Semiconductor built a whole line of VAX-like machines,
the NS16016, NS32032, and variations on that theme. These were the
basis of early Sequent UNIX boxes, and still appear as microcontrollers,
but never did much volume.
Zilog built a Z8000 (another PDP-11 like machine) and UNIX boxes
using it in the late 1970s, but it never caught on. They came up with
an improved version, the Z80000 (?) in the mid-80s, by which time nobody
cared.
IBM built a 68000 UNIX box around 1983, out of Instruments Division,
but never did much with it. It was a nice little package, with a graphics
screen in a desktop box with the computer.
Motorola's big mistake in the early days of the 68000 is that they
were years late with the support chips. The CPU came out in 1978, but
the FPU and MMU came years later, and the 68000 couldn't do instruction
backout on a page fault properly, so virtual memory on a 68000 was next
to impossible, although it was done in early Apollos (by having two CPUs,
one for the operating system) and on the Apple Lisa (by forbidding the use
of instructions that could cause a page fault and a register incrementation
both). The Apple Lisa had a MMU and a protected mode operating system, but
the MMU wasn't a single chip, so it added considerably to the cost. If
Motorola had had its MMU out when originally promised, the Lisa might
have been much more cost-effective and faster, and the whole history of
the Lisa/Mac line could have been very different.
John Nagle
william E Davidsen
|> Not quite. The 8085 and Z80 were separate developments of the 8080. The
|> 8085 improved the I/O (but introduced multiplexed address/data lines).
Actually the 8085 had a few extra undocumented instructions, too.
These were related to indirect fetch through the 126 bit registers, and
allowed programs compiled from languages like C to run a lot faster. I
sent a copy of a DR Dobbs article on the topic to the GE printer plant
in Waynesboro VA, where the instructions were tried and found to improve
performance to the point that GE contracted with Intel to supply the
parts with the instructions documented. There was a special part number
for the "GE8085" chip.
The rumor was that Intel didn't document these because the Z80 had so
many new instructions and they felt the 8085 would suffer by comparison.
Perhaps someone from Intel would comment on all this.
--
- bill davidsen (davi...@crd.ge.com)
GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
Robert Hyatt
>In article <471...@zl2tnm.gen.nz>, d...@zl2tnm.gen.nz (Don Stokes) writes:
>
>|> Not quite. The 8085 and Z80 were separate developments of the 8080. The
>|> 8085 improved the I/O (but introduced multiplexed address/data lines).
>
> Actually the 8085 had a few extra undocumented instructions, too.
>These were related to indirect fetch through the 126 bit registers, and
>allowed programs compiled from languages like C to run a lot faster. I
>sent a copy of a DR Dobbs article on the topic to the GE printer plant
>in Waynesboro VA, where the instructions were tried and found to improve
>performance to the point that GE contracted with Intel to supply the
>parts with the instructions documented. There was a special part number
>for the "GE8085" chip.
>
> The rumor was that Intel didn't document these because the Z80 had so
>many new instructions and they felt the 8085 would suffer by comparison.
>Perhaps someone from Intel would comment on all this.
>--
While we're into folklore, the Z80 had a whole batch of undocumented
instructions. Seems that hardware around the edge of the mask was
somehow unreliable, and so the instructions were simply "deleted"
from the documentation rather than having to "fail" the majority of
the chips.
Byte Magazine ran an article on these instructions way back when. I
had often found "bizarre" behavior in the Z80 while debugging assembler
code using the rather crude debuggers; it became obvious later that
when I executed some "data" that happened to have some of these
instructions, things would get changed (registers, flags, interrupt
status, etc.) without my knowledge. When checking things in the
debugger, I wound up scratching my head a lot. Byte cleared most of
this up. It seems that as the years went on, most of these odd
instructions became "safe" to use as the process used to make the
chips improved. Amazing...
--
!Robert Hyatt Computer and Information Sciences !
!hy...@cis.uab.edu University of Alabama at Birmingham !
Tom Lang
>
>]
>] This is a list of interesting, unique, or important microprocessors
>
>Which means a relatively arbitrary list. Some important ones where missed.
>
>it's not verifiable enough to be of any real use.
>
>As it is, I'd give it a C. Fix the bugs, especially the definitions, maybe
>you'll get a B. If you want an A, you'd better add footnoted references.
>
make it worth saving, and you give it a "C" ? So, it's not perfect, but posts
like this should be strongly encouraged! Sure beats wading through all the
noise, like the "shared libs" re-hash...
--
Tom Lang (la...@hal.com) phone: 512 794 2855
HaL Computer Systems - Austin,Tx FAX: 512 794 8737
Peter da Silva
> dozens of bugs in it.
To be sure. I have the 4004 and 8008 manuals in front of me.
> The first single chip CPU was the Intel 4004, a 4-bit processor meant for
> a calculator. It processed data in 4 bits, but its instructions were
> 8 bits long. Internally, it featured eight 4 bit registers which acted as an
> internal evaluation stack.
Actually, it had 64 bits of index register addressible as 16 4-bit registers
or 8 8-bit registers, plus 4 12-bit address registers that acted as a 4-element
stack. External ROM for the program was 8-bit, but external RAM was 20-bit,
organised as groups of 4 4-bit cells and an extra cell that was fetched using
a separate instruction.
> The 4004 had 46 instructions. Intel created an 8-bit version of this, the
> 8008.
The 8008 is clearly descended from the 4004, but it's also very close to the
8080. It still had the internal stack (now 8 14-bit registers) but the data
registers were the now familiar A B C D E H and L, with mem(HL) for indexing.
Memory was unified, with ROM and RAM in the same address space.
The instruction sets of the two machines were different. They were
cousins, rather than being versions of each other.
I have no information on the 4040. If it was compatible with the 4004 then
there is no way the 8080 could even be considered a cousin.
> Part I: RCA 1802, wierdness at its best (1974)
Weird? Not at all! Forgotten? It's still in use!
> The RCA 1802 was an odd beast, extremely simple and fabricated in CMOS,
> which allowed it to run at 6.4 MHz, very fast for 1974.
It also allowed it to power down to DC, essential for embedded control and
space applications.
> Apart from the COSMAC microcomputer kit, the 1802 saw action in some
> video games from RCA and Radio Shack, and legend has it the chip is the heart
> of the Voyager and Viking probes.
And Galileo. That's not legend, mate.
It's also been widely used in the real-time control systems due to its
extremely low power requirements and flexibility.
> A later version, the 1805, was enhanced, giving it several Forth language
> primitives, which could explain the high usage of Forth in control
> applications.
You have the cart before the horse. Forth was used in control applications
on its own merits, and the Forth primitives (whatever they are, the 1802
being already an excellent Forth engine) were added later.
> The Ferranti F100-L was designed by a British company for the British
> Military. It was an 8 bit processor, with 16 bit addressing, but strangely it
> could only access 32K of memory.
Probably used an address bit for indirection. That was a common technique in 16
bit systems.
> The Intel 860 wasn't Intel's first RISC chip - that was the 960, but the
> 960 was slow, and better suited for embedded control applications.
That's intel's story. From examination of the design, the 960 appears much
better for general purpose computing. The 860, with its highly complex
instruction scheduling requirements, is more like a DSP and in practice
seems to be used as a high end graphics coprocessor.
It's not the first time Intel has sold an embedded processor as a general
purpose CPU.
--
Peter da Silva `-_-'
Programmer, network firefighter, thrillseeker 'U`
Ferranti International Controls Corporation Have you hugged
Sugar Land, TX 77487-5012 +1 713 274 5180 your wolf today?
Rob McCool
: While we're into folklore, the Z80 had a whole batch of undocumented
: somehow unreliable, and so the instructions were simply "deleted"
: from the documentation rather than having to "fail" the majority of
: the chips.
:
: Byte Magazine ran an article on these instructions way back when. I
: had often found "bizarre" behavior in the Z80 while debugging assembler
: code using the rather crude debuggers; it became obvious later that
: when I executed some "data" that happened to have some of these
: instructions, things would get changed (registers, flags, interrupt
: status, etc.) without my knowledge. When checking things in the
: debugger, I wound up scratching my head a lot. Byte cleared most of
: this up. It seems that as the years went on, most of these odd
: instructions became "safe" to use as the process used to make the
: chips improved. Amazing...
I think the 6502 had a bunch of these, too. Apple II stuff didn't seem to, but
many Commodore games took advantage of them. Some were kind of neat, but
I can't think of any specifics offhand. A friend and I sat around with a
debugger one day and figured a whole slew of them out.
:
: --
: !Robert Hyatt Computer and Information Sciences !
: !hy...@cis.uab.edu University of Alabama at Birmingham !
--
Rob McCool..... NCSA STG System Administrator
Real name: ro...@ncsa.uiuc.edu
Known aliases: stga...@ncsa.uiuc.edu r-mc...@uiuc.edu sq...@mafia.org
John F Carr
>Part II: IBM RS/6000 POWER chip
> When IBM decided to become a real part of the workstation market
They made this decision about 7 years ago with the RT. They didn't
succeed, but they tried (a little).
>It does, however, violate the RISC philosophy of fewer instructions at over a
>hundred, versus only about 34 for the ARM and 52 for the Motorolla 88000
>(including FPU instructions).
The instruction count alone isn't a good measure. Many of the instructions
are simple variations on each other. For example, the "multiply and add
floating point" instruction comes in 4 forms (the output or one of the
inputs can be negated). The floating point add, subtract, and multiply
instructions are implemented using the same hardware.
--
John Carr (j...@athena.mit.edu)
J. Bayko
like to thank everyone for their comments.
A lot of people have mentioned that some more processors
should be included - particularly MIPS Rx000 and HP-PA.
I didn't want to make a survey of everything ever made, and
generally chose representatives of a particular type. For
example, the NS-32032 wasn't really different enough from
the 68000, I felt, so I only included one. For RISC chips,
I decided to chose two representatives to illustrate the
variety of philosophies. SPARC was the more radical, literal
RISC design, and the MC88000 was the more conventional
design with RISC principles (I considered the HP-PA, but the
flexible function units of the 88000 apealed to me).
But I'll consider adding both MIPS and HP-PA architectures,
as well as some of the other suggestions, for the next version
of the list.
Anyway, I'm still open for comments...
John Bayko.
J. Bayko
<1992May14.1...@oakhill.sps.mot.com>
hun...@oakhill.sps.mot.com (Hunter Scales)>>Part I: SPARC, an origional RISC
>
> Uh, what about MIPS (the Stanford one) and RISC I and RISC II,
> or are you only talking about *commercial* micros?
Yes, commercial micros. And it was *an* origional RISC, certainly
not the first or only...
John Bayko.
Sean Eric Fagan
> National Semiconductor built a whole line of VAX-like machines,
>the NS16016, NS32032, and variations on that theme. These were the
>basis of early Sequent UNIX boxes, and still appear as microcontrollers,
>but never did much volume.
There never was a '16016'. The original naming scheme had
<data-bus-bits>032; they decided to change this around, after a while (so
that my machine, which uses a 16032, can have the CPU replaced with the
32016, which is the same part, except it has fewer bugs in it).
--
Sean Eric Fagan | "One form to rule them all, one form to find them, one
s...@kithrup.COM | form to bring them all and in the darkness rewrite the
-----------------+ hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
Dik T. Winter
> In article <1992May13.2...@regina.cs.uregina.ca>
> ba...@hercules.uregina.ca (J. Bayko) writes:
> >It does, however, violate the RISC philosophy of fewer instructions at over a
> >hundred, versus only about 34 for the ARM and 52 for the Motorolla 88000
> >(including FPU instructions).
>
> The instruction count alone isn't a good measure.
on the i860. But, according to IBM, RISC is an acronym for
Reduced Instruction Set Cycles.
Even if we acknowledge the common acronym:
Reduced Instruction Set Computer,
what is reduced? Is this a reduced set of instructions or a set of reduced
instructions? I think the latter.
J. Bayko
<DOCONNOR.92...@potato.sedona.intel.com>
doco...@potato.sedona.intel.com (Dennis O'Connor)
writes:
>
>]
>] This is a list of interesting, unique, or important microprocessors
>
>Which means a relatively arbitrary list. Some important ones where missed.
>
>] from the very beginning to today. Not necessarily the first of their kind,
>] or the best.
>
>If not the first, the best, or the most succesful, what criteria IS used ?
a bunch of these wouldn't get mentioned (Intel 432 for example).
>
>] Anyway, I've done my best to be accurate, but I'm sure there are
>] dozens of bugs in it. I'd appreciate comments and corrections (I'll try
>] and add whatever feedback I get into the next version).
>
>What it really needs is more, footnoted, references. Lacking references,
>it's not verifiable enough to be of any real use.
brief for that!). And a lot of it is folklore anyway, not referencible
stuff.
>
>Actually, I think you need to think about defining "microprocessor".
I can do that, right? But basically, I've tried to keep it single-chip
and document the exceptions.
>
>] [...]
>] But despite these specifications, RISC is more a philosophy than a set of
>] design criteria, and almost everything is called RISC, even if it isn't.
>
>Not at all true. No one calls the Intel486(tm) a RISC, nor the Motorola 68K
>series, nor DEC's VAX architecture. All though there are "RISCy" VAXEN...
the 80486 and 68040 respectively. I don't really think IBM's POWER CPU
is really RISC either, being as complex as it is.
>
>I'd tell you MY opinion of what's distinctive about the RISC design
>philosophy, but I think comp.arch's already played that record to death.
>Your "definition" of CISC is just as flawed. I think John Mashey did
>an magazine article recently on the subject that was good ( but not
>indisputable ). Maybe he'll point it out to you, I've forgotten the mag.
consider it.
>
>] Appendix C:
>] ==========
>] Bubble Memories:
>] ---------------
>] -----------------------------------------------
>
appendix, right? Stuff related, but not necessarily relevant.
Technically, the Altair ad is about microcomputers, not microprocessors,
but it's interesting.
Anyway, thanks for the comments...
John Bayko.
Don Stokes
[undocumented instructions]
> I think the 6502 had a bunch of these, too. Apple II stuff didn't seem to, but
> many Commodore games took advantage of them. Some were kind of neat, but
There was much consternation in the education sector when it was discovered
that Apple Logo wouldn't run on the new 65C02 based Apple //s (the "portable"
//c and later model //es), because the undocumented instructions went away
on the 65C02...
Lupe Christoph
>In article <1992May13.2...@regina.cs.uregina.ca> ba...@hercules.uregina.ca (J. Bayko) writes:
>... There was also a chip set implementation (I think from
>WD) of the UCSD P-Code.
The Pascal Microengine. I used one of these. It was a nice machine,
but a dead end. That was the time of the great CISC debate, machine
architecture to support programming languages.
The Pascal Microengine showed the problem of this kind of approach nicely:
it was months late because the instructions that handled Pascal Sets
was buggy. These instructions took most of the microcode space.
--
| ...!unido!ukw!lupe (German EUNet, "bang") | Disclaimer: |
| lu...@ukw.UUCP (German EUNet, domain) | As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany) | this *is* the opinion |
| Res non sunt complicanda praeter necessitatem. | of my employer. |
Greg Lehey
>The instruction sets of the two machines [8008 and 8080] were different. They were
>cousins, rather than being versions of each other.
The 8008 instruction set was a complete subset of the 8080 instruction
set. The opcodes were different, however, so you couldn't run 8008
code on the 8080. However, you *could* re-assemble and run it,
assuming you were you were using the right assembler (they had two
different sets of mnemonics, too).
-------------------------------------------------------------------------------
Greg Lehey | Public access UNIX available - try BSDI
LEMIS | out on our machine! Mail and news
W-6324 Schellnhausen 2 | connections available
Germany | Fax: +49-6637-1489
Tel: +49-6637-1488 | Mail: grog%le...@Germany.Eu.net
Claimer: The opinions expressed *are* the opinions of LEMIS
*** NOTE ***: My mail headers are suffering from a virus. The correct
reply address is grog%le...@Germany.EU.net
Paul S Secinaro
>I think the 6502 had a bunch of these, too. Apple II stuff didn't seem to, but
> many Commodore games took advantage of them. Some were kind of neat, but
> I can't think of any specifics offhand. A friend and I sat around with a
> debugger one day and figured a whole slew of them out.
I'm pretty sure the 6502/6510 has undocumented instructions. I have a
list of them floating around somewhere, probably on one of by
Commodore 64 disks, but I also can't remember any offhand. I think a
few of them were pretty useful, but nothing earth-shattering.
Paul
--
Paul Secinaro | Synthetic Vision and Pattern Analysis Lab
ps...@kepler.unh.edu | Dept. of Electrical and Computer Engineering
p_sec...@unhh.unh.edu | University of New Hampshire
br...@king.csd.mot.com
>Left out proper mention of IM/HM 6100 and 6120.
Proper mention of the 6100 would also include noting it as a RISC micro.
Eight instructions, including NOP! That would put it at the far right
edge of the "bitness vs. risc/ciscness" graph, at the 12 bit vertical mark.
And where else could you get an evaluation board, complete with keyboard and
display, that ran on D-cells?
--
-Brian Smithson
Motorola Inc., Computer Group, Commercial Systems Division
2001 Logic Drive, M/S 1-E10, San Jose, CA 95124 USA, (408)369-4104
br...@ca41.csd.mot.com, {apple | pyramid}!motcsd!brian
br...@king.csd.mot.com
>In article <1992May14.1...@oakhill.sps.mot.com>, hun...@oakhill.sps.mot.com (Hunter Scales) writes:
>Say what? The 650x was about as unrelated to the 6800 as you could get, except
>for their both being 8-bit machines!
Well, they did have very similar external busses (one exception was the
VMA signal, as I recall). I don't remember enough about the 6800 to make
a good comparison, but I do remember the 6800 having two accumulators --
that was certainly different from the 6502.
John A. Weeks III
>>>Part IV: Intel 8086, IBM's choice (1978)
> According to Cringley's book, IBM chose the 808x because it was the only
> 16 bit processor of the time that had a full complement of support chips
> (i.e. interrupt controller, I/O, etc.) available. He says that the
> equivalent chips from Motorola, etc. weren't developed or available yet.
> IBM wanted to get the PC out FAST (well, fast for IBM - 18months), so
> they needed to be able to use all off-the-shelf type parts (although,
> if you take a look at the schematics for the PC, you'll see IBM didn't
> skimp on the discrete logic any).
I seem to recall that IBM was already shipping a 68000 based micro
computer at the time the PC came out. It was called the 5???, and it
was intended primarily for lab work or instrumentation...and it came
with BASIC.
-john-
--
==============================================================================
John A. Weeks III (612) 942-6969 jo...@newave.mn.org
Newave Communications, Ltd. ..!uunet!tcnet!newave!john
Michael Hermann
>There never was a '16016'. The original naming scheme had
><data-bus-bits>032; they decided to change this around, after a while (so
>that my machine, which uses a 16032, can have the CPU replaced with the
>32016, which is the same part, except it has fewer bugs in it).
>--
>Sean Eric Fagan | "One form to rule them all, one form to find them, one
>s...@kithrup.COM | form to bring them all and in the darkness rewrite the
>-----------------+ hell out of them" -- sendmail ruleset 3 comment from DEC.
>Any opinions expressed are my own, and generally unpopular with others.
I can remember announcment of 16008 and 16016. They were supposed
to have a "native mode", which was NOT 16032 compatible and an
8080 emulation mode. Same trick NEC used with V20-V50.
Best regards
Michael Hermann
:wq
R. E. Nather
I'm not familiar with the ARM instruction, but this comment reminded me of
two "ancient" architectures with interesting features: the IBM 650 was a 2+
instruction machine with a "go to" as one part of every instruction, and the
DGC Nova had a 5-part instruction (Carry_set, Op, Shift, Test, Discard) that
allowed you to write some thoroughly inscrutable single instructions. All
five parts execute, in the sequence given above, in each instruction. All
parts have NOP options, and you rarely find a circumstance where you need
all 5, but when you do there is a quiet satisfaction in doing a job all in
one insturction. As an example, in the old "sieve" benchmark, the inner
loop had the sequence "i + i + 1" which could be done in a single Nova
instruction. The original Nova had a real elegence to the architecture
which was thoroughly kludged and bungled in later incarnations (IMHO).
mar...@vax.oxford.ac.uk
> In article <1992May15.2...@news.cso.uiuc.edu> ro...@void.ncsa.uiuc.edu (Rob McCool) writes:
>
>>I think the 6502 had a bunch of these, too. Apple II stuff didn't seem to, but
>> many Commodore games took advantage of them. Some were kind of neat, but
>> I can't think of any specifics offhand. A friend and I sat around with a
>> debugger one day and figured a whole slew of them out.
>
> I'm pretty sure the 6502/6510 has undocumented instructions. I have a
> list of them floating around somewhere, probably on one of by
> Commodore 64 disks, but I also can't remember any offhand. I think a
> few of them were pretty useful, but nothing earth-shattering.
be undocumented can they. The list counting as documentation.
Don Nichols (DoN.)
>ba...@hercules.cs.uregina.ca (J. Bayko) writes:
[ ... ]
>> Part V: The 6809, extending the 650x
>>
>> The 6800 from Motorolla was essentially the same design as the 6502, but
>> with some tweaking here and there. But the successor was a major advance - at
>> least relatively.
>
>Other way around -- the 6502 was "based" on the 6800 (which has the dubious
>distinction of having a "halt and catch fire" instruction). The 6809 was an
>improvement on the 6800 series, maybe borrowing things from other processors.
But, the HCF instruction (acutally, many other processors had
similar undocumented instructions for factory testing, or as side effects of
instruction decoding logic) was quite usefull in hardware debugging. It
would cycle through all addresses, with the data bus tri-stated, and it was
easy with a scope to detect address pins shorted together, or other
addressing problems. I generally kept a eprom around with the reset vector
pointing straight at the HCF instruction for testing when not enough was
working to get some sort of monitor eprom to talk to a terminal.
--
Donald Nichols (DoN.) | Voice (Days): (703) 704-2020 (Eves): (703) 938-4564
D&D Data | Email: <dnic...@ceilidh.beartrack.com>
I said it - no one else | <dnic...@ceilidh.aes.com>
--- Black Holes are where God is dividing by zero ---
Peter da Silva
>In article <id.M1...@ferranti.com> pe...@ferranti.com (Peter da Silva) writes:
>>The instruction sets of the two machines [8008 and 8080] were different. They were
>>cousins, rather than being versions of each other.
>The 8008 instruction set was a complete subset of the 8080 instruction
>set.
I find that hard to believe, since the way the two machines handle the
stack was completely different (the 8008 had a hardware stack in the CPU,
the 8080 has a conventional stack pointer).
>The opcodes were different, however, so you couldn't run 8008
>code on the 8080. However, you *could* re-assemble and run it,
>assuming you were you were using the right assembler (they had two
>different sets of mnemonics, too).
Assuming you didn't do enough subroutine calls to overflow the 8008's
internal stack, too, I guess.
--
# Peter da Silva pe...@taronga.com Have you hugged your wolf today?
# Taronga Park BBS +1 713 568 0480/1032 `-_-'
# Houston, TX, USA 'U`
# :vx:!sed -n '/# :vx/s/^[^#]*#/#/p' % >> $HOME/.signature
Charles Lasner
>las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>>Left out proper mention of IM/HM 6100 and 6120.
>
>Proper mention of the 6100 would also include noting it as a RISC micro.
>Eight instructions, including NOP! That would put it at the far right
>edge of the "bitness vs. risc/ciscness" graph, at the 12 bit vertical mark.
Not a NOP! A little review of the -8 instruction set (simplified):
There are SIX instructions that reference memory. All of them operate in
one of five addressing modes. The two that affect program flow use a
different form of memory extension than the four data handling types.
There is also a general purpose input/output class that allows for hundreds
of I/O instructions to be defined. Several dozen are standard including the
ones that control extended memory.
The last one isn't an instruction, rather it's a group known as the "Operate"
group. It defines 512 instructions; at least 3 of them are NOP's as a
consequence of the group being broken down into 3 sub-groups, each of which
can be a NOP if no actions are defined. All of the instructions are based on
the notion that non-conflicting operations can be carried out simultaneously,
so the entire instruction takes one cycle regardless of complexity.
For example, the second group consists of any instruction of the form:
1 1 1 1 C X Y Z R S H 0
The basic purpose is to test and possibly skip. The group is denoted by the
fact that the instruction is of the form 1 1 1 1 x x x x x x x 0.
If all of the x bits are 0, then this is this group's NOP. The X Y Z and R
bits form the basis of the test. Properly combined they mean:
SPA skip next instruction of accumulator positive (sign bit off)
SNL skip if Link (carry) bit set
SNA skip if AC is non-zero
These three AND together in terms of the skip condition, thus:
SPA SNA is skip only if the AC is strictly positive thus isolating the zero
case. The anding is indicated by setting the R bit. If the R is the only
test bit set, then it is an unconditional SKP.
If the R bit is clear, then the three conditions reverse to become:
SMA skip if AC negative (sign bit on)
SZL skip if Link zero (clear)
SZA skip if AC is zero (all clear)
Additionally, these tests then OR together. Thus, all forms of 12-bit
logical tests are available, as well as most 13-bit ones for unsigned
arithmetic purposes.
The C bit indicates to clear the AC after the test regardless of the
skip's outcome. The S bit means to OR the front panel switch register
into the AC after all of the above. The H bit means to halt the CPU after
all of the above. Front panel continue resumes operation. Note that
any skip-test instruction can therefore have the H bit patched in to cause
the machine to halt there without re-assembly. This has been used to debug
real-time routines where the intrusion of a debugger is intolerable.
Another class is used to manipulate the AC and L including clearing,
complementing, rotating, byte-swap, etc. Within this group is another
clear the AC and another NOP (there are 3 each).
The third class is not available on the 6100 which mimics the PDP-8/e which
is often provided without the EAE option (Extended Arithmetic Element).
Not enough logic was brought out for implementation. The 6120 gates the info
correctly to allow a "coprocessor"-type implementation of the EAE to mimic
this standard PDP-8/e option. This set includes Multiply, divide, long
left and right shifts, both arithmetic and logical, double-precision add,
load, store, increment, test, normalize, etc. (and a NOP and CLA.) The
DECmates do not implement EAE.
Interrupts, stack operations, memory management, and miscellaneous register
interactions are implemented as I/O operations, including vectored
interrupts on the 6120.
The 6 instructions are TAD (Two's complement add; DEC had one's complement
machines at the time so they needed to tell them apart.), logical AND,
Increment memory and Skip next if it becomes Zero (ISZ), Deposit and Clear
Accumulator (which since it also clears, removes most of the need for a
load AC), JuMP and JuMp to Subroutine (JMP and JMS respectively). The
six instructions all operate in one of five addressing modes:
Direct mode:
The current page of memory is the page where the operand is. The instruction
specifies which relative member of the current page the effective address is.
Page Zero mode:
The Zero page of memory (locations 0000-0177) is where the operand is. The
instruction specifies the relative member of page zero where the effective
address is. This is useful for global variables and global reusable literal
data such as constants and addresses.
Indirect mode:
The current page of memory is where the pointer to the operand is. The
instruction specifies which relative member of the current page is the
pointer address. This in turn points to the effective address which can
be on any memory page.
Page Zero Indirect mode:
The Zero Page is where the pointer is except that the relative member of
page zero must not be 0010-0017. Operation is the same as in current page
indirect mode. Note that global address pointers on page zero can be used
this way. Global subroutine calls are formed this way using reusable
literal addresses of routines or data, etc.
Auto-increment mode:
If the Zero Page pointer is specifically in the range 0010-0017 then a
special case change is made: The contents of the specified 0010-0017 is
used as an index register, in that it is pre-incremented before being used
as the pointer address. This is of course used to access tables without
having to separately increment address pointers. The only disadvantage is
that there is some setup overhead (they have to be initialized to
{address-1} of any data, and the fact that the auto-increment can't be
disabled. Note that programs that require less than 8 auto-increment
registers can store directly addresses literal data in these locations to
avoid waste.
Still want to call the PDP-8 a machine with only 8 instructions? :-)
cjl
LEMIEUX GUY GERARD
>In article <471...@zl2tnm.gen.nz> d...@zl2tnm.gen.nz (Don Stokes) writes:
>>ba...@hercules.cs.uregina.ca (J. Bayko) writes:
>
>>Other way around -- the 6502 was "based" on the 6800 (which has the dubious
>>distinction of having a "halt and catch fire" instruction). The 6809 was an
>>improvement on the 6800 series, maybe borrowing things from other processors.
>
> But, the HCF instruction (acutally, many other processors had
>similar undocumented instructions for factory testing, or as side effects of
>instruction decoding logic) was quite usefull in hardware debugging. It
>would cycle through all addresses, with the data bus tri-stated, and it was
>easy with a scope to detect address pins shorted together, or other
>addressing problems. I generally kept a eprom around with the reset vector
>pointing straight at the HCF instruction for testing when not enough was
>working to get some sort of monitor eprom to talk to a terminal.
For the 6502 I usually just drive $EA on the data bus. This is the NOP
instruction. The CPU should then simply do NOPS and the address bus
should simply cycle. Mind you, if you want to do this as a CPU instruction
you need a little extra external hardware to disconnect the chip selects
of everything else on the data bus and place $EA on there. Then by writing
to a specific memory location you can trigger this external hardware and
go into the NOP loop. Shouldn't take much more than a couple of AND and
inverter chips to do.
Guy Lemieux
lem...@ecf.toronto.edu
John Serafin
I notice that no one has mentioned the first 64 bit microprocessor,
the "Saturn" from HP, used in the HP-71, HP-28 (C & S), the
HP48 (SX & S), and miscellaneous other HP calculators. The
Saturn processor uses 64 bit integers, 64 bit floats, 20 bit
nibble addressing, and has a 4 bit bus. In 1984, HP-71s running
at 600kHz executed numerical benchmarks in interpreted BASIC faster
than Apple IIs, Ataris, and IBM PCs running the same programs in
interpreted BASIC. This does not even take into account the fact
that the transcendental functions for the latter machines were
inaccurate even for single precision, that double precision on them
was no better than single precision, or that the HP-71 functions
were accurate to 12 digits. It was simple to speed up HP-71s to
900kHz. The Saturn CPU in the HP-28 runs at 1MHz and can be sped up
with software to 2MHz. The HP48 runs at 2MHz.
There were several features to mitigate the effects of a 4 bit bus.
Among them, each RAM or ROM module kept a copy of the instruction
pointer in order to know whether it was addressed so that the CPU
did no have to send the full 5 nibbles of addresses most of the time.
--
John P. Serafin | Operating a bicycle is more like driving than riding.
j...@netcom.com | Operating an automobile is more like riding than driving.
Peter David THOMPSON
>In article <1992May13.2...@regina.cs.uregina.ca> ba...@hercules.uregina.ca (J. Bayko) writes:
>>...
>>RISC and CISC definitions:
>>...
>>Basically, RISC asks whether an instruction
>>is necessary, or whether it can be replaced by several simpler instructions
>>without a major performance loss.
>>...
>>The [CISC]
>>philosophy is that if a complex instruction can result in an overall increase
>>in speed, it's good.
>Let's see, RISC says optimize the instruction set for maximum performance
>and CISC says optimize the instruction set for maximum performance. Wait,
>something's wrong!. Could it be that there's really not a "philosophical"
>issue here!!?? No, that's impossible, that would contradict everything
>we've been told.
Perhaps there should be a ;') (or rather a :-) after that last posting. I
would have thought that most people know that the basis of RISC is not
how many instructions can be removed, but how many need to be provided.
(If you feel you know what RISC is stop here).
The philosophy of RISC (as it has been explaned to me) is to a) make it
simple and b) make it fast. Both objectives tend to produce chips similar
to those today, with uniform format, uniform width instructions (less
complex decode logic => faster decode, uniform width => faster prefetch)
that perform simple tasks (things should be done in a single clock cycle so
we can pipeline). There is no objection to having a multiply in a RISC
instruction set, as long as it completes in a single clock cycle.
The other reason for RISC is that the semantic gap is not all that much
of a problem with a good compiler. RISC makes it easier to match your
language to hardware (LISP (mostly) excepted) by providing an architecture
that is equally bad at any language....
Thanks for reading the ramblings of a confirmed 68k family addict..
* These opinions belong to p...@mundil.cs.mu.OZ.AU unless otherwise specified.
"GNU Make will no longer go into an infinite loop when fed the horrid trash
that passes for makefiles that `imake' produces (so you can compile X, despite
the extreme stubbornness and irrationality of its maintainers)."-version 3.55
Joel Kolstad
>
>I notice that no one has mentioned the first 64 bit microprocessor,
>the "Saturn" from HP, used in the HP-71, HP-28 (C & S), the
>HP48 (SX & S), and miscellaneous other HP calculators. The
>Saturn processor uses 64 bit integers, 64 bit floats, 20 bit
>nibble addressing, and has a 4 bit bus. In 1984, HP-71s running
>at 600kHz executed numerical benchmarks in interpreted BASIC faster
>than Apple IIs, Ataris, and IBM PCs running the same programs in
>interpreted BASIC. This does not even take into account the fact
>that the transcendental functions for the latter machines were
>inaccurate even for single precision, that double precision on them
>was no better than single precision, or that the HP-71 functions
>were accurate to 12 digits. It was simple to speed up HP-71s to
>900kHz. The Saturn CPU in the HP-28 runs at 1MHz and can be sped up
>with software to 2MHz. The HP48 runs at 2MHz.
>There were several features to mitigate the effects of a 4 bit bus.
>Among them, each RAM or ROM module kept a copy of the instruction
>pointer in order to know whether it was addressed so that the CPU
>did no have to send the full 5 nibbles of addresses most of the time.
What you say is completely true. However, I think that these days most
"palm tops" can kick a HP-48 in doing math benchmarks. The sad fact is that
HP has been using this same processor SINCE the HP-71 came out! This isn't
bad in itself... it's just that it opens HP up to a lot of competition.
Considering the ever shrinking gap in the difference between something like
an HP 48SX and a palm top PC clown (say, a HP 95LX), it's hard to say how
much longer "calculators" as such are going to be around (high end calculators,
that is.)
Also, realize that 2MHz on an HP-48 isn't 2MHz on an Atari or Apple. The
48 instructions are 5 clock cycles, giving .4 MIPS (Meaningless
Indication of Processor Speed). The IBM PC happens to use 5, too. 6502-based
machines use 1. (Which is why a 1MHz C-64 can do some things faster than a
PC XT...)
If HP continues on with the Saturn product line, it'd probably be in their
best interest to kick the architecture up to 8 bits and crank the clock.
(Which, you might notice, is something that'd be EASY to do on the HP-48SX --
the expansion ports on the 48 are already 8 bits. It's the internal
"peripherals" (the RAM "images," ROM, I/O, etc.) that still run on the old
4 bit Saturn bus. The question is whether or not redesigning the 48 to
make it faster is profitable for HP...
---Joel Kolstad
Sean Eric Fagan
>Also, realize that 2MHz on an HP-48 isn't 2MHz on an Atari or Apple. The
>48 instructions are 5 clock cycles, giving .4 MIPS (Meaningless
>Indication of Processor Speed). The IBM PC happens to use 5, too. 6502-based
>machines use 1. (Which is why a 1MHz C-64 can do some things faster than a
>PC XT...)
A 6502 takes between 2 and 7 cycles to execute an instruction. Most
instructions are 2 or 3 cycles long. (Remember, at least one cycle to fetch
each byte of the instruction.)
D John McKenna
>A 6502 takes between 2 and 7 cycles to execute an instruction. Most
>instructions are 2 or 3 cycles long. (Remember, at least one cycle to fetch
>each byte of the instruction.)
With the 6502, it is almost exactly 1 cycle/byte that needs to be
accessed. There are very few 'dead' cycles if you go through and look at
it. The exeptions are the 1 byte/2 cycle 'immediate' instructions and a
the writing instructions with indexed addressing (and a few others). For
the first, I suspect some result of their pipeline. For the second,
well...
Ever wonder why the 6502 is a little-endian beast? Why you have to
specify the low byte of the address first? Its because of the indexed
instructions. What happens:
1) The processor fetches the opcode, and figures out that it is an
indexed instruction with a 16 bit address.
2) The processor fetches the low byte of the address
3) Fetch the high byte, and simultaneously add the index to the low byte
4) Try the data fetch, and add the carry from the previous add to the
high address byte
5) (optional) If there was a carry, the address was wrong - do the fetch
again
So if you don't cross a page boundary, the instruction only takes 4
cycles. Obviously this doesn't work so well with writes - 'Oops. The
address was wrong. Cancel that write!'
Another interesting point is that the 6502 accesses memory on *every*
cycle. If it has nothing better to do, it fetches from $FFFF.
John West
--
gu...@uniwa.uwa.edu.au For the humour impaired: insert a :-) every 3 words
Torben AEgidius Mogensen
>ke...@hplb.hpl.hp.com (Chris Dollin) writes:
>] For my money, the *novel* feature of the ARM is that every instruction is
>] conditional. But then, I'm hooked.
>I know it's a little different, but isn't the idea of a "skip" instruction,
>that causes the next instruction to not be executed, both older than
>ARM's conditional instructions ( and RISC in general ), and semantically
>identical, if one considers the skip-next_inst sequence to actually be a
>single instruction ?
This is actually a very important point: the fact that the test
doesn't add to the cycle count makes it have an advantage over forward
branches in many more instances. The HP PA-RISC has a conditional
skip-next-instruction field on many of its instructions, again adding
no overhead. This is closer to the original "skip" instructions.
I believe the ARM is the first microprocessor to combine conditions
with a wide variety of general purpose instructions. Remember that
PA-RISC has only recently been moved to microprocessors.
Torben Mogensen (tor...@diku.dk)
Torben AEgidius Mogensen
>In article <1992May14.1...@odin.diku.dk> tor...@diku.dk (Torben AEgidius Mogensen) writes:
>>Another novel feature is the save/load multiple registers
>>instructions. These allow any subset of the 16 registers to be
>>transferred to or from memory. This takes advantage of fast sequential
>>access to dynamic memory, and makes procedure calls fairly efficient.
>In what way is this feature "novel" ? Is it any different from the 68000 MOVEM
>instruction ?
It is unusual for a RISC, but maybe "novel" is too strong a word. The
feature that distinguish the ARM istructions from the 68000
instructions is the use of burst mode access to dynamic memory and the
fact that also the status bits and the PC can be saved and restored
using these instructions.
Torben Mogensen (tor...@diku.dk)
Charles Lasner
>In article <1992May17.2...@doug.cae.wisc.edu> kol...@cae.wisc.edu (Joel Kolstad) writes:
>>Also, realize that 2MHz on an HP-48 isn't 2MHz on an Atari or Apple. The
>>48 instructions are 5 clock cycles, giving .4 MIPS (Meaningless
>>Indication of Processor Speed). The IBM PC happens to use 5, too. 6502-based
>>machines use 1. (Which is why a 1MHz C-64 can do some things faster than a
>>PC XT...)
>
>A 6502 takes between 2 and 7 cycles to execute an instruction. Most
>instructions are 2 or 3 cycles long. (Remember, at least one cycle to fetch
>each byte of the instruction.)
And for comparison, a 1965 implementation of the original PDP-8 takes 1 cycle
to fetch the instruction and execute it, and then a second cycle if the
instruction references memory again (a direct memory reference) and then a
third cycle if the instruction was an indirect reference. Most instructions
are 1 or 2 cycles long. Since all instructions are the same size, there is
no inefficiency of not knowing what the instruction length is, etc. No
pipelining of any kind was used in this early design, so all cycles ran at
precisely the same cycle time of 1.5 microseconds each as determined by the
xtal-controlled system clock. (As an accomodation to the up-to 50 foot long
external I/O bus which uses shielded cables, etc., some of whose signals are
driven by pulse transformers, the I/O cycle is stretched out an extra 3.0
microseconds so that I/O pulses can occur every 1.0 microseconds after the
1.5 microsecond fetch time of the IOT instruction. Later versions eliminated
much of this in two ways: if the peripheral wasn't located on the external
bus, it signaled the INTERNAL I/O signal to the processor, so the entire
stretch sequence was eliminated, thus I/O cycles are as long as fetch cycles.
Even if the IOT is on the external bus, it is only stretched as much as
necessary, in that the instruction itself determines need: On the original
PDP-8 negative buss, the I/O is of the form 6xxY where Y is 1-7. If Y=0 then
the cycle just wastes time, since there is nothing to initiate I/O with. For
Y=1-7, each bit that is a one creates a timing state on the buss that can be
used for an I/O transaction. A typical sequence might be: 6xx1 is skip on
input flag, 6xx2 is clear input flag and accumulator, 6xx4 is OR data into
accumulator. Thus 6xx1 is not functionally ever associated (in the same
instruction) with 6xx2 and 6xx4, while it would be likely to find 6xx2 and
6xx4 combined together. So, the later designs would remove the unreferenced
timing states. 6xx1 takes only one stretched state, while 6xx6 only generates
the 6xx2 and 6xx4 states; only 6xx7 takes as long as the original PDP-8 buss
design.)
Note that there is little in the PDP-8 design that "violates" any "rules" of
"modern" hardware design, thus most speedup techniques could apply. Given
half the effort typically applied to some other machines, a quite fast PDP-8
design is quite reasonable.
cjl
Greg Goss
>
> >instructions. These allow any subset of the 16 registers to be
> >transferred to or from memory. This takes advantage of fast sequential
> >access to dynamic memory, and makes procedure calls fairly efficient.
>
> In what way is this feature "novel" ? Is it any different from the 68000
> MOVEM
> instruction ?
Why is it novel in the 68000's? It's been on mainframe computers since the
60's. Is there any REAL difference between mainframes and micros when we're
talking about architectural concepts?
.../greg
--
"say NO to four-line sigs" greg...@mindlink.bc.ca
J. D. McDonald
>And for comparison, a 1965 implementation of the original PDP-8 takes 1 cycle
>to fetch the instruction and execute it, and then a second cycle if the
>instruction references memory again (a direct memory reference) and then a
>third cycle if the instruction was an indirect reference.
However, this meaning of "cycle" is not quite all there was to it. Actually,
these were "memory cycles" rather than "clock cycles". There were at
least 4 clock ticks per memory cycle. The original PDP8 was built of
"flip-chip" modules (discrete transistors, resistors, diodes and,
yes, folks, capacitors) that, mostly, ran at a nominal 2 MHz max rate.
>Note that there is little in the PDP-8 design that "violates" any "rules" of
>"modern" hardware design, thus most speedup techniques could apply. Given
>half the effort typically applied to some other machines, a quite fast PDP-8
>design is quite reasonable.
Yes, it would make a good test case for 10GHz clock GaAs.
I should add that I am really sorry that I never had a genuine discrete
logic PDP8 to play with - I got the first and simplest TTL one. I did
build a very complicated interface unit (over 2000 wire wraps) out
of DEC's TTL plug in modules.
Doug McDonald
Greg Lehey
>In article <1...@adagio.UUCP> gr...@adagio.UUCP (Greg Lehey) writes:
>>In article <id.M1...@ferranti.com> pe...@ferranti.com (Peter da Silva) writes:
>>>The instruction sets of the two machines [8008 and 8080] were different. They were
>>>cousins, rather than being versions of each other.
>
>>The 8008 instruction set was a complete subset of the 8080 instruction
>>set.
>
>I find that hard to believe, since the way the two machines handle the
>stack was completely different (the 8008 had a hardware stack in the CPU,
>the 8080 has a conventional stack pointer).
This is correct. However, there were no instructions on the 8008 to
explicitly manipulate the stack (it was only implicitly manipulated by
CALL and RET instructions, both of which could be conditional). The
8080 supports these instructions too, so it was able to execute the
programs.
>>The opcodes were different, however, so you couldn't run 8008
>>code on the 8080. However, you *could* re-assemble and run it,
>>assuming you were you were using the right assembler (they had two
>>different sets of mnemonics, too).
>
>Assuming you didn't do enough subroutine calls to overflow the 8008's
>internal stack, too, I guess.
Well, no, the 8080 would even handle this situation.
One point occurs to me now: since the 8008 didn't have (need) a stack
pointer, you would have to modify the programs at least as far as
getting the SP register to point to a 14-byte stack area. But compared
to other conversions, that would be trivial (remember, this is just
one instruction. Might even have space in your 1702 between a couple
of restart vectors for that).
Jim Frost
>I am given to understand that
>load/store multiple instructions are not usually found on RISC processors - for
>example, PA-RISC hasn't got them.
The RS/6000 has stm/lm and a number of similar instructions, SPARC has
ta.
It's not so uncommon even for RISC.
jim frost
ji...@centerline.com
Jim Frost
that RISC tends to have very few addressing modes and instruction
formats, simplifying just about everything in executing instructions,
and lots of general-purpose registers. The lack of convenient memory
addressing makes compiler writers put some effort into dataflow
analysis instead of just letting the chip handle the data.
This technique is forced down your throat in RISC, but it also works
for CISC. For example, the PL.8 compiler built by IBM for the 801
project was also used on the 370 architecture -- and it produced
significantly faster code than its CISC-aware counterparts.
To quote from the IBM Journal of R&D Jan 1990, "The Evolution of RISC
Technology at IBM:"
"We discovered that our [370/168], running code generated by the PL.8
compiler, consistently ran between 4.5 and 6 MIPS at a time when it
was considered an accomplishment to drive the 168 at 2 MIPS. [...]
Abstaining from the CISC-like operations of the System/370 and using
it like a RISC machine gained substantial performance improvement.
This was largely due to the effort of the PL.8 compiler to reuse data
already present in the registers of the System/370. [...] This
demonstrated conclusively that an appropriate combination of
RISC-based architecture and an optimizing compiler can outperform a
CISC-based CPU for a comparable program-instruction stream without
materially expanding the program code."
The rest of the article is similarly interesting. If you're at all
interested in RISC vs CISC, I'd consider it a must-read.
Happy hacking,
jim frost
ji...@centerline.com
Joel Kolstad
>
>instructions are 2 or 3 cycles long. (Remember, at least one cycle to fetch
>each byte of the instruction.)
Right... but, the 6502 has a 2 phase clock: You could say, then, that a
6502 at 1Mhz with it's 2 phase clock is really a 2MHz clock. It is
somewhat confusing.
I was just expressing the 2 cycles/instruction as the base instruction
cycle unit. Things like the 48 certainly take more than 5 cycles for
"hard" instructions too.
---Joel Kolstad
Greg Goss
>
> > So why did IBM chose the 8086 when most of the alternatives were so much
> >better? Apparently IBM's own engineers wanted to use the 68000, and it was
>
> They didn't. They chose the 8088. The 8806 was already in use
> in the Displaywriter. Rumor has it that Boca was forced to use
> the slower (4.88 MHz) 8088 to prevent the PC from competing with
> the Displaywriter. Can anyone confirm or deny this? (Come on,
> the statute of limitations for these things must have passed by
> now.)
>
The version of the story as I heard it (some mag article circa '86 on the
history of MS-Dos) was that the PC was halfway through design as a generic CP/M
(Z80 or whatever) system when they went to talk to Microsoft for BASIC
licensing rights and advice on the other system software. Microsoft wanted
more memory space to write applications for and convinced them to redesign the
machine to use an 8-bit 8088 instead. Since the data path is still 8 bit, this
didn't disrupt too many of the design decisions they'd already made. Microsoft
then told them to use CP/M-86, a plan that fell through for ludicrous reasons,
much to Microsoft's eventual wealth.
Greg Goss
>
> > The 6500 *was* essentially, a 6800. The 6502 was similiar but
> > not identical.
> >
>
> Say what? The 650x was about as unrelated to the 6800 as you could get,
> except
> for their both being 8-bit machines!
I've never programmed either, but the impression I've gathered from reading
folklore of the era was that the 6500 was a stripped-down 680x sold for some
ludicrously low price. So this version of the history would have the 650x and
the 680x related, but in the opposite direction than the author of the big list
had it.
Charles Lasner
Agreed. Architecturally, a micro is a mainframe stripped of the ability to
do high-speed I/O to many devices. Raw I/O speed may be comparable, but
not able to be "parcelled" out in practical designs as compared to existant
large machines such as high-end PDP-10/20 and 360/370 and their descendents.
Also, micros tend to have cheap I/O peripherals where there is a lot of
CPU overhead/intrusion into the I/O such as the poor implementation of SCSI
on a Macintosh or NeXt. Mainframes may have auxiliary processors to shovel
data without host interaction other than overall control. Also, mainframes
will tend to be able to accomplish N-way transfers to different memory areas
to avoid memory-system overhead while doing simultaneous DMA, etc.
In any case, in basic CPU comparisons, a CPU is a CPU whether Micro, Mini or
Mainframe (a definition that often overlaps anyway).
cjl
Guy Harris
>
>... SPARC has ta.
"ta" is "trap always" on SPARC; it serves as a load/store multiple
instruction only if the trap handler loads or stores multiple registers,
which it would probably do with "ldd" or "std".
br...@king.csd.mot.com
>ba...@hercules.cs.uregina.ca (J. Bayko) writes:
>>Part III: SC/MP, early advanced multiprocessing (April 1976)
>A feature of the SC/MP that distinguished it from the rest is that it was
>bit serial internally. Data was shifted through the ALU serially ie
>with 1 bit wide buses. This made the chip very small and cheap.
That reminds me -- someone (Motorola maybe?) introduced a 1-bit processor
in the early 80's. This wasn't a bit slice. It was more like what is
described above for the SC/MP, but the chip was 1-bit internally and
externally. Does anyone remember details on this?
--
-Brian Smithson
Motorola Inc., Computer Group, Commercial Systems Division
2001 Logic Drive, M/S 1-E10, San Jose, CA 95124 USA, (408)369-4104
br...@ca41.csd.mot.com, {apple | pyramid}!motcsd!brian
Charles Lasner
>In article <1992May18.1...@cunixf.cc.columbia.edu> las...@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>
>>And for comparison, a 1965 implementation of the original PDP-8 takes 1 cycle
>>to fetch the instruction and execute it, and then a second cycle if the
>>instruction references memory again (a direct memory reference) and then a
>>third cycle if the instruction was an indirect reference.
>
>However, this meaning of "cycle" is not quite all there was to it. Actually,
>these were "memory cycles" rather than "clock cycles". There were at
>least 4 clock ticks per memory cycle. The original PDP8 was built of
>"flip-chip" modules (discrete transistors, resistors, diodes and,
>yes, folks, capacitors) that, mostly, ran at a nominal 2 MHz max rate.
This is analogous to using n-phase clocks today, and only underscores the
inherent efficiency of the architecture. Imagine upscaling the clock while
leaving all else fairly much the same.
>
>
>>Note that there is little in the PDP-8 design that "violates" any "rules" of
>>"modern" hardware design, thus most speedup techniques could apply. Given
>>half the effort typically applied to some other machines, a quite fast PDP-8
>>design is quite reasonable.
>
>Yes, it would make a good test case for 10GHz clock GaAs.
>
>I should add that I am really sorry that I never had a genuine discrete
>logic PDP8 to play with - I got the first and simplest TTL one. I did
>build a very complicated interface unit (over 2000 wire wraps) out
>of DEC's TTL plug in modules.
>
>Doug McDonald
>
>
DEC's original bus is highly demultiplexed. There isn't a single
bi-directional signal on it, so you need many drivers. Also, the cards drive
a very "analog" buss, so this adds further to the complexity. DEC's basic
scheme of little cards with few pins (the PDP-8 had one-sided, while the
8/i you refer to was at least double-sided!) has proven troublesome regardless
of architecture. You can't get a lot of logic into the real estate. Many
of the cards have three chips on them and lotsa empty space because there are
only 36 pins on the card, including power/gnd, etc.
The OMNIBUS PDP-8/e version was better, because some signals are multiplexed
such as the AC data in/out. All buss lines can be driven/received by chips
so the entire interface, including the logic of your device, can likely
be implemented on a single card. Also, off-the-buss expansion can be achieved
by over-the-top connectors between cards.
Since the 8/a introduced Hex-wide cards, the number of cards needed for
complex interfaces drops off as well.
cjl
Robert Bernecky
>>
>
>Considering the ever shrinking gap in the difference between something like
>an HP 48SX and a palm top PC clown (say, a HP 95LX), it's hard to say how
>much longer "calculators" as such are going to be around (high end calculators,
>that is.)
According to Ian Sharp, it was three years from the time that the first
pocket calculator hit the streets until the last slide rule company
ceased to produce slide rules.
Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
Dik T. Winter
> in the early 80's. This wasn't a bit slice. It was more like what is
> described above for the SC/MP, but the chip was 1-bit internally and
> externally. Does anyone remember details on this?
> --
> -Brian Smithson
> Motorola Inc., Computer Group, Commercial Systems Division
Does Motorola not know? MC14500B. 16 instructions (i.e. RISC ;-):
NOP0, LD, LDC, AND. ANDC, OR, ORC, XNOR, STO, STOC, IEN, OEN, JMP, RTN,
SKZ, NOPF. However, LD and STO are not exactly load and store.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
d...@cwi.nl
Dik T. Winter
> This is correct. However, there were no instructions on the 8008 to
> explicitly manipulate the stack (it was only implicitly manipulated by
> CALL and RET instructions, both of which could be conditional).
The 8008-II had PUSH and POP which would push and pop the HL register pair.
(Of course there are equivalent instructions on the 8080.)
Geoff McCaughan
> Say what? The 650x was about as unrelated to the 6800 as you could get, excep
> for their both being 8-bit machines!
Uh-huh.
"Although the 6502 microprocessor can certainly be used on its
own merits, one of its important characteristics is its similarity to
the widely used 6800 microprocessor. This similarity is not sufficient
to allow programs written for one of these processors at the machine
or assembly level to be run on the other, but it is sufficient so that
programmers can easily move from one CPU to the other."
Lance A. Leventhal, 6502 Assembly Language Programming. 1979
| Geoff - Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 (4 Lines)
| Email: ge...@satori.equinox.gen.nz
| "If I post something lucid, is that satorial eloquence?"
william E Davidsen
|> While we're into folklore, the Z80 had a whole batch of undocumented
|> instructions. Seems that hardware around the edge of the mask was
|> somehow unreliable, and so the instructions were simply "deleted"
|> from the documentation rather than having to "fail" the majority of
|> the chips.
In the interest of historical accuracy, I believe the Zilog chips had
these, the Mostek chips didn't. Anyone remember more clearly than that?
Shades of Intel and AMD.
--
- bill davidsen (davi...@crd.ge.com)
GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
william E Davidsen
|> If there is a list of these instructions 'floating around' then the can't
|> be undocumented can they. The list counting as documentation.
If you want to be pedantic I think the term is "unsupported," since
the vendor makes no promise that they will be in the next mask.
Sam Wilson
> I seem to recall that IBM was already shipping a 68000 based micro
> computer at the time the PC came out. It was called the 5???, and it
> was intended primarily for lab work or instrumentation...and it came
> with BASIC.
"Personal Computer World", March 1983 has an article by Chris Morgan (of
"Byte", it says here) about the IBM 9000. It begins, "The best-kept
secret of 1982 may have been that IBM makes a 68000 computer," a
remarkable and bizarre machine, from the description. The basic model
came with the processor box, a 12" mono monitor (768x480 driven by a
6845) with 10 touch sensitive functions keys on the lower bezel and a 57
key UDK pad. A 'real' keyboard (very familiar!) was an extra as were
disk drives (up to 4x 5.25" or 8" DSDD in any combination) and a
printer/plotter. The monitor mounted no top of the system box and the
printer/plotter mounted between them. The photo with the article
definitely look like it was made for and by engineers and scientists
rather than marketeers (it was being marketed as a lab and control
system).
The article doesn't say what speed the 68K runs (ran?) at but 128K each
of RAM and ROM were standard, RAM expandable to 5M in units of 256K.
The main board was a 7 layer PCB absolutely covered with chips and
contained 3xRS232, an IEEE488 and a bidirectional TTL-level parallel
port. The OS was custom made and ran BASIC, Pascal and FORTRAN 77.
Amazing...
Sam
J. Bayko
>in the early 80's. This wasn't a bit slice. It was more like what is
>described above for the SC/MP, but the chip was 1-bit internally and
>externally. Does anyone remember details on this?
This was in version 2.0.2 of the processor file, but got dropped (should it
still be included?):
Probably the limit was the 1 bit 14500B from Motorola. It had a 4 bit
instruction, and controlled a single signal line for control applications.
It had no address bus - that was an external unit that was added on. Or
another CPU could be used to feed control instructions to the 14500B
as part of an application.
It had 16 pins, less than a typical RAM chip, and ran at 1MHz.
John Bayko.
John Davis
> I seem to recall that IBM was already shipping a 68000 based micro
> computer at the time the PC came out. It was called the 5???, and it
> was intended primarily for lab work or instrumentation...and it came
> with BASIC.
I think you're getting confused with the IBM cs/9000 system,
which was their 68000 based lab computer. It wasn't released
'til 83-84 (I've got the review of it out of BYTE at work somewhere) if I
remember rightly.
The cs/9000 was quite an interesting machine really - nice
multitasking operating system, decent processor, good range of
languages (I've got FORTRAN, sci/eng BASIC ans Pascal for the
one at work) - price killed it though.
Cheers ... John
+-----------+-------------------------------+-------------------------+
|John Davis | che...@csc.canterbury.ac.nz | "out of small hacks |
| | j...@equinox.gen.nz | great things do come" |
+-----------+-------------------------------+-------------------------+
Eric Smith
...
> and two 16 bit index registers and a 16 bit stack pointer. It used these
those are 8 bit index registers and stack pointers.
> a fast zero-page mode that accessed memory addresses from address 0 to 255
> with an 8-bit address that speeded operations (it didn't have to fetch a
> second byte for the address).
In fact, instructions accessing zero-page on a 1 MHz 6502 were typically
faster than similar instructions using registers on a 4 MHz Z-80, so you
could consider the 6502 to have 256 extra registers.
Also, Rockwell and Mitsubishi make a lot of single chip microcontrollers
using the 6502 architecture, competing with the Intel etc. 8051 and Motorola
68HC05 and 68HC11 parts.
> Part VI: Advanced Micro Devices Am2903, a few bits at a time
Actually, the 2903 was never anywhere near as popular as the 2901, which
found its way into most minicomputers made in the late '70s, and lots of
other things such as Atari video games.
> Part II: Fairchild F8, Register windows
The F8 architecture was implemented by the 3850 series chips, and later by
the 3870 series single chip microcontrollers. The 3870 parts successfully
competed with the Intel 8048 until the late '80s.
> Part III: SC/MP, early advanced multiprocessing (April 1976)
The SC/MP (8060) was notable for being slow due to its implementation in PMOS.
A later version, the 8070, was an improved version implemented in NMOS.
The 8073 was an 8070 with tiny (tiny tiny) BASIC in 2.5K of ROM, and was
famous for a brief time.
> Part V: The Western Digital 3-chip CPU (June 1976)
You might mention that this chip set was the basis of the DEC LSI-11, the
Alpha-Micro computers, and the WD Pascal Microengine.
> Part II: Intel 432, Extraordinary complexity (1980)
(nb: Oh no, someone's got Eric started on the 432 again!!! <groan>)
> the 80286 was envisioned as a step between the 8086 and the 432.
I'm not sure anyone there actually believed this. I think they hoped to get
a lot of design wins from defense contractors due to the fault tolerance
features.
> The 432 actually included four chips. The GDP (processor) and IP (I/O
> controller) were introduced in 1980, and the BIU (Bus Interface Unit) and MCU
> (Memory Control Unit) were introduced in 1983.
Actually it was five chips, because the GDP was two chips, the 43201
containing the sequencer and control store, and the 43202 containing the
execution unit. Unfortunately the 43204 BIU and 43205 MCU never made it
into mass production, although I got to see a fault-tolerant system which
employed prototypes of these chips. We got to hot-socket boards, short out
bus lines, etc., and the system kept on going and going (just like some
battery advertisements).
> The GDP was exclusively object oriented - normal linear memory access
> wasn't allowed. It was designed with the Ada programming language in mind.
That was the claim, but I think that they had much of the architecture
designed before they decided that Ada would be a good language to use. If
they had really designed it as an Ada processor, they would have made the
architecture map much more closely to the language.
An early evaluation board, the 432/100, ran a SmallTalk-like language.
The 432 is probably the only processor that Intel has made for which they
don't supply an assembler. The Ada compiler did support in-line assembly
though.
> It had hardware support for data hiding, methods, and access protection.
> Unfortunately this meant that every memory access was checked, which slowed
> execution.
They did use object descriptor caching, so not every data access involved
reading the descriptor tables from main memory as you seem to imply.
It's not clear to me what feature of the 432 you are referring to as the
hardware support for methods, but the 432 architecture certainly could
handle methods as well as anything else.
Note that the current Ada standard does not include classes or inheritance
in a general sense, nor does it include late binding. The 432 is capable
of all of these.
One of the best features of the 432 architecture (IMHO) is that it allows
the use of Dijkstra's (sp?) parallel garbage collection algorithm.
The 432 architecture could support an ANSI-compliant C compiler, but it
probably wouldn't be able to run very much real world C code. This is
because most real world C code assumes that the underlying architecture
is a PDP-11 (or VAX). The most obvious examples of this are the assumptions
that pointers and ints are compatible and may be cast back and forth without
loss of information, and that arbitrary address arithmetic may be used.
The ANSI C standard specifically limits the operations that may be performed
on pointers, and the limits on their operations. For instance, in ANSI C,
if you set an int pointer to the beginning of an array of ints, the result
of pointer arithmetic are defined only as long as you keep the pointer within
the array, or pointing to the non-existent element immediately following the
end of the array. This restriction make it feasible for a hypothetical
432 C compiler to be ANSI-compliant (at least with respect to pointers).
> Because of the object oriented approach, the GDP had no local data
> registers.
Actually, the reason they didn't have programmer-visible registers has nothing
to do with being object oriented; it is because it is stack-oriented. The
documentation (or perhaps one of the article reprints) mentions that it does
have registers; they simply aren't programmer-visible.
> The BIU defined the bus. BIUs were designed for multiprocessor support,
> allowing up to 63 BIUs on a bus, and up to 8 independent buses, allowing
> memory interleaving, to speed access.
That's 63 modules on a bus, where a module could be a processor (interfaced
by BIU chips) or a memory array (interfaced by an MCU).
> The MCU did automatic pairity checking and single bit error correcting.
The MCU did full ECC and scrubbing. They even included the memory address in
the ECC computation, so they could detect (but not correct) addressing
failures.
> The total system was designed to be fault tolerant to a large degree, and
> each of these parts contributes to that reliability.
The fault tolerance was based on the combination of two redundancy mechanisms,
master-checker pairing of individual 432 components on a single module, and
primary-shadow pairing of modules. The former technique allowed for error
detection, but not correction. The latter technique added correction. If
the master and checker components on one module disagree, the module is
considered to have failed. By itself that would be unrecoverable, but the
alternate module of the pair (primary or shadow) operates in lock step, so
the complete (and correct) state of the module is still available. In the
case of a memory module, the MCU chips use master-checker pairing, but the
DRAMs don't. This doesn't reduce fault tolerance since ECC will detect
DRAM failures.
The BIU and MCU hardware would automatically shut down failed hardware, in
which case the system would continue to operate in a less fault-tolerant
matter. Software could then make policy decisions. For example, if one
processor module failed, the software could choose to continue to run the
alternate module of the primary-shadow pair (without fault tolerance),
assign a spare module to restore primary-shadow operation, or shut down that
processor.
> Despite these advanced features, the 432 didn't catch on. The main reason
> was that it was slow, about five to ten times slower than a 16-bit 68000.
From personal experience, I'd rate a 5 MHz 432 single processor (GDP) system
as having about 1/3 the performance of an 8 MHz 68000 at running high-level
language code. The ratio for hand-tuned assembly for both would probably
be different.
Although I am not familiar with the details of the implementation of the 432
GDP, I am told that the performance problems step from the use of 1979
silicon process and packaging technology. If they could have implemented the
GDP as a single chip, it probably would have had much better performance.
They were limited by die size, and by the 64 pin package. It is rumored that
a single microinstruction was wider than the 16 bit path from the 43201 to the
43202, necessitating a 2-clock microcycle.
> Part of this was the lack of local data registers, or a cache.
They did have a cache. It was probably too small. It was technically possible
to add an external cache, but as far as I know this was never done.
> Part of this was the fault-tolerant BIU, which defined an asynchronous bus
> that resulted in 25% to 40% of the access time being used by wait states.
This is misleading; an entire 432 system operated on a single synchronous
clock. The CPU bus was asynchronous to the memory bus only in the sense that
the number of clock cycles necessary for the BIU to acquire the memory bus was
non-deterministic if there was more than one processor. This is true in all
systems that don't have true dual- (or n- ) ported memory.
> In addition, the protections imposed on the objects required multiple
> memory accesses for permission checks every time data was accessed.
Again, this is somewhat of an exaggeration.
Cheers,
Eric
David E A Wilson
>Say what? The 650x was about as unrelated to the 6800 as you could get, except
>for their both being 8-bit machines!
Rubbish. The 6501 (the first in the 65xx series to be released) was a drop
in pin compatible replacement for the 6800 - only the instruction set changed.
The 6502 used the 6501 instruction set and had its own unique pin out.
The designers of the 65xx series were ex-6800 designers who decided to form
their own company.
--
David Wilson (042) 21 3802 voice, (042) 21 3262 fax
Dept Comp Sci, Uni of Wollongong da...@cs.uow.edu.au
-*_Spikey_Tribble_*-
> hy...@cis.uab.edu (Robert Hyatt) writes:
> : While we're into folklore, the Z80 had a whole batch of undocumented
> : instructions. Seems that hardware around the edge of the mask was
> : somehow unreliable, and so the instructions were simply "deleted"
> : from the documentation rather than having to "fail" the majority of
> : the chips.
> : Byte Magazine ran an article on these instructions way back when. I
> : had often found "bizarre" behavior in the Z80 while debugging assembler
> : code using the rather crude debuggers
Could somebody post me some info on this ( I have an old Z80 to play with ... )
--
# Bill Crawford aka *Cuddly_Cactus* | wj...@uk.ac.bton.unix #
# BSc (Hons) Computer Science Year One | wj...@uk.ac.bton.vms #
# Have you read your Book In Basic Life Education today ? You should !! #
# Any views I express are not necessarily those of Brighton Polytechnic #
###################### "surivorter erutangis a ma I" ######################
Ian Wild
> Actually the 8085 had a few extra undocumented instructions, too.
>These were related to indirect fetch through the 126 bit registers, and
>allowed programs compiled from languages like C to run a lot faster.
126 bit pointers? And here's me thinking the 8085 compilers didn't have a
large model...
Ian
Hunter Scales
>That reminds me -- someone (Motorola maybe?) introduced a 1-bit processor
>in the early 80's. This wasn't a bit slice. It was more like what is
>described above for the SC/MP, but the chip was 1-bit internally and
>externally. Does anyone remember details on this?
Sure, the MC6804. "Trix" the serial processor for kids.
--
Motorola Semiconductor Inc. Hunter Scales
Austin, Texas hun...@prometheus.sps.mot.com
#include <disclaimer.h>
Brian Wyld
>>
>> ke...@hplb.hpl.hp.com (Chris Dollin) writes:
>> ] For my money, the *novel* feature of the ARM is that every instruction is
>> ] conditional. But then, I'm hooked.
>>
>> I know it's a little different, but isn't the idea of a "skip" instruction,
>> that causes the next instruction to not be executed, both older than
>> ARM's conditional instructions ( and RISC in general ), and semantically
>> identical, if one considers the skip-next_inst sequence to actually be a
>> single instruction ?
>> --
>> Dennis O'Connor doco...@sedona.intel.com
I used to be fairly involved in the Beeb market, and once went to a
developers seminar thing run by Acorn. One of the (2 I think) designers of
the ARM was there speaking, and he said that two things amused him about the
ARM as a RISC machine.
One was that as each instruction was 32 bits long, and basically was a
microcode instruction (bits controlled CPU sections directly), this meant
that every single one of the 2^32 instructions was a "real" instruction. So
to call it a "Reduced Instruction Set CPU" seemed a bit silly!
And secondly, as a set of the bits were the conditional execution bits, and
one of the bits indicated "Never execute!", this meant that the chip had
2^31 NOP instructions.....
IMHO, the ARM is one of the great RISC chips around, and I'm really glad
that Apple etc are using it. An Archimedes (Acorns design with the ARM as
its processor) can gives you one of the cheapest UNIX boxes around. Needs a
better MMU to get a few more Meg in there, but lifes like that.
This was all a few years ago, so details in this posting may be wrong (such
as all the facts....)
Brian Wyld
--
<bri...@spider.co.uk : Spider Systems, Stanwell St, Edinburgh, Scotland >
<My opinions, ok? : 031 554 9424 : Short sigs save bandwidth >
Peter Desnoyers
>jo...@newave.mn.org (John A. Weeks III) writes:
>> I seem to recall that IBM was already shipping a 68000 based micro
>> computer at the time the PC came out. It was called the 5???, and it
>> was intended primarily for lab work or instrumentation...and it came
>> with BASIC.
>I think you're getting confused with the IBM cs/9000 system,
>which was their 68000 based lab computer.
>The cs/9000 was quite an interesting machine really - nice
>multitasking operating system, decent processor, good range of
>languages (I've got FORTRAN, sci/eng BASIC ans Pascal for the
>one at work) - price killed it though.
A friend worked at IBM Instruments a few years back (before they dumped
that division) and reports that one of the later modifications to the
9000 was to add an _8087_ as a numeric coprocessor. Interesting.
Peter Desnoyers
--
Tim McCaffrey
are derivable. If you look at the instruction set, the instructions
using the IX or IY registers are identical to instructions using the
HL register for an index, except that they are prefixed by an additional
instruction code byte. The prefix seems to work with other instructions
that use the HL register (such as DAD), but Zilog never documented this.
Tim McCaffrey
Per Lindqvist
: Say what? The 650x was about as unrelated to the 6800 as you could get, except
: for their both being 8-bit machines!
The 6502 appears to be influenced to the pdp-11. At least the instruction
references make references to the pdp-11 instruction set.
--
Per Lindqvist
Internet: p...@compuram.bbt.se Fidonet: Per Lindqvist @ 2:201/332
Per Lindqvist
the DEC PC instead of IBM with the IBM PC. The Intel 808X series of
microprocessors would have been forgotten together with the Z80, 8080,
and other stuff.
We might have had a family of computers, with the T11 in the entry
level (IBM PC), J11 in the more advanced level (IBM PC/AT), and the
VAX chip in the workstation level. MSDOS would never have been
invented. Instead we probably would have been running an advanced
version of RT-11.
Rick Kelly
It was also available with XENIX and a 10 meg hard drive.
--
Rick Kelly r...@rmkhome.UUCP unixland!rmkhome!rmk r...@frog.UUCP
Mr Tranfert File
> A friend worked at IBM Instruments a few years back (before they dumped
> that division) and reports that one of the later modifications to the
> 9000 was to add an _8087_ as a numeric coprocessor. Interesting.
IBM has also mated an 8087 with (two ?) 68000 in what was known as PC/XT/370
which should bring VM from the mainframe to your PC/XT desktop; (the 8087 to
do numerical computation and the two modified-68 to execute 370 instructions)
alas, this was not widely used or accepted at least in France, what a pity ...
--nh
Nhuan DODUC,
Framentec-Cognitech, Paris, France, do...@framentec.fr
Association Francaise des Utilisateurs d'Unix, France, do...@afuu.fr
ne...@walter.bellcore.com
Are you sure the 8008 followed the 4004. Going by numerical sequence,
it seems right. But I seem to recall that what stuck in my mind at the
time was the backwards sequencing. I recall the 8008 being first,
and the 4004 appearing after as a cheaper, embedded controller for things
like telephones and such.
Maybe the poster who has the manuals for both can check the
copyright notices.
Marc Pucci
ma...@bellcore.com
Donald Lindsay
>Are you sure the 8008 followed the 4004.
Yes, the 4004 was the very first microprocessor.
When it was announced in, ahh, 1971?, I sent away for information. I
got a two page document, the most horrendously reproduced, amateurish
document that I have ever received about a chip. None of my professors
wanted to know more, either.
--
Don D.C.Lindsay Carnegie Mellon Computer Science
Jim Frost
>Yes, the 4004 was the very first microprocessor.
>When it was announced in, ahh, 1971?, I sent away for information. I
>got a two page document, the most horrendously reproduced, amateurish
>document that I have ever received about a chip. None of my professors
>wanted to know more, either.
What do you want from a pocket-calculator chip? :-)
Byte magazine, within the last couple of issues, had a rather
extensive article about the 4004. It was interesting reading.
jim frost
ji...@centerline.com
Eric Smith
> Oh yeah - there was also a 65808. This was (or is, really) a 65816
> without the extra address lines. It could be plugged straight into a
> 6502 socket, and gave you most of the 65816 features - big registers (a
Actually, it was the 65802.
Many years before the 65816/65802, Synertek announced a 6516, which was
supposed to be a 16 bit 6502. Never shipped though, and I'm not sure they
actually even designed it. Not to be confused with the Harris 6516, which
is some kind of small bipolar memory, or the Commodore/MOS 6516, which came
much later and was just another 6502 derivative like the 6510.
Eric
Eric Smith
> The 8008-II had PUSH and POP which would push and pop the HL register pair.
> (Of course there are equivalent instructions on the 8080.)
Eric Smith
>>That reminds me -- someone (Motorola maybe?) introduced a 1-bit processor
>>in the early 80's. This wasn't a bit slice. It was more like what is
>>described above for the SC/MP, but the chip was 1-bit internally and
>>externally. Does anyone remember details on this?
>>>>> On Wed, 20 May 1992 15:38:19 GMT, hun...@oakhill.sps.mot.com (Hunter Scales) said:
> Sure, the MC6804. "Trix" the serial processor for kids.
Bzzzzt! He said 1 bit internally AND externally. The 6804 has an eight
bit architecture implemented in bit serial logic (like a DEC PDP-8/S).
Most of the 6804 instructions other than those specifically for bit
manipulation operate on 8-bit bytes.
The one bit processor (inside and out) was the Motorola 14500B Industrial
Control Unit (ICU), which was intended for applications such as replacement
of relay logic. In that respect it was like a DEC PDP-14.
Eric
Dik T. Winter
Intel are more knowledgable. The Datapoint manual mentions the processor.
It is of course also possible that it is custom made for Datapoint. But,
the major difference between the 8008 and the 8008-II is similar to the
major difference between the 4004 and the 4040: two register banks!
Antony Davies
>hun...@oakhill.sps.mot.com (Hunter Scales) writes:
>
>
>>>Part IV: Intel 8086, IBM's choice (1978)
>
>>> So why did IBM chose the 8086 when most of the alternatives were so much
>>>better? Apparently IBM's own engineers wanted to use the 68000, and it was
>
>> They didn't. They chose the 8088. The 8806 was already in use
<stuff deleted>
>
>According to Cringley's book, IBM chose the 808x because it was the only
>16 bit processor of the time that had a full complement of support chips
>(i.e. interrupt controller, I/O, etc.) available. He says that the
>equivalent chips from Motorola, etc. weren't developed or available yet.
<stuff deleted>
>Jay Kubicky
>jkub...@cco.caltech.edu
>
>(P.S. Cringley's book is called Accidental Empires and I highly recommend it!)
I don't read this newsgroup much and haven't followed much of this discussion,
so at the risk of getting flamed:
At the time the PC was first being developed memory was expensive. The 8086
had the advantage of compact object code because of many instructions that
use implied registors, etc. This would allow these first 128K
(is this right?) PC's to run larger programs than would be normally possible
with a more orthogonal instruction set. Maybe IBM just completely
underestimated how quickly memory would come down in price....Antony
J. Bayko
>it seems right. But I seem to recall that what stuck in my mind at the
>time was the backwards sequencing. I recall the 8008 being first,
>and the 4004 appearing after as a cheaper, embedded controller for things
>like telephones and such.
>
All the information I've found was that the 4004 was the first,
including a recent article in Byte on the subject of 'who was
first to make a microprocessor'.
Still, I'm human...
John Bayko.
Charles Lasner
I am confused here:
Since when is 8086 code compact? The 8086 has too many special-purpose
registers to be compact. Just another mediocre 8/16-bit architecture, not
a RISC machine or PDP-8.
I believe the first PC's were 16K capable, but were sold as 64K, not 128K.
I think the 128K number is the chip size for the AT and was first done by
soldering piggy-back the chips on the AT motherboard. But for total
capacity, isn't a PC first 64K then 256K not counting add-ons?
What does orthogonality have to do with program size when this machine is
neither RISCy or any other implied size efficiency? What is the mythical
improvement being compared to, the PDP-11? (Where many systems run quite
fine in a 64K address space total) or the Z80? (same yardstick there).
OK, so don't agree with me either, and flame both of us :-).
cjl (I am the god of hellfire and I bring you....)
Kevin Strietzel
>I believe the first PC's were 16K capable, but were sold as 64K, not 128K.
>I think the 128K number is the chip size for the AT and was first done by
>soldering piggy-back the chips on the AT motherboard. But for total
>capacity, isn't a PC first 64K then 256K not counting add-ons?
The original IBM PC was 16K base on the motherboard, expandable to 64K
on the motherboard. They'd sell you a disk controller if you had at
least 64K; DOS required 64K. The Pascal compiler required 128K. RAM
cards were originally 32K and 64K.
I think the PC/XT could handle 4 rows of 64Kbit DRAMs on the
motherboard, giving 256K there.
The PC/AT originally came in 128K and 512K RAM versions, with an
optional 128K card to fill up the base 640K address space.
Kevin
--
Kevin Strietzel
k...@naucse.cse.nau.edu
Greg Lehey
>In article <ERIC.92Ma...@iceland.telebit.com> er...@telebit.com (Eric Smith) writes:
> > >>>>> On 19 May 92 01:46:22 GMT, d...@cwi.nl (Dik T. Winter) said:
> > > The 8008-II had PUSH and POP which would push and pop the HL register pair.
> > > (Of course there are equivalent instructions on the 8080.)
> > Who made the 8008-II? I never heard of it!
>I have no idea who made it. Presumably Intel, but perhaps the people from
>Intel are more knowledgable. The Datapoint manual mentions the processor.
>It is of course also possible that it is custom made for Datapoint. But,
>the major difference between the 8008 and the 8008-II is similar to the
>major difference between the 4004 and the 4040: two register banks!
My understanding is that the 8008-II was a faster version of the 8008.
I forget the clock speed, and the crystal on the board in front of me
isnot going to tell me either ("XS 6102\n2KVG75" - maybe 2 MHz or 2.75
MHz?), but the register-register instruction speeds were 20 us on the
8008 and 12.5 us on the 8008-II. I have been looking (without success)
for my MSC-8 manual with the instruction set details, but can't find
it. I believe, however, that Dik is correct with the PUSH/POP
instructions. The stack was only 14 bits, however, so the upper 2 bits
of H got lost.
2 register banks? I'd like to see documentation of that. The board I
have here is in VME 6U format (also called double Eurocard) and has
the processor, bus logic and a second register set in TTL logic. The
manufacturer (GPM of Vienna, 1974) went to a lot of trouble to
advertise the advantages of the second register set (accessible by I/O
instructions).
-------------------------------------------------------------------------------
Greg Lehey | Public access UNIX available - try BSDI
LEMIS | out on our machine! Mail and news
W-6324 Schellnhausen 2 | connections available
Germany | Fax: +49-6637-1489
Tel: +49-6637-1488 | Mail: grog%le...@Germany.Eu.net
Claimer: The opinions expressed *are* the opinions of LEMIS
*** NOTE ***: My mail headers are suffering from a virus. The correct
reply address is grog%le...@Germany.EU.net