[parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Thibaut VARENE]

Hi pa,

I've been writing a few optimized asm bits for ffmpeg, using MAX2
insns and taking advantage of the fact that pa2.0 implements 64bit
wide registers.

NOTE: i'm not using a 64bit address space at all. I'm just taking
advantage of the fact that GRs can hold 64bit, as per architecture
design. MAX2 insns need the full 64bit width, for instance.

Yet, Randolph pointed out that it's likely that upon context switch,
the upper 32bit of the registers i'm using would be thrown away.

Two options from there:
1) we claim what I'm trying to do should not be done on parisc-linux
=3D> using ldd/std, MAX2 and other insns that rely on 64bit regs should
be prohibited by binutils for non-wide code (currently gcc/binutils
happily build my code with -mpa-risc-2-0, which generates level 2.0
non wide code)

2) we claim what I'm trying to do should be possible on parisc-linux
=3D> we need to fix context switching in 32bit kernels.

Comments?

T-Bone

--=20
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: [RFC] using 64bit wide registers with 32bit kernel

[Thibaut VARENE]

On 5/13/06, Thibaut VARENE <T-Bone@parisc-linux.org> wrote:
> Hi pa,
>
> I've been writing a few optimized asm bits for ffmpeg, using MAX2
> insns and taking advantage of the fact that pa2.0 implements 64bit
> wide registers.
>
> NOTE: i'm not using a 64bit address space at all. I'm just taking
> advantage of the fact that GRs can hold 64bit, as per architecture
> design. MAX2 insns need the full 64bit width, for instance.
>
> Yet, Randolph pointed out that it's likely that upon context switch,
> the upper 32bit of the registers i'm using would be thrown away.
>
> Two options from there:
> 1) we claim what I'm trying to do should not be done on parisc-linux
> =3D> using ldd/std, MAX2 and other insns that rely on 64bit regs should
> be prohibited by binutils for non-wide code (currently gcc/binutils
> happily build my code with -mpa-risc-2-0, which generates level 2.0
> non wide code)

I take that back as I can see a reason to use them in userspace when
running a 64bit kernel, even though the generated code wouldn't work
with a 32bit kernel.
Yet, not being to use them (in particular MAX2) with a 32bit kernel on
pa2.0 cpus is quite sad, as we encourage our users to run 32bit
kernels on pa2.0 machines that can...

> 2) we claim what I'm trying to do should be possible on parisc-linux
> =3D> we need to fix context switching in 32bit kernels.
>
> Comments?

T-Bone
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[James Bottomley]

On Sat, 2006-05-13 at 17:41 +0200, Thibaut VARENE wrote:
> 1) we claim what I'm trying to do should not be done on parisc-linux
> => using ldd/std, MAX2 and other insns that rely on 64bit regs should
> be prohibited by binutils for non-wide code (currently gcc/binutils
> happily build my code with -mpa-risc-2-0, which generates level 2.0
> non wide code)

I really don't think doubling the size of our register file on all tasks
and doubling the size of the saved registers on stack for interruptions
is really a sensible thing to do just so some multi-media extension can
be made to work.

> 2) we claim what I'm trying to do should be possible on parisc-linux
> => we need to fix context switching in 32bit kernels.
> 
> Comments?

There is a third possibility, and that's to execute the instruction in
the kernel where there wouldn't be a danger of context switches, where
the return values could be packaged properly and where it could be
emulated if necessary.  It would be nice to use a vDSO for this, but I
suspect Carlos' lightweight semaphore infrastructure can be pressed into
service for this.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Thibaut VARENE]

On 5/13/06, James Bottomley <James.Bottomley@steeleye.com> wrote:
> On Sat, 2006-05-13 at 17:41 +0200, Thibaut VARENE wrote:
> > 1) we claim what I'm trying to do should not be done on parisc-linux
> > =3D> using ldd/std, MAX2 and other insns that rely on 64bit regs should
> > be prohibited by binutils for non-wide code (currently gcc/binutils
> > happily build my code with -mpa-risc-2-0, which generates level 2.0
> > non wide code)
>
> I really don't think doubling the size of our register file on all tasks
> and doubling the size of the saved registers on stack for interruptions
> is really a sensible thing to do just so some multi-media extension can
> be made to work.

