Re: [Q] Looking for an emulation for CMOV* instructions.

Re: [Q] Looking for an emulation for CMOV* instructions.

[Giacomo Catenazzi]

Alan Cox wrote:

>>Just curious; is RPM a "standard" for most linux distros now? I have always
>>been running RedHat so I wouldn't know.
>>
> 
> Most but not all. Debian has a very powerful package system that is quite
> different for example. I don't know if the Debian package setup protects
> you from installing i686 binaries on an i486, but I bet within 48 hours of
> this discussion it will do anyway


Debian doesn't have this feature.
Debian policy tell us: i386 is fine. Performance gain is minimal (or nothing)
so compile with in i386 compatible mode.
(on package that performance matter, there exists an optional package with
an extra suffix (i.e. 686). So user can choice the more performant
package (but not the default)).
But numbers (profiles) have told us that such package are less then 1
every 1000.

[In debian-devel list this is a frequent flamewar. But until we have
'number' that told us to add a PPro optimization, we don't move.
Debian have not the the marketing need of other distributions.
(We are are the best distribution :-) ) ]

	giacomo

Re: [Q] Looking for an emulation for CMOV* instructions.

[Adam J. Richter]

H. Peter Anvin wrote, in response to Andi Kleen:
>You don't need CMPXCHG8B to do efficient inline mutexes.  In fact, the
>pthreads code for i386 uses the same mutexes the kernel does (LOCK INC
>based, I believe), complete with section hacking to make them
>efficiently inlinable -- and then they're put inside a function call.
[...]

	Your comment prompted me to look at
linux-2.5.2-pre11/include/asm-i386/spinlock.h, and I now believe that
the "lock; decb" that it uses for grabbing spinlocks will return an
incorrect success if 255 or more processors are waiting on the same
spinlock.  I don't know if anybody has ever built a shared memory x86
multiprocessor with 257 (not a typo) or more CPU's, but it's possible
to imagine.  It's also possible to imagine this scenario happening
with even just one processor and a preemtable kernel.  I believe that
the current preemtable kernel patch limits the number of preempted
processes to something like four or six, but that's just a temporary
limitation of the current version.

	If we get the point where this scenario really could happen,
then maybe the spin lock counter type should be expanded from one byte
to four.  I think we already assume four byte alignment in
asm-i386/semaphore.h, which uses a four byte count (I think "lock" is
not guaranteed to work across page boundaries).

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: [Q] Looking for an emulation for CMOV* instructions.

[David Weinehall]

On Sat, Jan 12, 2002 at 02:48:53AM -0800, Adam J. Richter wrote:
> H. Peter Anvin wrote, in response to Andi Kleen:
> >You don't need CMPXCHG8B to do efficient inline mutexes.  In fact, the
> >pthreads code for i386 uses the same mutexes the kernel does (LOCK INC
> >based, I believe), complete with section hacking to make them
> >efficiently inlinable -- and then they're put inside a function call.
> [...]
> 
> 	Your comment prompted me to look at
> linux-2.5.2-pre11/include/asm-i386/spinlock.h, and I now believe that
> the "lock; decb" that it uses for grabbing spinlocks will return an
> incorrect success if 255 or more processors are waiting on the same
> spinlock.  I don't know if anybody has ever built a shared memory x86
> multiprocessor with 257 (not a typo) or more CPU's, but it's possible
> to imagine.  It's also possible to imagine this scenario happening
> with even just one processor and a preemtable kernel.  I believe that
> the current preemtable kernel patch limits the number of preempted
> processes to something like four or six, but that's just a temporary
> limitation of the current version.

AFAIK, there's more code than this that won't work with >255
processors... It's not like each and every person on this list has
such a beast to test with (and probably most never will even if they
do exist, or come to existance...)


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [Q] Looking for an emulation for CMOV* instructions.

[Brian Gerst]

"Adam J. Richter" wrote:
> 
> H. Peter Anvin wrote, in response to Andi Kleen:
> >You don't need CMPXCHG8B to do efficient inline mutexes.  In fact, the
> >pthreads code for i386 uses the same mutexes the kernel does (LOCK INC
> >based, I believe), complete with section hacking to make them
> >efficiently inlinable -- and then they're put inside a function call.
> [...]
> 
>         Your comment prompted me to look at
> linux-2.5.2-pre11/include/asm-i386/spinlock.h, and I now believe that
> the "lock; decb" that it uses for grabbing spinlocks will return an
> incorrect success if 255 or more processors are waiting on the same
> spinlock.

