🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22430

Re: 64-bit addresses

#22430
From: Joe Keane
Date: Mon, 12 Feb 1990 19:10
43 lines
3023 bytes
In article <10795@snow-white.udel.EDU> nelson@udel.edu (Mark Nelson) writes:
>I would personally prefer a 64 bit word size with either straight 48 bit
>addresses or else 64 bit addresses with the top 16 bits used as a segment
>number.

I view with great suspicion any comment which says that smaller or segmented
addresses are desirable.  Let's see the reasoning...

>Why?  Because it is very hard to fit 64 bits of address into a 64 bit
>instruction and still have room for e.g. the opcode.

This assumes that you want to put all your constant data in the instruction
stream.  Back on the PDP-11 it was a neat idea to use `PC auto-increment' to
get constants, because registers were so scarce.  Then on the VAX this idea
got bloated so the instruction stream contained all sizes of `immediate' data
plus three different sizes of offsets.  Did you know there's a format where a
floating point number takes up six bits?  (I'm using the PDP-11 and VAX only
as representative examples.)

If you think about it, there's no good reason to put instructions and constant
data together.  In fact, there are good reasons not to; on a pipelined machine
(any machine these days) you don't have to spend silicon trying to figure out
whether a particular word (or byte on the VAX) is going to be an instruction
or data.  If you've got good (small and fast) load instructions, use them.
Take another register and have it point to the `constant pool'.  I don't think
you'll miss this one register.

>I'm a real proponent of fixed size instructions, and I don't think two
>instructions should be required just to load an address.

I heartily agree with this.

>Actually, I'll go further and say I'm not sure that a 64 bit machine really
>needs to fully support 64 bit integers.  There should definitely be 64 bit
>add/subtract, boolean, shifts, and anything else which scales linearly with
>word size, but I think the largest integer multiply supported need only be
>48x48 -> 96, with the corresponding divide 96/48 -> 48,48.

You can do that, but what you get is not completely a 64-bit machine.  It's
somewhere between 48-bit and 64-bit, which in my opinion isn't desirable.  For
a while i've been tempted to design a machine with something like 67-bit
instructions, 53-bit integers, and 47-bit pointers.  I'd be neat, but somehow
i don't think it'd catch on.
Technical Details
Message-ID: <2027@osc.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!clyde.concordia.ca!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!elroy.jpl.nasa.gov!ames!pacbell!osc!jgk
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <10795@snow-white.udel.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!clyde.concordia.ca!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!elroy.jpl.nasa.gov!ames!pacbell!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Summary: You don't want to put large constants in the instruction stream.
Message-ID: <2027@osc.COM>
Date: 12 Feb 90 19:10:11 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <10795@snow-white.udel.EDU>
Reply-To: jgk@osc.osc.COM (Joe Keane)
Organization: Object Sciences Corp., Menlo Park, CA
Lines: 43