[net.arch] Very Long Addresses

andy@Shasta.UUCP (09/09/86)

Most of us already use systems whose addresses are 100's of bits
long.*  Freedom in naming, especially if it results in sparse use
of the name space, can be quite important.

BTW - The delay of comparators that use precharging (see the Manchester
carry-chain adder in Mead-Conway) seems to be independent of the size
of the addresses being compared, at least through several tens of bits.

-andy
*How long is your name?  What about your address?
-- 
UUCP:  ...!decwrl!glacier!shasta!andy forwards to
ARPA:  andy@sushi.stanford.edu
(415) 329-1718/723-3088 home/cubicle

mangler@cit-vax.Caltech.Edu (System Mangler) (09/22/86)

In article <831@Shasta.STANFORD.EDU>, andy@Shasta.UUCP writes:
> BTW - The delay of comparators that use precharging (see the Manchester
> carry-chain adder in Mead-Conway) seems to be independent of the size
> of the addresses being compared, at least through several tens of bits.

This was true in the technology that the Manchester carry chain was
invented for - because the relay contact resistance and inductance
were so small relative to that of the coils being driven.  But MOS
switches have large resistance and capacitance, leading to quadratic
delay.	The trick is to insert a buffer before the quadratic term
gets too large - every 3 bits for nMOS, every 2 for cMOS, making the
delay linear in the number of bits.

Using an adder to do address *comparison* in RAMs (as Andy seems to
be saying) is overkill; there are much more efficient ways to test
for equality to a constant.  More likely, that adder will be doing
address *translation*, but here too the adder delay is usually a red
herring, since it can be overlapped with cache access time, if you
have one (yes, I know that Cray's don't).  You can do the same trick
with TLB lookup, and I hear that that's what's done in the 68030.
Adders and small RAMs have comparable delay when implemented side-
by-side on a chip.

Don Speck	speck@vlsi.caltech.edu	seismo!cit-vax!speck