Implementation detail.  You could just as easily use a long instead of a
char and have room for 2^32 processors.

--
						Brian Gerst

Re: [Q] Looking for an emulation for CMOV* instructions.

[H. Peter Anvin]

Adam J. Richter wrote:

> 
> 	Your comment prompted me to look at
> linux-2.5.2-pre11/include/asm-i386/spinlock.h, and I now believe that
> the "lock; decb" that it uses for grabbing spinlocks will return an
> incorrect success if 255 or more processors are waiting on the same
> spinlock.  I don't know if anybody has ever built a shared memory x86
> multiprocessor with 257 (not a typo) or more CPU's, but it's possible
> to imagine.  It's also possible to imagine this scenario happening
> with even just one processor and a preemtable kernel.  I believe that
> the current preemtable kernel patch limits the number of preempted
> processes to something like four or six, but that's just a temporary
> limitation of the current version.
> 


Linux specificially does not allow for more processors than there are 
bits in a long (32 or 64).  Libc, however, since it counts processes, 
not CPUs, uses a 4-byte word.

	-hpa

Re: [Q] Looking for an emulation for CMOV* instructions.

[willy tarreau]

> Gee, when was the last time Intel removed something
> from the instruction set? An old 80286 instruction
> comes to mind, but that was a super-CISC mess that
> was really specific to the implementation. Anything
> really useful that was ever removed?

well, the 8088/8086 supported the POP CS instruction
which was used by a virus and 80186/80286 broke this
virus (which was rewritten anyway).

The undocumented loadall instruction changes from
CPU to CPU, and the IBTS/XBTS bit string manipulation
instructions appeared in Step A 386 and disappeared
later. The Step A 486 reused their opcodes for CMPXCHG
and it changed just after in Step B.

This are very rare cases, but at least some
developpers could have based their work on the
existence of IBTS/XBTS but it disappeared.

Anyway, I cannot imagine that they could break
compatibility by removing CMOV !

Regards,
Willy


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Courrier : http://courrier.yahoo.fr

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> Anyway, I cannot imagine that they could break
> compatibility by removing CMOV !

It wouldnt be a break. They explicitly allow themselves to do so in their
documentation.
 

Re: [Q] Looking for an emulation for CMOV* instructions.

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> The kernel isnt there to fix up the fact authors can't read. Its also very
> hard to get emulations right. I grant that this wasn't helped by the fact
> the gcc x86 folks also couldnt read the pentium pro manual correctly.

One corner case where emulation would IMHO make sense would be CMPXCHG8.
It would allow to do efficient inline mutexes in pthreads, and hit the
emulation only on 386/486. cpu feature flag checking is unfortunately
not an option normally for inline code.

-Andi (who would have already done it if he had an 486/386 to test) 

Re: [Q] Looking for an emulation for CMOV* instructions.

[Pavel Machek]

Hi!

> > The kernel isnt there to fix up the fact authors can't read. Its also very
> > hard to get emulations right. I grant that this wasn't helped by the fact
> > the gcc x86 folks also couldnt read the pentium pro manual correctly.
> 
> One corner case where emulation would IMHO make sense would be CMPXCHG8.
> It would allow to do efficient inline mutexes in pthreads, and hit the
> emulation only on 386/486. cpu feature flag checking is unfortunately
> not an option normally for inline code.
> 
> -Andi (who would have already done it if he had an 486/386 to test) 

Do you want one? I have elonex, which is 486sx, small and quiet (needs 
NFS root). But I'd want it back eventually. Or I might be able to get
you some 386...
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [Q] Looking for an emulation for CMOV* instructions.

[H. Peter Anvin]

Followup to:  <p737kqpp60w.fsf@oldwotan.suse.de>
By author:    Andi Kleen <ak@suse.de>
In newsgroup: linux.dev.kernel
>  
> One corner case where emulation would IMHO make sense would be CMPXCHG8.
> It would allow to do efficient inline mutexes in pthreads, and hit the
> emulation only on 386/486. cpu feature flag checking is unfortunately
> not an option normally for inline code.
> 

You don't need CMPXCHG8B to do efficient inline mutexes.  In fact, the
pthreads code for i386 uses the same mutexes the kernel does (LOCK INC
based, I believe), complete with section hacking to make them
efficiently inlinable -- and then they're put inside a function call.
I believe "kill me now" is an appropriate response.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [Q] Looking for an emulation for CMOV* instructions.

