Petko Manolov wrote:
> > You'd still want string-486.h to _call_ the larger routines in
> > string-486.c, using FASTCALL or your choice of alternate registers.
>
> I am not very sure if Linus will like the idea.
There is precedent: arch/i386/mmx.c.
I expect he'd prefer it over inlining unrolled
Jamie Lokier wrote:
>
> Petko Manolov wrote:
> > I don't see the point of string-486.c - string-486.h is a replacement
> > of string.h for i[45]86 machines so let stay in include directory.
>
> The point is it may run faster due to better i-cache usage. Remember
> also that 486 machines don't h
Petko Manolov wrote:
> I don't see the point of string-486.c - string-486.h is a replacement
> of string.h for i[45]86 machines so let stay in include directory.
The point is it may run faster due to better i-cache usage. Remember
also that 486 machines don't have much memory, so the gain from r
Jamie Lokier wrote:
>
> Alan Cox wrote:
> > > Alan, can you send me again the list of CPUs you think
> > > is worth using 486 string routines.
> > > Sorry, i lost your previous mail.
> >
> > I suspect it is
> >
> > 486
> > K5
> > IDT Winchip
> > Rise
> > NexGen
>
>
Alan Cox wrote:
> > Alan, can you send me again the list of CPUs you think
> > is worth using 486 string routines.
> > Sorry, i lost your previous mail.
>
> I suspect it is
>
> 486
> K5
> IDT Winchip
> Rise
> NexGen
Take a look at
http://now.cs.berkeley.edu/Td/b
> Alan, can you send me again the list of CPUs you think
> is worth using 486 string routines.
> Sorry, i lost your previous mail.
I suspect it is
486
K5
IDT Winchip
Rise
NexGen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
"Richard B. Johnson" wrote:
>
> > I think patch like this is not safe for 2.4.X-pre.
> >
>
> Not safe only in that there is so much stuff changed all at once
> that it'd be a good idea not to change anything that doesn't have to
> be changed. I agree.
Actually there are no so many changes.
Pavel Machek wrote:
>
> > If your patch doesn't hurt anything, even if it only adds marginal
> > performance, I'm pretty sure that Linus will accept it.
>
> I think patch like this is not safe for 2.4.X-pre.
Not necessary. These routines are quite simple so a 1 week period
spend in heavy tests
Alan Cox wrote:
>
> > However, in 2.5.0 we should apply it, and force it on *all* cpus just
> > to test it well. Then in 2.5.10 we should turn it off for
> > pentium/MMX+.
>
> Even original pentium has hardware optimised rep movs fast paths. Its just
> a few cpus they disable it via undocumented
On Fri, 1 Sep 2000, Pavel Machek wrote:
> Hi!
>
> > > > On Thu, 31 Aug 2000, Petko Manolov wrote:
> > > >
> > > > [Snipped...]
> > > >
> > > > Good. You understand. Keep up the good work.
> > >
> > >
> > > I realy would like to see this code in use ;-)
> >
> > After you test it **THOUROUGHL
> However, in 2.5.0 we should apply it, and force it on *all* cpus just
> to test it well. Then in 2.5.10 we should turn it off for
> pentium/MMX+.
Even original pentium has hardware optimised rep movs fast paths. Its just
a few cpus they disable it via undocumented magic (ditto it seems a couple
Hi!
> > > On Thu, 31 Aug 2000, Petko Manolov wrote:
> > >
> > > [Snipped...]
> > >
> > > Good. You understand. Keep up the good work.
> >
> >
> > I realy would like to see this code in use ;-)
>
> After you test it **THOUROUGHLY**, send a patch to Linus. I
> recommend testing it in a user-mo
"Richard B. Johnson" wrote:
>
> On Thu, 31 Aug 2000, Petko Manolov wrote:
>
> > I realy would like to see this code in use ;-)
>
> After you test it **THOUROUGHLY**, send a patch to Linus. I
> recommend testing it in a user-mode program with all kinds of
> sizes/shapes/lengths/offsets, etc., an
On Thu, 31 Aug 2000, Petko Manolov wrote:
> "Richard B. Johnson" wrote:
> >
> > On Thu, 31 Aug 2000, Petko Manolov wrote:
> >
> > [Snipped...]
> >
> > Good. You understand. Keep up the good work.
>
>
> I realy would like to see this code in use ;-)
After you test it **THOUROUGHLY**, send a
Alan Cox wrote:
>
> > This will be a speedup for 486 and older 586. I don't have
> > Intel's optimization manual for 586s handy so i can't argue.
> > But looking at linux/arch/i386/config.in shows that 486
> > strings (CONFIG_X86_USE_STRING_486) are preferred for 486,
> > 586, 586 with TSC and 58
> This will be a speedup for 486 and older 586. I don't have
> Intel's optimization manual for 586s handy so i can't argue.
> But looking at linux/arch/i386/config.in shows that 486
> strings (CONFIG_X86_USE_STRING_486) are preferred for 486,
> 586, 586 with TSC and 586 MMX.
Which according to my
"Richard B. Johnson" wrote:
>
> On Thu, 31 Aug 2000, Petko Manolov wrote:
>
> [Snipped...]
>
> Good. You understand. Keep up the good work.
I realy would like to see this code in use ;-)
best,
Petkan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Thu, 31 Aug 2000, Petko Manolov wrote:
[Snipped...]
Good. You understand. Keep up the good work.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you r
"Richard B. Johnson" wrote:
>
> With intel processors, the 'rep' before an instruction will not
> execute that instruction if ecx is already zero. You do not
> have to test. Also, a jump is often much more harmful in instruction
> time than straight-through instruction. For instance, the fastest
On Thu, 31 Aug 2000, Petko Manolov wrote:
> Hi to all,
>
> I made this patch as some people request using
> 486 optimized string routines for older
> (486 and 586) machines.
>
With intel processors, the 'rep' before an instruction will not
execute that instruction if ecx is already zero.
Alan Cox wrote:
>
> > I made this patch as some people request using
> > 486 optimized string routines for older
> > (486 and 586) machines.
>
> I would be suprised if its a win for intel pentium cpus since almost all of them
> have hardware rep movs paths (except 100Mhz B step and a few oddment
> I made this patch as some people request using
> 486 optimized string routines for older
> (486 and 586) machines.
I would be suprised if its a win for intel pentium cpus since almost all of them
have hardware rep movs paths (except 100Mhz B step and a few oddments)
-
To unsubscribe from this l
Hi to all,
I made this patch as some people request using
486 optimized string routines for older
(486 and 586) machines.
Actually i made 2 things:
- replaced buggy macro definitions for
memset and memcpy which caused compiler
break. Also paranoia check added for
23 matches
Mail list logo
