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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
> 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.
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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
> > 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?
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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
> 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...
----- Original Message -----
From: "Alan Cox" <[email protected]>
To: "Ronald Wahl" <[email protected]>
Cc: "Alan Cox" <[email protected]>; <[email protected]>
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
On Thursday 10 January 2002 19:09, Martin Eriksson wrote:
> ----- Original Message -----
> From: "Alan Cox" <[email protected]>
> To: "Ronald Wahl" <[email protected]>
> Cc: "Alan Cox" <[email protected]>; <[email protected]>
> 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.
--
[email protected].
> 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
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
> 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
Alan Cox <[email protected]> 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)
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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
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
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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
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~
> > 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
> A message occurs already: "Illegal instruction". But this is not
> really a help.
So LD_PRELOAD a library that handles it
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?
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
> 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
Followup to: <[email protected]>
By author: Andi Kleen <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
> 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
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
[email protected] \ / 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."
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 <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
"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
> 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.
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
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.
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.
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.
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
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.
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
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 /\/\
\/\/ [email protected] \/\/ ------------------ \/\/
/\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\
\/\/ GnuPG/PGP key available \/\/ administration \/\/
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: [email protected], PGP key available +
[email protected] 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
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
Followup to: <[email protected]>
By author: Pavel Machek <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>