[willy tarreau]

> is it possible to include an emulation for the CMOV*
(and
> possible other i686 instructions) for processors
that dont

I did something similar to emulate 486 instructions
for 386s
(bswap, cmpxchg...). You can reuse it if needed. It's 
available for 2.2 and 2.4 at this location :

http://www-miaif.lip6.fr/willy/linux-patches/486emulation/

Regards,
Willy


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Courrier : http://courrier.yahoo.fr

Re: [Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

On Fri, 11 Jan 2002 10:25:48 +0100 (CET), willy tarreau wrote:

>> is it possible to include an emulation for the CMOV*
> (and
>> possible other i686 instructions) for processors
> that dont

> I did something similar to emulate 486 instructions
> for 386s
> (bswap, cmpxchg...). You can reuse it if needed. It's 
> available for 2.2 and 2.4 at this location :

> http://www-miaif.lip6.fr/willy/linux-patches/486emulation/

Thanks! I will have a look into it.

ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

[Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

Hallo kernel hackers,

is it possible to include an emulation for the CMOV* (and possible other
i686 instructions) for processors that dont have these (k6, pentium
etc.)? I think this should work like the fpu emulation. Even if its slow
it will allow you to work even if you tried to install a libc for i686
on an older architecture or if you have apps that are statically linked
against such a libc (rpm, e2fschk, etc.).

I found some info on this here:

        http://gwenole.beauchesne.online.fr/basilisk2/

        "... * uae_jit: added CMOV "emulation" for processors that don't
         support them ..."

Maybe this can be of any use to hack it in the kernel?

thanx,
ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> is it possible to include an emulation for the CMOV* (and possible other
> i686 instructions) for processors that dont have these (k6, pentium
> etc.)? I think this should work like the fpu emulation. Even if its slow

The kernel isnt there to fix up the fact authors can't read. Its also very
hard to get emulations right. I grant that this wasn't helped by the fact
the gcc x86 folks also couldnt read the pentium pro manual correctly.

If you have a static linked program install the right version. RPMv4
even knows about cmov and i686 rpms.

Re: [Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

On Thu, 10 Jan 2002 23:28:48 +0000 (GMT), Alan Cox wrote:

>> is it possible to include an emulation for the CMOV* (and possible other
>> i686 instructions) for processors that dont have these (k6, pentium
>> etc.)? I think this should work like the fpu emulation. Even if its slow

> The kernel isnt there to fix up the fact authors can't read. Its also very
> hard to get emulations right. I grant that this wasn't helped by the fact
> the gcc x86 folks also couldnt read the pentium pro manual correctly.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^       
What do you mean with this? Explain, please!

> If you have a static linked program install the right version. RPMv4
> even knows about cmov and i686 rpms.

The problem I had is the following: I make all of my linux binaries
myself but I have also some older machines here that have a k6 or a
pentium. For mistake I installed the wrong rpm and had a non working
system. An emulation for such cases would be a _real_ feature at least
more than a pinguin boot logo (if one uses the framebuffer console).
I think a stable and possible self correcting [1] system should be the aim
of a modern OS. Maybe I will have a look on implementing the emulation
but I thought I'll find someone here who has done this already (or is
willing to do so).

ron

[1] This means catching most or all errors and correct them as good as
    possible. Only a running system is a good system. ;-)

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> > hard to get emulations right. I grant that this wasn't helped by the fact
> > the gcc x86 folks also couldnt read the pentium pro manual correctly.
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^       
> What do you mean with this? Explain, please!

gcc told to generate i686 binaries uses cmov unconditionally. The intel
PPro handbook explicitly says that cmov must be checked for.

> myself but I have also some older machines here that have a k6 or a
> pentium. For mistake I installed the wrong rpm and had a non working
> system. An emulation for such cases would be a _real_ feature at least

So you have a buggy rpm program. Get the rpm program fixed so it correctly
stops you from doing that.

Alan
--
	    If my call is so important to you why don't you hire 
		  some more people to answer the telephone? 

Re: [Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

On Fri, 11 Jan 2002 00:26:07 +0000 (GMT), Alan Cox wrote:

>> > hard to get emulations right. I grant that this wasn't helped by the fact
>> > the gcc x86 folks also couldnt read the pentium pro manual correctly.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^       
>> What do you mean with this? Explain, please!

> gcc told to generate i686 binaries uses cmov unconditionally. The intel
> PPro handbook explicitly says that cmov must be checked for.

The compiler doesn't know, where the binary runs later. Or do you mean,
that it has to insert some code that checks for the existance of these
instructions during program start? Ok that would be a solution, but how
do you do this for libraries that are not run in itself?

>> myself but I have also some older machines here that have a k6 or a
>> pentium. For mistake I installed the wrong rpm and had a non working
>> system. An emulation for such cases would be a _real_ feature at least

> So you have a buggy rpm program. Get the rpm program fixed so it correctly
> stops you from doing that.

Maybe, ok. But why should such a mistake prevent me from workin with the
system when it could be easily catched? Ok, the emulation code may not
be easy, I dunno, but the infrastructure for emulation of instructions
is already there (FPU emulation). To say its the admins fault is easy
but the costs of automatically catching such errors are little in
respect of the benefit you get. A running system is always better than
a unusable one even if it was the admins fault.

ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> The compiler doesn't know, where the binary runs later. Or do you mean,
> that it has to insert some code that checks for the existance of these
> instructions during program start? Ok that would be a solution, but how
> do you do this for libraries that are not run in itself?

It means the compiler for -m686 shouldn't have assumed cmov was available

> > So you have a buggy rpm program. Get the rpm program fixed so it correctly
> > stops you from doing that.
> 
> Maybe, ok. But why should such a mistake prevent me from workin with the
> system when it could be easily catched? Ok, the emulation code may not

It can be easily caught. Thats what rpm is for. If it let you install that
package on a box that can run it without using --force type options its
a bug. 

> be easy, I dunno, but the infrastructure for emulation of instructions
> is already there (FPU emulation). To say its the admins fault is easy

FPU emulation should probably have been in glibc via a fault handler
but thats a historical story.

> but the costs of automatically catching such errors are little in
> respect of the benefit you get. A running system is always better than
> a unusable one even if it was the admins fault.

Then while you are it you can make the kernel magically recover from rm -rf /
or rm * in /lib...

Re: [Q] Looking for an emulation for CMOV* instructions.

[Martin Eriksson]

----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "Ronald Wahl" <Ronald.Wahl@informatik.tu-chemnitz.de>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>; <linux-kernel@vger.kernel.org>
Sent: Friday, January 11, 2002 1:54 AM
Subject: Re: [Q] Looking for an emulation for CMOV* instructions.


<snip>
> It can be easily caught. Thats what rpm is for. If it let you install that
> package on a box that can run it without using --force type options its
> a bug.

Just curious; is RPM a "standard" for most linux distros now? I have always
been running RedHat so I wouldn't know.

Maybe Ronald should start a new kernel tree with patches for goofy admins ;D

Re: [Q] Looking for an emulation for CMOV* instructions.

[Timothy Covell]

On Thursday 10 January 2002 19:09, Martin Eriksson wrote:
> ----- Original Message -----
> From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
> To: "Ronald Wahl" <Ronald.Wahl@informatik.tu-chemnitz.de>
> Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>; <linux-kernel@vger.kernel.org>
> Sent: Friday, January 11, 2002 1:54 AM
> Subject: Re: [Q] Looking for an emulation for CMOV* instructions.
>
>
> <snip>
>
> > It can be easily caught. Thats what rpm is for. If it let you install
> > that package on a box that can run it without using --force type options
> > its a bug.
>
> Just curious; is RPM a "standard" for most linux distros now? I have always
> been running RedHat so I wouldn't know.

IIRC, it is a standard according to the FHS.   Please let's not get started 
on the RPM v. Apt debate.

>
> Maybe Ronald should start a new kernel tree with patches for goofy admins
> ;D

You know, it's funny how people think.  I'm sure that  we all have had some 
ideas which appear goofy to others, esp. at first blush.   I think that 
creativity requires that thoughts sometimes be juxtaposed in a goofy manner;
usually it  creates garbage, but sometimes it's like peanut butter and 
chocolate. :-)

That much said, a good system administrator should be able to handle this
situation without having to rely on RPM.   The fact that that RedHat ships 
everything defaulted to i386 (except the kernel) is just one more proof of 
good thinking.  If you know what you're doing, then Mandrake i586 is good, 
but can be a rude awakening for newbies, which is Mandrake's target it
would seem.

IMHO, for ordinary day to day tasks, the gains from compiling -m[4|5|6] are
not worth the effort and extra administrative work.


-- 
timothy.covell@ashavan.org.

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> Just curious; is RPM a "standard" for most linux distros now? I have always
> been running RedHat so I wouldn't know.

Most but not all. Debian has a very powerful package system that is quite
different for example. I don't know if the Debian package setup protects
you from installing i686 binaries on an i486, but I bet within 48 hours of
this discussion it will do anyway

Re: [Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

On Fri, 11 Jan 2002 00:54:29 +0000 (GMT), Alan Cox wrote:

>> The compiler doesn't know, where the binary runs later. Or do you mean,
>> that it has to insert some code that checks for the existance of these
>> instructions during program start? Ok that would be a solution, but how
>> do you do this for libraries that are not run in itself?

> It means the compiler for -m686 shouldn't have assumed cmov was
> available

It's not the compiler that is responsible for it. At least in my case.
The problem is that if you compile the glibc than some assembler code
gets included into glibc.  So the problem here is glibc and not gcc.
Ok, the way to go for me now will be to make a new glibc without this
instructions. But I still think it would be a step to more fault
tolerance (or tolerance to goofy admins ;-) if we could have an
emulation of this. If I find some time I will do this...

>> but the costs of automatically catching such errors are little in
>> respect of the benefit you get. A running system is always better than
>> a unusable one even if it was the admins fault.

> Then while you are it you can make the kernel magically recover from rm -rf /
> or rm * in /lib...

Let the FS driver copy all modified sectors into a hidden log on the
disk (fixed or dynamic in size or as a ringbuffer). Then e.g during
kernel startup in case you removed most of the system you might be asked
to recover from some point. Such concepts are used by software like
HDD-Sheriff but one level below (disc sector level). On filesystem level
it makes more sense since you may recover partially. All that will bloat
the kernel but it would be possible. This case is one that has (very)
high costs. Not that I want this but I want to show that there _are_
ways to do it.

ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

Re: [Q] Looking for an emulation for CMOV* instructions.

[Richard Henderson]

On Fri, Jan 11, 2002 at 12:54:29AM +0000, Alan Cox wrote:
> It means the compiler for -m686 shouldn't have assumed cmov was available

Eh?  -march=i686 *asserts* that cmov is available.

What's the point of optimizing an IF to a cmov if I have
to insert another IF to see if I can use cmov?


r~

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> > It means the compiler for -m686 shouldn't have assumed cmov was available
> 
> Eh?  -march=i686 *asserts* that cmov is available.

So why is it called "i686" when the intel i686 machine definition says
its optional ? Its just the naming that seems odd

> What's the point of optimizing an IF to a cmov if I have
> to insert another IF to see if I can use cmov?

I've always wondered. Intel made the instruction optional yet there isnt
an obvious way to do runtime fixups on it

Re: [Q] Looking for an emulation for CMOV* instructions.

[Albert D. Cahalan]

Alan Cox writes:
> [somebody]

>> Eh?  -march=i686 *asserts* that cmov is available.
>
> So why is it called "i686" when the intel i686 machine definition
> says its optional ? Its just the naming that seems odd
>
>> What's the point of optimizing an IF to a cmov if I have
>> to insert another IF to see if I can use cmov?
>
> I've always wondered. Intel made the instruction optional
> yet there isnt an obvious way to do runtime fixups on it

This may design-by-committee in action, or corporate rules
that are hard to defy. Don't worry about it. Intel will
never produce a new x86-compatible chip without cmov.
Nobody else will either.

Gee, when was the last time Intel removed something from the
instruction set? An old 80286 instruction comes to mind, but
that was a super-CISC mess that was really specific to the
implementation. Anything really useful that was ever removed?

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> that are hard to defy. Don't worry about it. Intel will
> never produce a new x86-compatible chip without cmov.
> Nobody else will either.

People already do. The C3 and C5. The fact the real world i686 definition
and the compiler one differed caused much pain in the package installing
department.

Alan

Re: [Q] Looking for an emulation for CMOV* instructions.

[Jamie Lokier]

Alan Cox wrote:
> > What's the point of optimizing an IF to a cmov if I have
> > to insert another IF to see if I can use cmov?
> 
> I've always wondered. Intel made the instruction optional yet there isnt
> an obvious way to do runtime fixups on it

Yes there is -- emulation! :-)

-- Jamie

Re: [Q] Looking for an emulation for CMOV* instructions.

[Richard B. Johnson]

On Wed, 16 Jan 2002, Jamie Lokier wrote:

> Alan Cox wrote:
> > > What's the point of optimizing an IF to a cmov if I have
> > > to insert another IF to see if I can use cmov?
> > 
> > I've always wondered. Intel made the instruction optional yet there isnt
> > an obvious way to do runtime fixups on it
> 
> Yes there is -- emulation! :-)
> 