that's not my point. It's not only about "some multimedia extension".
It's about being able to do 64bit logic on 64bit-wide registers with
32bit kernels...

> > 2) we claim what I'm trying to do should be possible on parisc-linux
> > =3D> we need to fix context switching in 32bit kernels.
> >
> > Comments?
>
> There is a third possibility, and that's to execute the instruction in
> the kernel where there wouldn't be a danger of context switches, where
> the return values could be packaged properly and where it could be
> emulated if necessary.  It would be nice to use a vDSO for this, but I
> suspect Carlos' lightweight semaphore infrastructure can be pressed into
> service for this.

If by "executing the instruction" you mean one specific insn, that
sounds like a nightmare to me. I've got some routines asm-optimized
that are about 15 lines of asm. Each of these routines handle packs of
16 pixels. On a 640x480@25fps movie for instance, these routines would
typically be called at least 480000 times per second, and they're
expected to be executed as fast as possible (which is the whole point
of doing them in hand crafted asm)...

I don't know about vDSO, but the thought of having to call something
in the kernel in that perspective doesn't feel about right to me. I've
been reading other archs optimizations, and all do straight forward
asm computation.

What I'm looking for is a way to use the architecture to the best of
its design, and said design comprises 64bit wide GPRs...

If that's not possible in parisc-linux, fine, I'd just like to have
this clarified so I don't waste my time on pointless code :-)

HTH

T-Bone

--=20
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Jes Sorensen]

Thibaut VARENE wrote:
> On 15 May 2006 05:10:15 -0400, Jes Sorensen <jes@sgi.com> wrote:
>> What about setting an ELF flag or somesuch, set a task flag based on
>> this and then only do the extended register file backup for these
>> apps?
> 
> If that's possible *and* acceptable, it might be very helpful indeed.

I don't know anything about the PARISC ELF specification, but I think
it ought to be feasible.

Alternatively, if you can trap the instruction so you get a kernel trap
the first time the user app tries to do this and then set the flag then.
Otherwise there is the problem that someone will do some hand tuned
assembly that uses the 64 bit regs and you end up with mocked up state
if this goes undetected.

Cheers,
Jes
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Kyle McMartin]

On Mon, May 15, 2006 at 05:10:15AM -0400, Jes Sorensen wrote:
> 
> What about setting an ELF flag or somesuch, set a task flag based on
> this and then only do the extended register file backup for these
> apps?
>

There are bits in the PA ELF supplement for stuff like this, for
example you can certainly have a PARISC2_0 ELF32 object file.

I proposed doing exactly this when it was first brought up. There is a
slight snag though, it could get icky internally... Whoever volunteers
to do it would certain be in for some fun in entry.S amongst other places.
Probably more effort than it is worth in other words. On the other hand
the work in the same areas is probably needed to ever support HPUX 
ELF binaries.

Cheers!
	Kyle
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[John David Anglin]

> Two options from there:
> 1) we claim what I'm trying to do should not be done on parisc-linux
> => using ldd/std, MAX2 and other insns that rely on 64bit regs should
> be prohibited by binutils for non-wide code (currently gcc/binutils
> happily build my code with -mpa-risc-2-0, which generates level 2.0
> non wide code)

Well, hpux supports using 64-bit registers in non-wide code, so
I don't particularly like the idea that code generation changes
between linux and hpux.  64-bit registers are a PA 2.0 feature
and their use is independent of whether or not the processor is
in wide mode.

> 2) we claim what I'm trying to do should be possible on parisc-linux
> => we need to fix context switching in 32bit kernels.

I believe that's the correct approach.  The context state needs to
be updated for 64-bit userspace anyway.  HP-UX has some horrible
macros like GetSSReg for accessing register values in context data
(see pa/save_state.h).

