[Simh] C64 and C128

[Timothe Litt]

On 30-Jun-15 21:48, Rich Alderson wrote:
[Snip]

A great summary, to which I'll add a couple of additional infobits:

The Intel 4004 (and 4040) use 4 bit data words, (mostly) 8-bit
instruction words & 12-bit addresses.  (Some instructions use two 8-bit
instruction words.)  The external bus is 4 bits - different cycle types
for ROM, RAM and I/O.  Its documentation calls 8 bits both a word and a
byte, and its 4-bit word a 'character'.  Welcome to the wild world of
early computing; all terms are context-sensitive!  Adding 8-bit binary
numbers is double-precision, requiring several instructions.  The CPU
supports BCD as well.  The device was designed for a calculator, so it's
not quite as crazy as at seems.  At ~90KIPS, it isn't exactly speedy -
though I had a project that managed to do some speech synthesis with it
(!).  Some of its architecture can be seen in the x86.

CPU architectures usually have some extensions (warts) for various
reasons.  For example, the Z80 is an 8-bit machine, but has some
instructions that operate on 16 bits.  It, like the 4004/40, x86 and
VAX, has variable length instructions.  Many support multiple precision
data types (double is common); these consume/generate multiple 'words'
of memory and/or registers. 

Floating point throws another wrench into simplicity: floating point
numbers can have a word size that differs from integers. 

The PDP-10's idea of 'character' or byte is flexible.  36-bits comes
from the 6-bit BCD character of some industry predecessors.  But the
PDP-10 supports variable-size bytes - from 1 to 36 bits at arbitrary
alignment in words.  Most text, by convention, is stored in 7-bit
bytes.  But 6, 8, 9 and 12-bit characters are commonly used in
applications and the OS.  The -10 survived the transitions from 6 to 7
to 8-bit characters without architectural change.  And if it was active
today, it would be equally happy with 16 and 32-bit Unicode characters
as 'bytes'.  Hardware supports single, double & quad integers (modulo
how the sign bit is handled).

The implementation details can become visible, both functionally and for
performance.  The KL10 memory system groups 4 words into each cache
line, and it clever enough to request them in the right order (requested
word first).  The VAX fetches instructions in aligned words (or
multiples).  This is visible architecturally in the required sequence
for turning memory management on, and can have a significant impact on
performance following a branch.  Many modern CPUs have different data
path widths internally from the external bus (and register size).  And
the 'bits per address' usually diverges as memory gets cheaper and
programs larger.  Memory address 'banking' and 'mapping' provide more
physical memory than an instruction can address.

So life gets complicated - especially so as caches and other modern
micro-architectural innovations provide one view to the programmer in
user mode, another to the OS programmer and yet another to the
hardware.  Not to mention the layers of compatibility evidenced in
machines like the x86.

The only good news is that just about everyone has adopted IEEE floating
point format.  Well, one of them.

As a general rule, the 'word size' that most people use is the width in
bits of an integer register.  And addressing targets either 8-bit bytes
or words that are the width of a native integer register.  The external
bus's data path may be either wider or narrower than the apparent
address target.  Narrower to save pins and simplify the hardware; wider
to increase performance.  The external bus's address also can be either
wider or narrower than an instruction can generate.  Wider as the
architecture ages and more memory is needed.  Narrower early on to
simplify implementation and match the 'affordable' amount of memory.

Sorry if this adds any confusion; the one invariant in computer
architecture seems to be that if you wait long enough, complexity always
increases.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150701/a414c372/attachment-0001.bin>