lwl-lwr

lwl-lwr

[Gilad Benjamini]

Hi,
About two months ago there was a discussion
here about disabling lwl-lwr.

Can someone shed some light on why the discussion
emerged ?

Is this a performance issue, a processor which 
doesn't support it, or something else ?

If this is a performance issue, I'll be happy
to hear more details.

TIA

Re: lwl-lwr

[Will Jhun]

Some free or "MIPS-like" CPUs don't implement it because of a patent
problem. I've seen at least one implementation on opencores.org that has
this (missing) feature.

Probably if the compiler were to emit lwl and lwr code via
__attribute__((packed)), these instructions would have to be emulated by
the kernel on such a CPU. I imagine this would be quite a bit worse than
just doing two normal loads and extracting the desired word.

Will

On Tue, May 20, 2003 at 06:32:31PM +0000, Gilad Benjamini wrote:
> Hi,
> About two months ago there was a discussion
> here about disabling lwl-lwr.
> 
> Can someone shed some light on why the discussion
> emerged ?
> 
> Is this a performance issue, a processor which 
> doesn't support it, or something else ?
> 
> If this is a performance issue, I'll be happy
> to hear more details.
> 
> TIA
> 
> 
> 

Re: lwl-lwr

[Kevin D. Kissell]

> About two months ago there was a discussion
> here about disabling lwl-lwr.
> 
> Can someone shed some light on why the discussion
> emerged ?
> 
> Is this a performance issue, a processor which 
> doesn't support it, or something else ?
> 
> If this is a performance issue, I'll be happy
> to hear more details.

I don't remember the discussion in question, but it's a question
which comes up from time to time, due to the existence of 
MIPS-like CPUs which lack the (patented) lwl/lwr mechanism
for dealing with unaligned data.  The Lexra cores, for example.

There's really no such thing as "disabling" lwl/lwr.  They are part 
of the base MIPS instruction set.  If one wants to live without them, 
one can either rig a compiler to emit multi-instruction sequences instead 
of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
targets), or you can rig the OS to emulate them, and hope that the processors 
lacking support will take clean reserved instruction traps, where the function 
can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
but *really* slow for the guys doing emulation).

            Kevin K.

Re: lwl-lwr

[Kevin D. Kissell]

> About two months ago there was a discussion
> here about disabling lwl-lwr.
> 
> Can someone shed some light on why the discussion
> emerged ?
> 
> Is this a performance issue, a processor which 
> doesn't support it, or something else ?
> 
> If this is a performance issue, I'll be happy
> to hear more details.

I don't remember the discussion in question, but it's a question
which comes up from time to time, due to the existence of 
MIPS-like CPUs which lack the (patented) lwl/lwr mechanism
for dealing with unaligned data.  The Lexra cores, for example.

There's really no such thing as "disabling" lwl/lwr.  They are part 
of the base MIPS instruction set.  If one wants to live without them, 
one can either rig a compiler to emit multi-instruction sequences instead 
of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
targets), or you can rig the OS to emulate them, and hope that the processors 
lacking support will take clean reserved instruction traps, where the function 
can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
but *really* slow for the guys doing emulation).

            Kevin K.

Re: lwl-lwr

[Ralf Baechle]

On Tue, May 20, 2003 at 09:07:26PM +0200, Kevin D. Kissell wrote:

> I don't remember the discussion in question, but it's a question
> which comes up from time to time, due to the existence of 
> MIPS-like CPUs which lack the (patented) lwl/lwr mechanism
> for dealing with unaligned data.  The Lexra cores, for example.
> 
> There's really no such thing as "disabling" lwl/lwr.  They are part 
> of the base MIPS instruction set.  If one wants to live without them, 
> one can either rig a compiler to emit multi-instruction sequences instead 
> of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> targets), or you can rig the OS to emulate them, and hope that the processors 
> lacking support will take clean reserved instruction traps, where the function 
> can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> but *really* slow for the guys doing emulation).

Technically you're right ...  In reality lwl/lwr are covered by US patent
4,814,976 which would also cover a software implementation.  So unless MIPS
grants a license for the purpose of emulation in the Linux kernel ...

  Ralf