It's just as bad, probably worse! You trap on an invalid op-code. The
trap-handler checks the op-code and if it's emulated, it emulates it
and returns to the executing task. This takes many instruction cycles,
certainly more than `if(cmov) doit; else do_something_else;` --which,
itself, takes many more instruction cycles than cmov is supposed to
reduce. It's a no-win situation. The only way to win is a compile-time
choice. This means customizing for your CPU IFF it has the cmov
instruction.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: [Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

On Wed, 16 Jan 2002 11:16:55 -0500 (EST), Richard B Johnson wrote:

> On Wed, 16 Jan 2002, Jamie Lokier wrote:
>> Alan Cox wrote:
>> > > What's the point of optimizing an IF to a cmov if I have
>> > > to insert another IF to see if I can use cmov?
>> > 
>> > I've always wondered. Intel made the instruction optional yet there isnt
>> > an obvious way to do runtime fixups on it
>> 
>> Yes there is -- emulation! :-)
>> 

> It's just as bad, probably worse! You trap on an invalid op-code. The
> trap-handler checks the op-code and if it's emulated, it emulates it
> and returns to the executing task. This takes many instruction cycles,
> certainly more than `if(cmov) doit; else do_something_else;` --which,
> itself, takes many more instruction cycles than cmov is supposed to
> reduce. It's a no-win situation. The only way to win is a compile-time
> choice. This means customizing for your CPU IFF it has the cmov
> instruction.