config.guess for the distinguishes narrow and wide hpux kernels
(hppa2.0, hppa2.0n and hppa2.0w).  The hppa2.0 and hppa2.0n kernels
are narrow and don't support 64-bit context information.  As far
as I know, wide kernels support 64-bit context information for
the 32-bit runtime.

The GMP library is one bit of code that attempts to make use of this
capability.  It's a problem for GCC as there's no way to describe that
a register is partially call clobbered.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Thibaut VARENE]

On 5/13/06, John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:
> > Two options from there:
> > 1) we claim what I'm trying to do should not be done on parisc-linux
> > =3D> using ldd/std, MAX2 and other insns that rely on 64bit regs should
> > be prohibited by binutils for non-wide code (currently gcc/binutils
> > happily build my code with -mpa-risc-2-0, which generates level 2.0
> > non wide code)
>
> Well, hpux supports using 64-bit registers in non-wide code, so
> I don't particularly like the idea that code generation changes
> between linux and hpux.  64-bit registers are a PA 2.0 feature
> and their use is independent of whether or not the processor is
> in wide mode.

Yes I took back the wrong implication in a subsequent post.
I'm glad to hear that, that sounds sensible to me.

> > 2) we claim what I'm trying to do should be possible on parisc-linux
> > =3D> we need to fix context switching in 32bit kernels.
>
> I believe that's the correct approach.  The context state needs to
> be updated for 64-bit userspace anyway.  HP-UX has some horrible
> macros like GetSSReg for accessing register values in context data
> (see pa/save_state.h).

As James pointed out, fixing this means doubling the size of saved
registers on stack...

> config.guess for the distinguishes narrow and wide hpux kernels
> (hppa2.0, hppa2.0n and hppa2.0w).  The hppa2.0 and hppa2.0n kernels
> are narrow and don't support 64-bit context information.  As far
> as I know, wide kernels support 64-bit context information for
> the 32-bit runtime.
>
> The GMP library is one bit of code that attempts to make use of this
> capability.  It's a problem for GCC as there's no way to describe that
> a register is partially call clobbered.

There I'm a bit confused. Correct me if I'm wrong, but to be able to
effectively use 64bit registers you need the kernel to save 64bit
registers on context switch? So if the narrow kernel doesn't support
64bit context information (as it's currently the case with
parisc-linux), you can't use them?

Are you trying to say that userspace code shouldn't be using the full
registers width when running a 32bit (narrow) kernel?

If so, how can hpux support using 64bit registers in non wide mode?
Upon any context switch, their content would be messed up if only half
of it is saved...

T-Bone

--=20
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[John David Anglin]

> > I believe that's the correct approach.  The context state needs to
> > be updated for 64-bit userspace anyway.  HP-UX has some horrible
> > macros like GetSSReg for accessing register values in context data
> > (see pa/save_state.h).
> 
> As James pointed out, fixing this means doubling the size of saved
> registers on stack...

I believe that we already save 64 bits when CONFIG_64BIT is true.  See
assembly.h.

> There I'm a bit confused. Correct me if I'm wrong, but to be able to
> effectively use 64bit registers you need the kernel to save 64bit
> registers on context switch? So if the narrow kernel doesn't support
> 64bit context information (as it's currently the case with
> parisc-linux), you can't use them?

64-bit kernels run in wide mode, so they have to save/restore 64bit
registers.  It's certainly not much of an extension to save 64 bits
on user context changes.

> Are you trying to say that userspace code shouldn't be using the full
> registers width when running a 32bit (narrow) kernel?

I don't believe that it's impossible to support the full register width
with a 32bit (narrow) kernel.  However, hpux to my knowledge doesn't
support 64-bit registers when using a narrow kernel.  I think this
reflects the historical development of hpux.  The first PA 2.0 kernels
were narrow and based on the 32-bit PA 1.1 implementation.  Wide kernels
were introduced with HP-UX 11.

