Subject: lwl-lwr

From: "Gilad Benjamini" <[email-masked]>
Date: Tue, 20 May 2003 18:32:31 +0000

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

---

From: Will Jhun <[email-masked]>
Date: Tue, 20 May 2003 11:34:36 -0700

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

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Tue, 20 May 2003 21:07:26 +0200

> If this is a performance issue, I'll be happy

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.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 21 May 2003 01:34:49 +0100

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 21 May 2003 11:56:44 +0200 (MET DST)

> 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: [email-masked], PGP key available        +

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Wed, 21 May 2003 15:40:25 +0200

>From: "Maciej W. Rozycki" [email-masked]
>

> 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.

---

From: Alan Cox <[email-masked]>
Date: 21 May 2003 13:49:45 +0100

> > of lwr/lwl to do the appropriate shifts and masks (which is slower on all 

This would seem the sane approach. 

> 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.