It is a big win in the situation where you have only a binary for i686
and want or better must execute it e.g. on a i586. This was the reason
why I asked initially.

ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

Re: [Q] Looking for an emulation for CMOV* instructions.

[Dave Jones]

On Wed, Jan 16, 2002 at 03:18:52PM +0000, Jamie Lokier wrote:
 > > > What's the point of optimizing an IF to a cmov if I have
 > > > to insert another IF to see if I can use cmov?
 > > I've always wondered. Intel made the instruction optional yet there isnt
 > > an obvious way to do runtime fixups on it
 > Yes there is -- emulation! :-)

 Too much overhead to be of practical use..

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [Q] Looking for an emulation for CMOV* instructions.

[Maciej W. Rozycki]

On Wed, 16 Jan 2002, Jamie Lokier wrote:

> > I've always wondered. Intel made the instruction optional yet there isnt
> > an obvious way to do runtime fixups on it
> 
> Yes there is -- emulation! :-)

 For shared libraries the dynamic linker could choose appropriate images.

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

Re: [Q] Looking for an emulation for CMOV* instructions.

[Hans-Peter Jansen]

On Friday, 11. January 2002 00:28, Alan Cox wrote:
> > is it possible to include an emulation for the CMOV* (and possible other
> > i686 instructions) for processors that dont have these (k6, pentium
> > etc.)? I think this should work like the fpu emulation. Even if its slow
>
> The kernel isnt there to fix up the fact authors can't read. Its also very
> hard to get emulations right. I grant that this wasn't helped by the fact
> the gcc x86 folks also couldnt read the pentium pro manual correctly.

