Path: utzoo!attcan!uunet!lll-winken!decwrl!orc!oli-stl!asylum!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Summary: I want a simple machine.
Message-ID: <2054@osc.COM>
Date: 21 Feb 90 00:14:20 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <10795@snow-white.udel.EDU> <2027@osc.COM> <162@gollum.twg.com>
Reply-To: jgk@osc.osc.COM (Joe Keane)
Organization: Object Sciences Corp., Menlo Park, CA
Lines: 36

In article <2027@osc.COM> i write:
>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.

In article <162@gollum.twg.com> warner@twg.com (Warner Losh) writes:
>I really don't see how this will solve your problems.  You still need a
>constant to offset into the constant pool.  It would also make your compilers
>much harder to produce since they would also have to manage a constant pool.

I should say that when i wrote the original post i was thinking specifically
about the ROMP architecture.  After IBM's recent announcements, it looks like
this will become one of the major architectures of the next couple years.
There's no reason why it shouldn't, even though their first implementation was
lame.  So if you want to know how a `constant pool' works, what a typical
linkage convention is, and how to compile for it, look at the RT.  The
one-line summary is that it's not hard to do, although there's a little bit of
hair for the RT because the BALAX instruction only has a 24-bit range.

>This isn't so bad until you try to optimize for space (why would I want to
>have five copies of the number four anyway) between modules.  I don't see that
>it would buy you anything, at the cost of additional complexity.

I agree this is hard, but it's an interesting optimization and can only
improve your performance.  Of course it's completely impossible if your
constants are embedded in the instruction stream.

>At best the solution to this problem is to always use int constants and not
>try to deal with saving a few bytes here or there.

I'm mostly trying to be a good RISC person and make the CPU simpler and
faster, and if we can save a few bytes along the way, that's good too.