British Science Museum needs a lesson in history

From: Hans Franke <Hans.Franke_at_mch20.sbs.de>
Date: Mon Jun 28 15:47:33 1999

(Shure, not exactly new, but I'v still some 300 unread mails...)

> > > _At_ the musuem they advertise the machine as the first electronic
> > > computer with random-access memory. I have far less of a problem with
> > > that statement :-)
> > Except that Zuse's Z3 also had random-access memory, just not for the
> > program. IIRC the Z3 had/has 64 data registers.
> It was implied (if not explicitly stated) that the _program_ was in
> random-access memory as well.
> > In fact (as Sellam might remember since this was presented at a speech at
> > last year's VCF) there is a way to give the Z3 random read-only access to
> > its program. The Z3 reads its opcodes from a strip of 35mm movie film; the
> > film can of course be looped together; most importantly the Z3 will _stop_
> > if it encounters an arithmetic exception. So the "only" work left is to
> > partition the program into sections and explode each arithmetic operation
> > into a conditional operation based on the current value of the section
> > counter. It's possible to do the exploding without causing any more
> > exceptions. I think the section counter needs to go in one of the registers.

> I would claim that was 'faking' a random access of a sequential access
> store (in much the same way that you can address a particular block on a
> TU58 cartridge, but tape is certainly a seqeuntial device).


So when does fake start - in fact, almost any system views program
storage as sequential (unless a jump is encountered) - and when
using the look-trick on the Z3 I cant see a big difference compared
to lets say a modern CPU/RAM system, where you may need a real lot
of set up cycles if you want to access a different cell (shure, you
can argue, that the 'streaming' mode is just an enhancement to the
basic random access, but the architectures cange). When it comes
to a short jump (one or just a few memory words away), adressing
and skiping the locations inbetween might be the way of choice.


On the other hand: When is a device random ? What viewpoint is
to be taken - the CPUs view of instructions, or the memory view
of memory words (aka bytes in an byte wide memory) ? Depending
on that, the term 'random' becomes 'unscharf' (unclear/fuzzy/vague -
I can't find an exact translation).

Third: If random is 'unscharf', maybe sequential isn't ? So,
when is an (memory) access sequential - do I have to process
all the data inbetween, or is it enough just to address them ?
Is advancing the media (or a pointer) already a sequential
access ?

Third: Again: when becomes a device 'random accesible' ? I a disk
drive random ? First impression: yes - but if you come closer you'll
find just a bunch of sequential access: First, the heads have to move:
sequential, not random (and, depending of the technology, the tracks
have to be read to assure the possition) - next, the track has to be
read until the needed block is found (sequential - not random), and
then the block had to be read - no random actions at all.
And last: the media is rotating, so if we have assumed that
advancing the media is already sequential access, a disk is
performing a permanent sequential access.


Now, if we admit that different (CPU/Mem interface-)designs
are using different, more or less obscure ways to address
the program storage, Raul's Loop-Trick doesn't look _very_
strange.


Postscriptum: I don't try to put the Z1/Z3 where they don't belong,
and I know that there's a difference between them and a machine
_with_ conditional instructions, but the Loop-Trick pushes the
line again further - in fact, this is like the question where
(in biological, not biblical sense) lifeless nature and life
is diverted. Again, the gap is way smaler then we may assume.

Gruss
H.

--
Stimm gegen SPAM:     http://www.politik-digital.de/spam/de/
Vote against SPAM:    http://www.politik-digital.de/spam/en/
Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
Ich denke, also bin ich, also gut
HRK
Received on Mon Jun 28 1999 - 15:47:33 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:17 BST