But it shouldn't crash, if the wrong architecture is chosen. (Different
problem, I know) Perfect solution would be emulate them all, but at least
an simple error message (please eject CPU, and put in a XXX one) would be 
sufficient, IMHO. 

> If you have a static linked program install the right version. RPMv4
> even knows about cmov and i686 rpms.

Hans-Peter

Re: [Q] Looking for an emulation for CMOV* instructions.

[Ronald Wahl]

On Fri, 11 Jan 2002 20:59:45 +0100, Hans-Peter Jansen wrote:

> On Friday, 11. January 2002 00:28, Alan Cox wrote:
>> > is it possible to include an emulation for the CMOV* (and possible other
>> > i686 instructions) for processors that dont have these (k6, pentium
>> > etc.)? I think this should work like the fpu emulation. Even if its slow
>> 
>> The kernel isnt there to fix up the fact authors can't read. Its also very
>> hard to get emulations right. I grant that this wasn't helped by the fact
>> the gcc x86 folks also couldnt read the pentium pro manual correctly.

> But it shouldn't crash, if the wrong architecture is chosen. (Different
> problem, I know) Perfect solution would be emulate them all, but at least
> an simple error message (please eject CPU, and put in a XXX one) would be 
> sufficient, IMHO. 

A message occurs already: "Illegal instruction". But this is not
really a help.

ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alan Cox]

> A message occurs already: "Illegal instruction". But this is not
> really a help.

So LD_PRELOAD a library that handles it

Re: [Q] Looking for an emulation for CMOV* instructions.

[Pavel Machek]

HI!

> > is it possible to include an emulation for the CMOV* (and possible other
> > i686 instructions) for processors that dont have these (k6, pentium
> > etc.)? I think this should work like the fpu emulation. Even if its slow
> 
> The kernel isnt there to fix up the fact authors can't read. Its also very
> hard to get emulations right. I grant that this wasn't helped by the fact
> the gcc x86 folks also couldnt read the pentium pro manual correctly.

How long does it take until netscape binaries contain CMOV? We already do
FPU emulation (you can do soft-float, so you do NOT need FP emulation!), so
I guess this would begood freature.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [Q] Looking for an emulation for CMOV* instructions.

[H. Peter Anvin]

Followup to:  <20020112062735.D511@toy.ucw.cz>
By author:    Pavel Machek <pavel@suse.cz>
In newsgroup: linux.dev.kernel
>
> HI!
> 
> > > is it possible to include an emulation for the CMOV* (and possible other
> > > i686 instructions) for processors that dont have these (k6, pentium
> > > etc.)? I think this should work like the fpu emulation. Even if its slow
> > 
> > The kernel isnt there to fix up the fact authors can't read. Its also very
> > hard to get emulations right. I grant that this wasn't helped by the fact
> > the gcc x86 folks also couldnt read the pentium pro manual correctly.
> 
> How long does it take until netscape binaries contain CMOV? We already do
> FPU emulation (you can do soft-float, so you do NOT need FP emulation!), so
> I guess this would begood freature.
> 

The difference is that the overhead of doing FP emulation is
acceptable when compared to softfloat; this is not the case for CMOV
unless you can somehow patch the binary on the fly.

At some point it might make sense to run "the one program" that you
otherwise can't live without, but I don't think it's gotten to that
stage yet.  Which is, in some ways, unfortunate.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [Q] Looking for an emulation for CMOV* instructions.

[Pavel Machek]

Hi!

> The kernel isnt there to fix up the fact authors can't read. Its also very
> hard to get emulations right. I grant that this wasn't helped by the fact

What's so hard about CMOV?

> If you have a static linked program install the right version. RPMv4
> even knows about cmov and i686 rpms.

RPM does not help. Think new machine failed, but you still have some trash
with 386 on it, so you connect your disk to it, boot from floppy, and expect
it to work.
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [Q] Looking for an emulation for CMOV* instructions.

[David Woodhouse]

pavel@suse.cz said:
>  RPM does not help. Think new machine failed, but you still have some
> trash with 386 on it, so you connect your disk to it, boot from
> floppy, and expect it to work.

What if my spare machine is an ARM? Should I still expect it to work?

--
dwmw2

Re: [Q] Looking for an emulation for CMOV* instructions.

[Pavel Machek]

Hi!

> >  RPM does not help. Think new machine failed, but you still have some
> > trash with 386 on it, so you connect your disk to it, boot from
> > floppy, and expect it to work.
> 
> What if my spare machine is an ARM? Should I still expect it to work?

Let's say "It is easy in 386 case and hard in ARM case". Besides, we
do FPU emulation already. Way harder than CMOV emulation, and serves
exactly same purpose.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [Q] Looking for an emulation for CMOV* instructions.

[Alistair Riddell]

On 11 Jan 2002, Ronald Wahl wrote:

> is it possible to include an emulation for the CMOV* (and possible other
> i686 instructions) for processors that dont have these (k6, pentium

Where does it stop? Perhaps we should emulate PPC and Sparc instructions
in the kernel, in case the sysadmin installs wrong architecture
package....





;-)

-- 
Alistair Riddell - BOFH
IT Manager, George Watson's College, Edinburgh
Tel: +44 131 446 6070    Fax: +44 131 452 8594
Microsoft - because god hates us