[parisc-linux] depi?

[John David Anglin]

> 
> Philipp Rumpf wrote:
> > 
> > > I must be missing something...the above should branch
> > > to: sr7.0xc008dbc0, not to "0xc008dbc0".  I.e., you specified SR7
> > > in the BE instruction, so it gets used.

I agree.  The contents of SR7 is loaded into the instruction space id
queue.

The example was a stub.  Stubs are generated by the compiler/linker
when a relative branch is too far.  The BE instruction was used (as
opposed to a BL instruction) to allow the branch to go anywhere within
the assumed 4GB address space model.  The linker used SR7 because
it determined that the branch was to an address in the 4th quadrant
of the 4GB address space.

> > 
> > No, we didn't.  We set the space register selection field to '00' which
> > according to the documentation means you select SR7 but in reality means
> > you don't want to have anything to do with space registers.  Just think
> > of it as flat address 0xc008dbc0 and of SR[123]:0xc008dbc0 as "real"
> > segmented addresses.

This is only for data accesses.  Instructions use the full space register
specifications.  When an interspace branch is taken with sr7, for example,
the contents of sr7 becomes the new contents of the space id queue. 

> When address translation is enabled, a space register is *always* used.
> You cannot turn that off.  Specifying '00' in the space register
> select bits really does mean that you use space register 7 to calculate
> the 64 bit virtual address.  (Humor me, and pretend that all
> implementations of space registers are 32 bits, even though they aren't.)
> 
> If you "don't want to have anything to do with space registers", you
> can put the same value (such as zero) in all of the space registers.
> 
> 
> > > So, SR7 indeed needs to be set correctly...but since I haven't
> > > looked at the surrounding code...
> > 
> > SR0, SR4, SR5, SR6, SR7 shouldn't ever need to be set to different values
> > for flat 4 gig code.  SR1, SR2, SR3 you use only for "real" segmented code.
> > 
> > (This is based on what the C compiler does, and what changed with PA2.0)
> > 
> >         Philipp Rumpf
> 
> I don't understand.  Are you saying that there is a single 4gByte virtual
> address range that is shared by the kernel and all user processes?  Or
> do you plan to provide a separate 4gByte virtual address range to each
> process/task/thread/whatever?

I think what is being suggested is to run with the space registers all
zero and swap the TLB contents on context switches in order to changing
the mapping from virtual to physical.  However, I doubt this is efficient.

On the otherhand, the space registers could be swapped on context switches,
and the kernel and each process could have their own 4GB virtual space.  The
mapping of program virtual addresses to hardware virtual addresses would
still be flat. I can't see any reason to segment the address space since
the hardware virtual address space is large enough to accomodate more
processes than would ever be needed.  I assume here that we aren't concerned
with running on level 0 machines without space registers.  In this scenario,
cache usage would reflect the scheduling priorities of the OS.

I stress that, because the PA architecture has space registers, a program's
virtual address space (0 - 4GB) doesn't have to be the same as its hardware
virtual address space.

My original point was that I couldn't see where the space registers were
initialized prior to the transition to virtual operation.  They may in
fact be initialized to zero by the boot loader prior to transfer to the
kernel (cf., head.S).

Does the above suggestion regarding the usage of space registers make any
sense?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)