Space registers and how to use them
There's a certain amount of confusion about how space registers are specified, so I'm going to explain it for posterity.
There are two types of instruction which reference memory; those with 2-bit 's' fields and those with 3-bit 's' fields.
Instructions with a 3-bit s field are straightforward. The value of the s field directly specifies which of the 8 space registers to use.
Instructions with a 2-bit s field have two cases. If s is 1-3, we use the corresponding space register (sr1-sr3). If the value in the s field is 0, we do not use space register 0. Instead, we use one of sr4-7 as determined by the top two bits of the *base register*.
In Linux, sr4-7 are always set to the same value. When in kernel space, they are 0. In user space, they have the value for the task we're currently executing.
What we were trying to do in pacache.S was use an instruction (flush instruction cache) as if it were a 2-bit-s instruction when it's actually a 3-bit-s instruction. This led to the processor using sr0 instead of one of sr4-7. The assembler now errors on this case, causing us to find a bug.
Just to make things harder, there is a 2-bit-s version of flush instruction cache, but it's only available on pa2.0 processors, so we don't want to use it. Instead we use sr4 (since sr4-7 all have the same value in Linux).
_______________________________________________
parisc-linux mailing list [email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Joel Soete
Btw can you help me to undurstand the concept of the 4 quadrants as it was spoken in:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2002-December/018602.html>
A "quadrant" is 1GB of address space. Think of each 1GB of address space in 4GB as a "quadrant".
Quoted 1 line
Used in hpux? (documented somewhere?)
Probably.
Quoted 1 line
Is it related to the usage of sr4-7 as 4 different kernel spaces?
Yes. "2 bit s" field in fdc/fic map each "quadrant" to sr4-7. ie 0-1GB uses sr4, 1-2GB uses sr5, etc.
John was just saying it doesn't matter since parisc-linux uses the same value in all four (sr4-7) space registers.
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 2 lines
John was just saying it doesn't matter since parisc-linux uses the same value in all four (sr4-7) space registers.
It's possible for user code to mess with sr4. It's not a privileged register.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 5 lines · John David Anglin
Quoted 2 lines
John was just saying it doesn't matter since parisc-linux uses the same value in all four (sr4-7) space registers.
It's possible for user code to mess with sr4. It's not a privileged register.
Certainly. But in the kernel those are KERNEL_SPACE (zero).
We save/restore the user space values for sr4-7.
We clear sr4-sr7 in linux_gateway_entry (arch/parisc/kernel/syscall.S) for syscalls. We do the same for interrupts in virt_map macro in entry.S.
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 4 lines
Instructions with a 2-bit s field have two cases. If s is 1-3, we use the corresponding space register (sr1-sr3). If the value in the s field is 0, we do not use space register 0. Instead, we use one of sr4-7 as determined by the top two bits of the *base register*.
Actually, there is another twist to the above in wide mode (PSW[W]==1). Instructions with long displacements always use the implicit addressing scheme. The space register bits are used instead to provide a 16-bit displacement. At the moment, we need support for some additional relocations to handle long displacements for all instruction formats (e.g., we lack support for long displacements in floating point loads and stores).
Short and indexed instructions behave the same as in 32-bit mode for s_field==0 (i.e., space register is determined by the top two bits of the base register). However, it's an undefined operation to have a nonzero s_field in unprivileged code.
Regarding GAS, I changed the rules regarding the specification of space registers in instructions to avoid confusion. In instructions that have a 3-bit space register field, it is now a requirement to explicitly specify the space register field. The treatment of sr0 in these instructions is completely different from the treatment in instructions with 2-bit space register fields (i.e., the base register selection process isn't used). There were a couple of entries in the opcode table that allowed omitting the space register field in instructions with 3-bit space register fields. These have been removed. Indeed, without doing this, it wouldn't have been possible to support both the 2 and 3-bit formats for "fic".
As a coding note, it's best not to specify sr0 in instructions which use the base register selection mechanism.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 2 lines · John David Anglin
As a coding note, it's best not to specify sr0 in instructions which use the base register selection mechanism.
I'd be happiest if it were illegal actually. I wonder how much code that'd break though ...
Can we make it emit a warning? Something like
"sr0 not allowed for this instruction, using short pointer addressing instead"
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux