From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: [TUHS] Re: Clever code
Date: Tue, 13 Dec 2022 12:58:11 -0500 (EST) [thread overview]
Message-ID: <20221213175811.C1E8118C098@mercury.lcs.mit.edu> (raw)
> From: Stuff Received
> I had always thought of a delay line as a precursor to a register (or
> stack) for storing intermediate results. Is this not an accurate way of
> thinking about it?
No, not at all.
First: delay lines were a memory _technology_ (one that was inherently
serial, not random-access). They preceded all others.
Second: registers used to have two aspects - one now gone (and maybe the
second too). The first was that the _technology_ used to implement them
(latches built out of tubes, then transistors) was faster than main memory -
a distinction now mostly gone, especially since caches blur the speed
distinction between today's main memory and registers. The second was that
registers, being smaller in numbers, could be named with a few bits, allowing
them to be named with a small share of the bits in an instruction. (This one
still remains, although instructions are now so long it's probably less
important.)
Some delay-line machines had two different delay line sizes (since size is
equivalent to average access time) - what one might consider 'registers' were
kept in the small ones, for fast access at all times, whereas main memory
used the longer ones.
Noel
next reply other threads:[~2022-12-13 17:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 17:58 Noel Chiappa [this message]
2022-12-13 18:51 ` G. Branden Robinson
2022-12-13 20:14 ` segaloco via TUHS
2022-12-13 20:58 ` Warren Toomey via TUHS
2022-12-14 2:28 ` Luther Johnson
-- strict thread matches above, loose matches on Subject: below --
2022-12-13 18:02 Noel Chiappa
2022-12-13 3:30 Rudi Blom
2022-12-13 3:41 ` Warner Losh
2022-12-13 3:53 ` Dave Horsfall
2022-12-13 4:03 ` George Michaelson
2022-12-13 8:05 ` Ralph Corderoy
2022-12-13 9:45 ` Dagobert Michelsen
2022-12-13 7:47 ` Ralph Corderoy
2022-12-13 19:56 ` Dave Horsfall
2022-12-13 11:46 ` John P. Linderman
2022-12-13 14:07 ` Douglas McIlroy
2022-12-13 14:31 ` arnold
2022-12-13 14:48 ` Ralph Corderoy
2022-12-13 15:10 ` Douglas McIlroy
2022-12-13 15:34 ` Stuff Received
2022-12-13 15:56 ` Ralph Corderoy
2022-12-13 23:02 ` Harald Arnesen
2022-12-14 7:31 ` arnold
2022-12-15 18:06 ` Marc Donner
2022-12-15 18:08 ` Marc Donner
2022-12-13 15:52 ` Bakul Shah
2022-12-13 16:14 ` Ralph Corderoy
2022-12-13 16:30 ` Bakul Shah
2022-12-11 20:03 [TUHS] Re: Stdin Redirect in Cu History/Alternatives? Larry McVoy
2022-12-12 2:15 ` [TUHS] Clever code (was " Bakul Shah
2022-12-12 9:48 ` [TUHS] Re: Clever code Michael Kjörling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221213175811.C1E8118C098@mercury.lcs.mit.edu \
--to=jnc@mercury.lcs.mit.edu \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).