> If so, how can hpux support using 64bit registers in non wide mode?
> Upon any context switch, their content would be messed up if only half
> of it is saved...

Sure.  The hpux context has various flag bits (e.g. SS_WIDEREGS
and SS_NARROWISINVALID) to handle the various differences between
the PA 1.0, 1.1 and 2.0 architectures.  There was a change in
the number of floating point registers between 1.0 and 1.1, and
in the accessibility of the left and right halves.

Personally, I think the wide register support is most important
when running a 64-bit kernel and that's the place it would be
easiest to implement.  I can see that there are situations where
it would be nice to use 64-bit registers on a narrow kernel but
this would change the size of register files, the context passed
to signal handlers, etc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[John Marvin]

John David Anglin wrote:

> 
> I don't believe that it's impossible to support the full register width
> with a 32bit (narrow) kernel.  However, hpux to my knowledge doesn't
> support 64-bit registers when using a narrow kernel.  I think this
> reflects the historical development of hpux.  The first PA 2.0 kernels
> were narrow and based on the 32-bit PA 1.1 implementation.  Wide kernels
> were introduced with HP-UX 11.
> 

You are correct.

If you are running a 32 bit version of hpux on a 64 bit machine then the 
upper halfs of registers are not saved. I will note that there are not 
many (and may no longer be any) 64 bit machines that HP supports running 
a 32 bit kernel on.

If you are running a 64 bit version of hpux then the upper halfs of 
registers are saved during context switches, even if you are running a 
32 bit app. It gets interesting in a signal handler, since the registers 
are saved in the signal context twice, i.e. the 32 bit lower halfs are 
saved in one place (for backwards object compatibility), and then the 64 
bit versions are saved in another. I forget all the details about what 
happens if you want to change the saved value in the signal context.

John
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Grant Grundler]

On Sat, May 13, 2006 at 07:35:48PM -0400, John David Anglin wrote:
> > Are you trying to say that userspace code shouldn't be using the full
> > registers width when running a 32bit (narrow) kernel?
> 
> I don't believe that it's impossible to support the full register width
> with a 32bit (narrow) kernel.  However, hpux to my knowledge doesn't
> support 64-bit registers when using a narrow kernel.

I believe later 10.20 updates/patches to support PA2.0 processors did
in fact support saving/restoring 64-bits. But it's been a _long_
time since I've look at that.

> I think this
> reflects the historical development of hpux.  The first PA 2.0 kernels
> were narrow and based on the 32-bit PA 1.1 implementation.

Correct. Mostly in the form of 10.20 patches.

> Wide kernels were introduced with HP-UX 11.

Trivia: 10.30 was a T600/customer specific release that
provided 64-bit support before 11.00 was ready.

...
> Personally, I think the wide register support is most important
> when running a 64-bit kernel and that's the place it would be
> easiest to implement.  I can see that there are situations where
> it would be nice to use 64-bit registers on a narrow kernel but
> this would change the size of register files, the context passed
> to signal handlers, etc.

Oh..good point. I'm really not willing to tolerate an ABI event
for this kind of perf optimization. I'd much rather start advocating
use of 64-bit kernels in order to enable use of MAX insns.

Until HP 24-bit color gfx PCI cards work on pa2.0, I don't
see a good reason to implement this. Maybe 8-bit color with
a private color map is sufficient...


thanks,
grant

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel

[Grant Grundler]

On Sun, May 14, 2006 at 11:10:30AM -0400, John David Anglin wrote:
> > Until HP 24-bit color gfx PCI cards work on pa2.0, I don't
> > see a good reason to implement this. Maybe 8-bit color with
> > a private color map is sufficient...
> 
> Tried firefox recently?

Not on parisc. I'm regularly using it on ia64 and x86.
When I had parisc desktop 2 years ago, I got fed up with
the 8-bit color (PCI Vis_EG) and no audio (fixed now).
That's why I moved to a zx2000 (ia64) desktop.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux