15 Mar
2005
15 Mar
'05
12:58 p.m.
woodelf wrote:
The 1620 I had had the memory stack pretty much in the area under the
area of the machine with the console. Only box box. Perhaps a larger system
with expansion memory or chassis had external, but the one we had in Lafayette,
La had the memory in the box. only thing external was the reader punch and
printer.
An undergraduate that fell in love with the one we got up and running wrote
a simulator that ran in Multics Basic, which was compiled, in an timeshare
environment
that ran 5 to 10 times faster than the original machine.
Ran ASM and Fortran, since the school had decided to have one of the
few multics machines with a card reader. As I remember, it was a documation
that was hooked thru the DN355, but someone else might remember better
Jim
That depends on
whether you trust the datapath between the memory and
the CPU. In the 1620, the memory is a separate cabinet, connected bycables
to the CPU cabinet. A wise designer would run parity on that
interconnect. That's still true: high end "system on a
chip" designs have ECC memory
AND parity (at least) on the buses -- even if they only run inside
the chip.
I don't actually know if there was parity
there. Probably yes, since
As for sign bit per digit, in the 1620 the "sign" bit serves two
purposes -- on the least significant digit it's the sign of the
number, on the most significant digit it's the "this is the last
digit" marker.Not that the 1620 is all that efficient -- at 12 digits per
instruction, code density was pretty low.
I don't think that the code density was that bad since it was a two
address instruction.
If you consider at the time most computers had the power of a 4 function
calculator
with tiny amount of data memory the base machine with 20,000 digit memory
was a lot of memory. What was real inefficient was converting from
internal codes
to external coding like printers, paper tape, punch cards all with
different formats.
(I don't have one, I just read the book about it)