Re: lwl-lwr

[Maciej W. Rozycki]

On Wed, 21 May 2003, Ralf Baechle wrote:

> > There's really no such thing as "disabling" lwl/lwr.  They are part 
> > of the base MIPS instruction set.  If one wants to live without them, 
> > one can either rig a compiler to emit multi-instruction sequences instead 
> > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> > targets), or you can rig the OS to emulate them, and hope that the processors 
> > lacking support will take clean reserved instruction traps, where the function 
> > can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> > but *really* slow for the guys doing emulation).
> 
> Technically you're right ...  In reality lwl/lwr are covered by US patent
> 4,814,976 which would also cover a software implementation.  So unless MIPS
> grants a license for the purpose of emulation in the Linux kernel ...

 For practical reasons I believe it can be dealt with without patent
infringing, but I am not that excited with doing anything at all about it. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: lwl-lwr

[Kevin D. Kissell]

>From: "Maciej W. Rozycki" macro@ds2.pg.gda.pl
>

> On Wed, 21 May 2003, Ralf Baechle wrote:
> 
> > > There's really no such thing as "disabling" lwl/lwr.  They are part 
> > > of the base MIPS instruction set.  If one wants to live without them, 
> > > one can either rig a compiler to emit multi-instruction sequences instead 
> > > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> > > targets), or you can rig the OS to emulate them, and hope that the processors 
> > > lacking support will take clean reserved instruction traps, where the function 
> > > can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> > > but *really* slow for the guys doing emulation).
> > 
> > Technically you're right ...  In reality lwl/lwr are covered by US patent
> > 4,814,976 which would also cover a software implementation.  So unless MIPS
> > grants a license for the purpose of emulation in the Linux kernel ...
> 
>  For practical reasons I believe it can be dealt with without patent
> infringing, but I am not that excited with doing anything at all about it. 

I agree.  I've never read the patent, but now that you mention it, I do
recall having heard that it covers software implementations.  Lets just
leave this one alone...

            Kevin K.

Re: lwl-lwr

[Kevin D. Kissell]

>From: "Maciej W. Rozycki" macro@ds2.pg.gda.pl
>

> On Wed, 21 May 2003, Ralf Baechle wrote:
> 
> > > There's really no such thing as "disabling" lwl/lwr.  They are part 
> > > of the base MIPS instruction set.  If one wants to live without them, 
> > > one can either rig a compiler to emit multi-instruction sequences instead 
> > > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 
> > > targets), or you can rig the OS to emulate them, and hope that the processors 
> > > lacking support will take clean reserved instruction traps, where the function 
> > > can be emulated (which is "free" for code running  on CPUs with lwl/lwr, 
> > > but *really* slow for the guys doing emulation).
> > 
> > Technically you're right ...  In reality lwl/lwr are covered by US patent
> > 4,814,976 which would also cover a software implementation.  So unless MIPS
> > grants a license for the purpose of emulation in the Linux kernel ...
> 
>  For practical reasons I believe it can be dealt with without patent
> infringing, but I am not that excited with doing anything at all about it. 

I agree.  I've never read the patent, but now that you mention it, I do
recall having heard that it covers software implementations.  Lets just
leave this one alone...

            Kevin K.

Re: lwl-lwr

[Alan Cox]

On Mer, 2003-05-21 at 01:34, Ralf Baechle wrote:
> > of the base MIPS instruction set.  If one wants to live without them, 
> > one can either rig a compiler to emit multi-instruction sequences instead 
> > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 

This would seem the sane approach. 

> Technically you're right ...  In reality lwl/lwr are covered by US patent
> 4,814,976 which would also cover a software implementation.  So unless MIPS
> grants a license for the purpose of emulation in the Linux kernel ...

They would need to grant a license for general GPL use, the GPL itself
does not intend to allow other restrictions that would make the code non
free. There are a billion examples of prior art for software fixing up
of exceptions and software emulation of alignment fixups however.

Maybe MIPS can clarify their position officially.