Re: svn commit: r314669 - head/sys/i386/conf

[Konstantin Belousov]

On Sun, Mar 05, 2017 at 03:40:45PM +0100, Jilles Tjoelker wrote:
> On Sun, Mar 05, 2017 at 11:35:26AM +1100, Bruce Evans wrote:
> > On Sun, 5 Mar 2017, Konstantin Belousov wrote:
> 
> > > On Sat, Mar 04, 2017 at 02:54:56PM -0800, John Baldwin wrote:
> > >> On Saturday, March 04, 2017 11:16:11 PM Konstantin Belousov wrote:
> > >>> On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:
> >  The number came out from an old posting involving buildworld times, 
> >  which I can???t find now :(.
> >  Things seem to have changed a lot: it was surely using GCC back then, 
> >  I don???t believe clang does much distinction about 486 at all.
> > 
> >  BTW, does it make sense to keep i586 in the configuration still? Both 
> >  i486 and i586 were once removed but later re-instated in r205336.
> > 
> > >>> What did make significant impact on 32bit shared libraries some time ago
> > >>> was to compile them with -mtune=i686. Default PIC prologue effectively
> > >>> neutered return stack predictor, adding uneccessary overhead to already
> > >>> expensive PIC code. I think that this is even measureable, i.e. it might
> > >>> give >= 5% of difference.
> 
> > I now use -mtune=athlon-xp (and no other -m CFLAGS) to get the same effect
> > with minor additional optimizations/pessimizations for athlon-xp.  I forget
> > if I switched to this before or after getting jhb to not use
> > -mtune=pentiumpro.  Maybe we didn't know at the time that the pentiumpro
> > optimizations affected little more than this PIC problem.
> 
> > >>> I did not rechecked modern compilers WRT the generated PIC code,
> > >>> but I doubt that the thing changed recently.
> 
> > >>> Several notes: -mtune is not -march, i.e. the code would be still 
> > >>> targeted
> > >>> for 486 instruction set, but scheduling is optimized for more modern 
> > >>> CPUs.
> > >>> Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
> > >>> as request for scheduling for generic modern CPUs.  We already compile
> > >>> 32bit compat libs on amd64 with -march=i686.
> 
> > >>> Working on this stuff would be much more useful than tweaking
> > >>> kernel config for CPU detection.
> 
> > >> Hmm, I originally wanted to use -mtune=i686 (spelled as
> > >> -mcpu=pentiumpro) on i386 builds for this reason, but I removed it
> > >> at bde@'s request in r125252. I would be happy to go back to adding
> > >> -mtune for i386 when CPUTYPE isn't specified.
> 
> > > I just rechecked.
> > > gcc, at least 4.9 and 6.3, generate 'right' prologue, i.e.
> > >   call__x86.get_pc_thunk.cx (ecx or whatever register
> > >   which is used to address GOT)
> > > __x86.get_pc_thunk.cx:
> > >   movl(%esp), %ecx
> > >   ret
> > > even when compiling for -march=i486.
> 
> > > OTOH, clang 3.9.1 uses
> > >   calll   .L0
> > > .L0:  popl%eax
> > > to get the base even for native nehalem and newer CPUs.
> 
> > > So indeed there is no reason to bother. gcc become too good to require any
> > > tuning, and clang generates unoptimal code even when hinted.  I did not
> > > checked 4.0.
> 
> > The old method might actually be best for the original i386.  It is
> > 1 byte larger per call, but 1 instruction shorter by dynamic count.
> > Original i386 has poor instruction fetch bandwidth and no caches and
> > to help or harm.  Even the (%esp) address mode can cost a cycle on 
> > original i386, and setting up a frame pointer to access the stack would
> > be much worse, while on modern x86 the frame pointer might cost nothing
> > since it can be done in parallel.
> 
> > Maybe some newer CPUs have better return address predictors so the old
> > method is best for them too.
> 
> > It is only clear that generic optimizations should use the new method,
> > since CPU manufacturers won't pessimize it since it looks like a normal
> > function call.
> 
> I tried a naive benchmark of a million iterations on a
> 
> CPU: Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz (2993.26-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
> 
> and a subroutine containing the old method is almost as fast as an empty
> subroutine (3.8ns including loop overhead), while a subroutine
> containing the new method is slower (6.3 ns including loop overhead).
> Apparently this CPU knows that a call to the next instruction will not
> be returned to.
Or the branch predictor learned that return happens to the same address
always and stack pointer tracking logic was shut down. Of course, this
is a speculation, we will never know.

> 
> Likewise, the old method is faster on a
> 
> hw.model: Intel(R) Xeon(R) CPU   X5675  @ 3.07GHz
> 
> On the other hand, the old method is slower on an old
> 
> hw.model: Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz
> 
> Apparently, LLVM has decided to trade considerably worse performance on
> CPUs such as Core2 for better performance on newer and older CPUs. What
> is somewhat 

Re: svn commit: r314669 - head/sys/i386/conf

[Pedro Giffuni]

> Il giorno 05 mar 2017, alle ore 18:24, John Baldwin  ha 
> scritto:
> 
> On Saturday, March 04, 2017 08:14:11 PM Pedro Giffuni wrote:
>> 
>> On 3/4/2017 5:51 PM, John Baldwin wrote:
>>> On Saturday, March 04, 2017 03:49:52 PM Pedro Giffuni wrote:
> Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  ha 
> scritto:
> 
> On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
>> On 03/04/17 10:32, Slawa Olhovchenkov wrote:
>>> On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
>>> 
 Author: pfg
 Date: Sat Mar  4 15:04:17 2017
 New Revision: 314669
 URL: https://svnweb.freebsd.org/changeset/base/314669
 
 Log:
  Drop i486 from the default i386 GENERIC kernel configuration.
 
  80486 production was stopped by Intel on September 2007. Dropping the 
 486
  configuration option from the GENERIC kernel improves performance
  slightly.
 
  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved 
 i486
  CPUs, is also gone so we don't test such platforms anymore.
>>> What is realy mean?
>> This means we don't do work-arounds that would be required for raw 486.
>> Instead we will use the 586 instructions by default.
> This doesn't change that.  The kernel already has runtime tests in place
> for new things on 486 and later via cpuid.
> 
 Hmm ..then I am wondering if I effectively changed anything?
>>> The only change is a 486 now panics on boot when it used to work fine. :-/
>>> 
>>> Nothing for other CPUs has changed.
>> 
>> Not much has been lost then.
>> FWIW, I have a "Pentium overdrive" somewhere in the basement which could 
>> theoretically boot FreeBSD 12 but last I remember just rebuilding a 
>> kernel was painful and the memory and HD limitations really make it a no-go.
> 
> So I would rather support 486 in GENERIC or not support it at all.  It doesn't
> cost anything for it to be in GENERIC, so if we have it, I think we should 
> ship
> it.  Also, the original justification for this commit of a 4% performance gain
> doesn't seem to have any basis in fact.  The one gain I can think of is
> de-cluttering some things like identcpu.c and initcpu.c which can only happen 
> if
> we remove code entirely, not from removing an option in GENERIC.
> 

OK, that’s reasonable. I will revert the change.

Pedro.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Saturday, March 04, 2017 08:14:11 PM Pedro Giffuni wrote:
> 
> On 3/4/2017 5:51 PM, John Baldwin wrote:
> > On Saturday, March 04, 2017 03:49:52 PM Pedro Giffuni wrote:
> >>> Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  ha 
> >>> scritto:
> >>>
> >>> On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
>  On 03/04/17 10:32, Slawa Olhovchenkov wrote:
> > On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
> >
> >> Author: pfg
> >> Date: Sat Mar  4 15:04:17 2017
> >> New Revision: 314669
> >> URL: https://svnweb.freebsd.org/changeset/base/314669
> >>
> >> Log:
> >>   Drop i486 from the default i386 GENERIC kernel configuration.
> >>
> >>   80486 production was stopped by Intel on September 2007. Dropping 
> >> the 486
> >>   configuration option from the GENERIC kernel improves performance
> >>   slightly.
> >>
> >>   Removing I486_CPU is consistent at this time: we don't support any
> >>   processor without a FPU and the PC-98 arch, which frequently 
> >> involved i486
> >>   CPUs, is also gone so we don't test such platforms anymore.
> > What is realy mean?
>  This means we don't do work-arounds that would be required for raw 486.
>  Instead we will use the 586 instructions by default.
> >>> This doesn't change that.  The kernel already has runtime tests in place
> >>> for new things on 486 and later via cpuid.
> >>>
> >> Hmm ..then I am wondering if I effectively changed anything?
> > The only change is a 486 now panics on boot when it used to work fine. :-/
> >
> > Nothing for other CPUs has changed.
> 
> Not much has been lost then.
> FWIW, I have a "Pentium overdrive" somewhere in the basement which could 
> theoretically boot FreeBSD 12 but last I remember just rebuilding a 
> kernel was painful and the memory and HD limitations really make it a no-go.

So I would rather support 486 in GENERIC or not support it at all.  It doesn't
cost anything for it to be in GENERIC, so if we have it, I think we should ship
it.  Also, the original justification for this commit of a 4% performance gain
doesn't seem to have any basis in fact.  The one gain I can think of is
de-cluttering some things like identcpu.c and initcpu.c which can only happen if
we remove code entirely, not from removing an option in GENERIC.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Jilles Tjoelker]

On Sun, Mar 05, 2017 at 11:35:26AM +1100, Bruce Evans wrote:
> On Sun, 5 Mar 2017, Konstantin Belousov wrote:

> > On Sat, Mar 04, 2017 at 02:54:56PM -0800, John Baldwin wrote:
> >> On Saturday, March 04, 2017 11:16:11 PM Konstantin Belousov wrote:
> >>> On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:
>  The number came out from an old posting involving buildworld times, 
>  which I can???t find now :(.
>  Things seem to have changed a lot: it was surely using GCC back then, I 
>  don???t believe clang does much distinction about 486 at all.
> 
>  BTW, does it make sense to keep i586 in the configuration still? Both 
>  i486 and i586 were once removed but later re-instated in r205336.
> 
> >>> What did make significant impact on 32bit shared libraries some time ago
> >>> was to compile them with -mtune=i686. Default PIC prologue effectively
> >>> neutered return stack predictor, adding uneccessary overhead to already
> >>> expensive PIC code. I think that this is even measureable, i.e. it might
> >>> give >= 5% of difference.

> I now use -mtune=athlon-xp (and no other -m CFLAGS) to get the same effect
> with minor additional optimizations/pessimizations for athlon-xp.  I forget
> if I switched to this before or after getting jhb to not use
> -mtune=pentiumpro.  Maybe we didn't know at the time that the pentiumpro
> optimizations affected little more than this PIC problem.

> >>> I did not rechecked modern compilers WRT the generated PIC code,
> >>> but I doubt that the thing changed recently.

> >>> Several notes: -mtune is not -march, i.e. the code would be still targeted
> >>> for 486 instruction set, but scheduling is optimized for more modern CPUs.
> >>> Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
> >>> as request for scheduling for generic modern CPUs.  We already compile
> >>> 32bit compat libs on amd64 with -march=i686.

> >>> Working on this stuff would be much more useful than tweaking
> >>> kernel config for CPU detection.

> >> Hmm, I originally wanted to use -mtune=i686 (spelled as
> >> -mcpu=pentiumpro) on i386 builds for this reason, but I removed it
> >> at bde@'s request in r125252. I would be happy to go back to adding
> >> -mtune for i386 when CPUTYPE isn't specified.

> > I just rechecked.
> > gcc, at least 4.9 and 6.3, generate 'right' prologue, i.e.
> > call__x86.get_pc_thunk.cx (ecx or whatever register
> > which is used to address GOT)
> > __x86.get_pc_thunk.cx:
> > movl(%esp), %ecx
> > ret
> > even when compiling for -march=i486.

> > OTOH, clang 3.9.1 uses
> > calll   .L0
> > .L0:popl%eax
> > to get the base even for native nehalem and newer CPUs.

> > So indeed there is no reason to bother. gcc become too good to require any
> > tuning, and clang generates unoptimal code even when hinted.  I did not
> > checked 4.0.

> The old method might actually be best for the original i386.  It is
> 1 byte larger per call, but 1 instruction shorter by dynamic count.
> Original i386 has poor instruction fetch bandwidth and no caches and
> to help or harm.  Even the (%esp) address mode can cost a cycle on 
> original i386, and setting up a frame pointer to access the stack would
> be much worse, while on modern x86 the frame pointer might cost nothing
> since it can be done in parallel.

> Maybe some newer CPUs have better return address predictors so the old
> method is best for them too.

> It is only clear that generic optimizations should use the new method,
> since CPU manufacturers won't pessimize it since it looks like a normal
> function call.

I tried a naive benchmark of a million iterations on a

CPU: Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz (2993.26-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9

and a subroutine containing the old method is almost as fast as an empty
subroutine (3.8ns including loop overhead), while a subroutine
containing the new method is slower (6.3 ns including loop overhead).
Apparently this CPU knows that a call to the next instruction will not
be returned to.

Likewise, the old method is faster on a

hw.model: Intel(R) Xeon(R) CPU   X5675  @ 3.07GHz

On the other hand, the old method is slower on an old

hw.model: Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz

Apparently, LLVM has decided to trade considerably worse performance on
CPUs such as Core2 for better performance on newer and older CPUs. What
is somewhat surprising is that there is no way to use the GCC method.
Then again, LLVM does not support bypassing the PLT either (loading the
address from the GOT directly).

Given that the old method is quite commonly used, it does not seem very
likely that CPU manufacturers will pessimize it in future.

-- 
Jilles Tjoelker
___
svn-src-head@freebsd.org mailing list

Re: svn commit: r314669 - head/sys/i386/conf

[Pedro Giffuni]

On 3/4/2017 5:51 PM, John Baldwin wrote:

On Saturday, March 04, 2017 03:49:52 PM Pedro Giffuni wrote:

Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  ha 
scritto:

On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:

On 03/04/17 10:32, Slawa Olhovchenkov wrote:

On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:


Author: pfg
Date: Sat Mar  4 15:04:17 2017
New Revision: 314669
URL: https://svnweb.freebsd.org/changeset/base/314669

Log:
  Drop i486 from the default i386 GENERIC kernel configuration.

  80486 production was stopped by Intel on September 2007. Dropping the 486
  configuration option from the GENERIC kernel improves performance
  slightly.

  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved i486
  CPUs, is also gone so we don't test such platforms anymore.

What is realy mean?

This means we don't do work-arounds that would be required for raw 486.
Instead we will use the 586 instructions by default.

This doesn't change that.  The kernel already has runtime tests in place
for new things on 486 and later via cpuid.


Hmm ..then I am wondering if I effectively changed anything?

The only change is a 486 now panics on boot when it used to work fine. :-/

Nothing for other CPUs has changed.


Not much has been lost then.
FWIW, I have a "Pentium overdrive" somewhere in the basement which could 
theoretically boot FreeBSD 12 but last I remember just rebuilding a 
kernel was painful and the memory and HD limitations really make it a no-go.


  

The number came out from an old posting involving buildworld times, which I 
can’t find now :(.
Things seem to have changed a lot: it was surely using GCC back then, I don’t 
believe clang does much distinction about 486 at all.

BTW, does it make sense to keep i586 in the configuration still? Both i486 and 
i586 were once removed but later re-instated in r205336.

If anything I'd probably say we should do what bde@ suggested and just
remove CPU class entirely (and act as if 486, 586, and 686 are always
defined).



In any case ... I won't MFC the change and if someone asks me to revert 
it I will (I'd love to see a dmesg first ;) ).


Pedro.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Bruce Evans]

On Sun, 5 Mar 2017, Konstantin Belousov wrote:


On Sat, Mar 04, 2017 at 02:54:56PM -0800, John Baldwin wrote:

On Saturday, March 04, 2017 11:16:11 PM Konstantin Belousov wrote:

On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:

The number came out from an old posting involving buildworld times, which I 
can???t find now :(.
Things seem to have changed a lot: it was surely using GCC back then, I don???t 
believe clang does much distinction about 486 at all.

BTW, does it make sense to keep i586 in the configuration still? Both i486 and 
i586 were once removed but later re-instated in r205336.


What did make significant impact on 32bit shared libraries some time ago
was to compile them with -mtune=i686. Default PIC prologue effectively
neutered return stack predictor, adding uneccessary overhead to already
expensive PIC code. I think that this is even measureable, i.e. it might
give >= 5% of difference.


I now use -mtune=athlon-xp (and no other -m CFLAGS) to get the same effect
with minor additional optimizations/pessimizations for athlon-xp.  I forget
if I switched to this before or after getting jhb to not use
-mtune=pentiumpro.  Maybe we didn't know at the time that the pentiumpro
optimizations affected little more than this PIC problem.


I did not rechecked modern compilers WRT the generated PIC code, but I doubt
that the thing changed recently.

Several notes: -mtune is not -march, i.e. the code would be still targeted
for 486 instruction set, but scheduling is optimized for more modern CPUs.
Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
as request for scheduling for generic modern CPUs.  We already compile
32bit compat libs on amd64 with -march=i686.

Working on this stuff would be much more useful than tweaking kernel config
for CPU detection.


Hmm, I originally wanted to use -mtune=i686 (spelled as -mcpu=pentiumpro) on
i386 builds for this reason, but I removed it at bde@'s request in r125252.
I would be happy to go back to adding -mtune for i386 when CPUTYPE isn't
specified.


I just rechecked.
gcc, at least 4.9 and 6.3, generate 'right' prologue, i.e.
call__x86.get_pc_thunk.cx (ecx or whatever register
which is used to address GOT)
__x86.get_pc_thunk.cx:
movl(%esp), %ecx
ret
even when compiling for -march=i486.

OTOH, clang 3.9.1 uses
calll   .L0
.L0:popl%eax
to get the base even for native nehalem and newer CPUs.

So indeed there is no reason to bother. gcc become too good to require any
tuning, and clang generates unoptimal code even when hinted.  I did not
checked 4.0.


The old method might actually be best for the original i386.  It is
1 byte larger per call, but 1 instruction shorter by dynamic count.
Original i386 has poor instruction fetch bandwidth and no caches and
to help or harm.  Even the (%esp) address mode can cost a cycle on 
original i386, and setting up a frame pointer to access the stack would

be much worse, while on modern x86 the frame pointer might cost nothing
since it can be done in parallel.

Maybe some newer CPUs have better return address predictors so the old
method is best for them too.

It is only clear that generic optimizations should use the new method,
since CPU manufacturers won't pessimize it since it looks like a normal
function call.

Bruce
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Konstantin Belousov]

On Sat, Mar 04, 2017 at 02:54:56PM -0800, John Baldwin wrote:
> On Saturday, March 04, 2017 11:16:11 PM Konstantin Belousov wrote:
> > On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:
> > > The number came out from an old posting involving buildworld times, which 
> > > I can???t find now :(.
> > > Things seem to have changed a lot: it was surely using GCC back then, I 
> > > don???t believe clang does much distinction about 486 at all.
> > > 
> > > BTW, does it make sense to keep i586 in the configuration still? Both 
> > > i486 and i586 were once removed but later re-instated in r205336.
> > > 
> > What did make significant impact on 32bit shared libraries some time ago
> > was to compile them with -mtune=i686. Default PIC prologue effectively
> > neutered return stack predictor, adding uneccessary overhead to already
> > expensive PIC code. I think that this is even measureable, i.e. it might
> > give >= 5% of difference.
> > 
> > I did not rechecked modern compilers WRT the generated PIC code, but I doubt
> > that the thing changed recently.
> > 
> > Several notes: -mtune is not -march, i.e. the code would be still targeted
> > for 486 instruction set, but scheduling is optimized for more modern CPUs.
> > Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
> > as request for scheduling for generic modern CPUs.  We already compile
> > 32bit compat libs on amd64 with -march=i686.
> > 
> > Working on this stuff would be much more useful than tweaking kernel config
> > for CPU detection.
> 
> Hmm, I originally wanted to use -mtune=i686 (spelled as -mcpu=pentiumpro) on
> i386 builds for this reason, but I removed it at bde@'s request in r125252.
> I would be happy to go back to adding -mtune for i386 when CPUTYPE isn't
> specified.

I just rechecked.
gcc, at least 4.9 and 6.3, generate 'right' prologue, i.e.
call__x86.get_pc_thunk.cx (ecx or whatever register
which is used to address GOT)
__x86.get_pc_thunk.cx:
movl(%esp), %ecx
ret
even when compiling for -march=i486.

OTOH, clang 3.9.1 uses
calll   .L0
.L0:popl%eax
to get the base even for native nehalem and newer CPUs.

So indeed there is no reason to bother. gcc become too good to require any
tuning, and clang generates unoptimal code even when hinted.  I did not
checked 4.0.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Sunday, March 05, 2017 09:13:05 AM Bruce Evans wrote:
> On Sat, 4 Mar 2017, John Baldwin wrote:
> I think all the removal does on a plain 486 is move a runtime test so that
> 486 CPUs no longer pass it, causing a panic for an "unsupported" CPU that
> would work except the panic, and prevent reaching a single 486 optimization.
> in bocpy().  The special support in initcpu() seems to be only to work
> around bugs in incompatible 486 variants.

The last time I looked at initcpu.c it wasn't clear how much of those old
workarounds were for CPUs we don't support that could just be axed.

> Fixes in this area should go the other way and remove the panics and the
> cpu class stuff to implement them.  The cpu class stuff used to mainly
> give panics for newer CPUs that are backwards compatible but unknown.
> Feature tests prevent that happening.  All new x86 are 686s with optional
> features.  Plain 486 should work if it were classified as a 686 without
> any features.

I recently removed cpu_class from amd64 entirely.  Removing it from i386
and just replying on cpu_feature* the way amd64 does would be fine with
me.  I'd probably remove all the I?86_CPU options in that case and just
compile them all in.

In regards to the TSC, that is one thing I've wondered if we should require
for i386 to avoid some runtime checks and simplify the i386 code.  There
were 486's with a TSC even.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Saturday, March 04, 2017 11:16:11 PM Konstantin Belousov wrote:
> On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:
> > The number came out from an old posting involving buildworld times, which I 
> > can???t find now :(.
> > Things seem to have changed a lot: it was surely using GCC back then, I 
> > don???t believe clang does much distinction about 486 at all.
> > 
> > BTW, does it make sense to keep i586 in the configuration still? Both i486 
> > and i586 were once removed but later re-instated in r205336.
> > 
> What did make significant impact on 32bit shared libraries some time ago
> was to compile them with -mtune=i686. Default PIC prologue effectively
> neutered return stack predictor, adding uneccessary overhead to already
> expensive PIC code. I think that this is even measureable, i.e. it might
> give >= 5% of difference.
> 
> I did not rechecked modern compilers WRT the generated PIC code, but I doubt
> that the thing changed recently.
> 
> Several notes: -mtune is not -march, i.e. the code would be still targeted
> for 486 instruction set, but scheduling is optimized for more modern CPUs.
> Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
> as request for scheduling for generic modern CPUs.  We already compile
> 32bit compat libs on amd64 with -march=i686.
> 
> Working on this stuff would be much more useful than tweaking kernel config
> for CPU detection.

Hmm, I originally wanted to use -mtune=i686 (spelled as -mcpu=pentiumpro) on
i386 builds for this reason, but I removed it at bde@'s request in r125252.
I would be happy to go back to adding -mtune for i386 when CPUTYPE isn't
specified.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Saturday, March 04, 2017 03:49:52 PM Pedro Giffuni wrote:
> 
> > Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  ha 
> > scritto:
> > 
> > On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
> >> 
> >> On 03/04/17 10:32, Slawa Olhovchenkov wrote:
> >>> On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
> >>> 
>  Author: pfg
>  Date: Sat Mar  4 15:04:17 2017
>  New Revision: 314669
>  URL: https://svnweb.freebsd.org/changeset/base/314669
>  
>  Log:
>   Drop i486 from the default i386 GENERIC kernel configuration.
>  
>   80486 production was stopped by Intel on September 2007. Dropping the 
>  486
>   configuration option from the GENERIC kernel improves performance
>   slightly.
>  
>   Removing I486_CPU is consistent at this time: we don't support any
>   processor without a FPU and the PC-98 arch, which frequently involved 
>  i486
>   CPUs, is also gone so we don't test such platforms anymore.
> >>> 
> >>> What is realy mean?
> >> 
> >> This means we don't do work-arounds that would be required for raw 486.
> >> Instead we will use the 586 instructions by default.
> > 
> > This doesn't change that.  The kernel already has runtime tests in place
> > for new things on 486 and later via cpuid.
> > 
> 
> Hmm ..then I am wondering if I effectively changed anything?

The only change is a 486 now panics on boot when it used to work fine. :-/

Nothing for other CPUs has changed.
 
> The number came out from an old posting involving buildworld times, which I 
> can’t find now :(.
> Things seem to have changed a lot: it was surely using GCC back then, I don’t 
> believe clang does much distinction about 486 at all.
> 
> BTW, does it make sense to keep i586 in the configuration still? Both i486 
> and i586 were once removed but later re-instated in r205336.

If anything I'd probably say we should do what bde@ suggested and just
remove CPU class entirely (and act as if 486, 586, and 686 are always
defined).

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Bruce Evans]

On Sat, 4 Mar 2017, John Baldwin wrote:


On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:


On 03/04/17 10:32, Slawa Olhovchenkov wrote:

On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:


Author: pfg
Date: Sat Mar  4 15:04:17 2017
New Revision: 314669
URL: https://svnweb.freebsd.org/changeset/base/314669

Log:
  Drop i486 from the default i386 GENERIC kernel configuration.

  80486 production was stopped by Intel on September 2007. Dropping the 486
  configuration option from the GENERIC kernel improves performance
  slightly.

  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved i486
  CPUs, is also gone so we don't test such platforms anymore.


What is realy mean?


It means that GENERIC is less generic.


This means we don't do work-arounds that would be required for raw 486.
Instead we will use the 586 instructions by default.


This doesn't change that.  The kernel already has runtime tests in place
for new things on 486 and later via cpuid.


I486_CPU also used to control optimization of get_cyclecount(), by
removing the dynamic test for a TSC if I486_CPU and some other options
are _not_ configured.  Now the optimization is never done, but a larger
pessimization is always done:

get_cyclecount():
- amd64 and old i386 without I486_CPU and some others: return inlined rdtsc().
- old i386 with I486_CPU or some others: test inline for a TSC; then if not
  an old CPU, return inline rdtsc(); else call binuptime() and do bad
  swizzling
- current i386: always call a function through a function pointer; if not an
  old CPU, this points to non-inline rdtsc(); otherwise, usually call
  binuptime() and do differently bad swizzling to partially support abuse
  of get_cyclecount() as a monotonic timestamp.

get_cyclecount() was changed to use cpu_ticks() in 2011 (r220347).

cddl has over-engineered direct use of the TSC for timestamps because native
APIs are under-engineered, but important native places like ktr still abuse
get_cyclecount().

get_cyclecount() is mis-engineered on most arches:
- arm: on newer CPUs with pmu, it uses large inline code with many function
  calls that might be inlined; on newer CPUs without pmu, it uses 1 function
  call that might be inlined; on older CPUs, it calls binuptime() and does
  differently again bad swizzling
- arm64: like amd64 (?)
- mips: like amd64 (?), except get_cyclecount() is a macro instead of an
  inline function.  The register for this is apparently not good enough
  for the cpu ticker and thus not good enough for abusing for monotonic
  timestamps.  The register is apparently only 32 bits.  The cpu ticker
  function counts wrap-arounds to maintain 32 more top bits.
- powerpc: like amd64, except the 64-bit result is assembled from 2 32-bit
  registers.  This looks like it has races on rollover, and correct code
  would look like mips: return only 32 bits in get_cyclecount(), and try
  to avoid rollover in the cpu ticker.  powerpc does this backwards: it
  returns 64 bits with races in get_cyclecount(), but returns only 32
  bits without races for the cpu ticker.  The races are not too bad
  because using get_cyclecount() is a monotonic timestamp is abuse.
  Differently bad swizzling breaks monotonicity differently badly too.
- riscv: stub that always returns 1.  That is really differently bad.
  This should at least copy the generic i386 implementation.  riscv
  doesn't set a special cpu ticker either.  It gets the default one
  which is a timecounter, just like on i386 without a TSC.  Thus might
  be a stub too, but then more things would break so it would get fixed.
- sparc64: like amd64 (?).

I486_CPU also used to give an optimized bzero() for i486.  That cost a
branch and/or call through a function point for newer CPUs.  This was
removed in 2010 (r209460).


Some Via CPU is like i486 (by instruction set).

CPU: VIA Ezra (800.04-MHz 686-class CPU)
  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
  Features=0x803035
  AMD Features=0x8000<3DNow!>



486 never had MMX extensions.
This is a 686, performance should improve ~4%.


How did you measure the improvement?  Keeping I486_CPU doesn't really
do anything except remove a some #ifdef'd conditionals in identcpu.c
and initcpu.c.  It doesn't affect whether we use the TSC, MMX, etc.  Those
are all runtime checks based the CPU feature flags from cpuid.


The old optimization might be worth as much as 0.004%.

I think all the removal does on a plain 486 is move a runtime test so that
486 CPUs no longer pass it, causing a panic for an "unsupported" CPU that
would work except the panic, and prevent reaching a single 486 optimization.
in bocpy().  The special support in initcpu() seems to be only to work
around bugs in incompatible 486 variants.

Fixes in this area should go the other way and remove the panics and the
cpu class stuff to implement 

Re: svn commit: r314669 - head/sys/i386/conf

[Konstantin Belousov]

On Sat, Mar 04, 2017 at 03:49:52PM -0500, Pedro Giffuni wrote:
> 
> > Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  ha 
> > scritto:
> > 
> > On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
> >> 
> >> On 03/04/17 10:32, Slawa Olhovchenkov wrote:
> >>> On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
> >>> 
>  Author: pfg
>  Date: Sat Mar  4 15:04:17 2017
>  New Revision: 314669
>  URL: https://svnweb.freebsd.org/changeset/base/314669
>  
>  Log:
>   Drop i486 from the default i386 GENERIC kernel configuration.
>  
>   80486 production was stopped by Intel on September 2007. Dropping the 
>  486
>   configuration option from the GENERIC kernel improves performance
>   slightly.
>  
>   Removing I486_CPU is consistent at this time: we don't support any
>   processor without a FPU and the PC-98 arch, which frequently involved 
>  i486
>   CPUs, is also gone so we don't test such platforms anymore.
> >>> 
> >>> What is realy mean?
> >> 
> >> This means we don't do work-arounds that would be required for raw 486.
> >> Instead we will use the 586 instructions by default.
> > 
> > This doesn't change that.  The kernel already has runtime tests in place
> > for new things on 486 and later via cpuid.
> > 
> 
> Hmm ..then I am wondering if I effectively changed anything?
> 
> >>> Some Via CPU is like i486 (by instruction set).
> >>> 
> >>> CPU: VIA Ezra (800.04-MHz 686-class CPU)
> >>>  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
> >>>  Features=0x803035
> >>>  AMD Features=0x8000<3DNow!>
> >>> 
> >> 
> >> 486 never had MMX extensions.
> >> This is a 686, performance should improve ~4%.
> > 
> > How did you measure the improvement?  Keeping I486_CPU doesn't really
> > do anything except remove a some #ifdef'd conditionals in identcpu.c
> > and initcpu.c.  It doesn't affect whether we use the TSC, MMX, etc.  Those
> > are all runtime checks based the CPU feature flags from cpuid.
> > 
> 
> The number came out from an old posting involving buildworld times, which I 
> can???t find now :(.
> Things seem to have changed a lot: it was surely using GCC back then, I 
> don???t believe clang does much distinction about 486 at all.
> 
> BTW, does it make sense to keep i586 in the configuration still? Both i486 
> and i586 were once removed but later re-instated in r205336.
> 
What did make significant impact on 32bit shared libraries some time ago
was to compile them with -mtune=i686. Default PIC prologue effectively
neutered return stack predictor, adding uneccessary overhead to already
expensive PIC code. I think that this is even measureable, i.e. it might
give >= 5% of difference.

I did not rechecked modern compilers WRT the generated PIC code, but I doubt
that the thing changed recently.

Several notes: -mtune is not -march, i.e. the code would be still targeted
for 486 instruction set, but scheduling is optimized for more modern CPUs.
Also, recent gcc puts specific meaning into -mtune=i686, interpreting it
as request for scheduling for generic modern CPUs.  We already compile
32bit compat libs on amd64 with -march=i686.

Working on this stuff would be much more useful than tweaking kernel config
for CPU detection.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Ian Lepore]

On Sat, 2017-03-04 at 15:49 -0500, Pedro Giffuni wrote:
> > 
> > Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  > g> ha scritto:
> > 
> > On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
> > > 
> > > 
> > > On 03/04/17 10:32, Slawa Olhovchenkov wrote:
> > > > 
> > > > On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni
> > > > wrote:
> > > > 
> > > > > 
> > > > > Author: pfg
> > > > > Date: Sat Mar  4 15:04:17 2017
> > > > > New Revision: 314669
> > > > > URL: https://svnweb.freebsd.org/changeset/base/314669
> > > > > 
> > > > > Log:
> > > > >  Drop i486 from the default i386 GENERIC kernel
> > > > > configuration.
> > > > > 
> > > > >  80486 production was stopped by Intel on September 2007.
> > > > > Dropping the 486
> > > > >  configuration option from the GENERIC kernel improves
> > > > > performance
> > > > >  slightly.
> > > > > 
> > > > >  Removing I486_CPU is consistent at this time: we don't
> > > > > support any
> > > > >  processor without a FPU and the PC-98 arch, which frequently
> > > > > involved i486
> > > > >  CPUs, is also gone so we don't test such platforms anymore.
> > > > What is realy mean?
> > > This means we don't do work-arounds that would be required for
> > > raw 486.
> > > Instead we will use the 586 instructions by default.
> > This doesn't change that.  The kernel already has runtime tests in
> > place
> > for new things on 486 and later via cpuid.
> > 
> Hmm ..then I am wondering if I effectively changed anything?
> 
> > 
> > > 
> > > > 
> > > > Some Via CPU is like i486 (by instruction set).
> > > > 
> > > > CPU: VIA Ezra (800.04-MHz 686-class CPU)
> > > >  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Steppi
> > > > ng=8
> > > >  Features=0x803035
> > > >  AMD Features=0x8000<3DNow!>
> > > > 
> > > 486 never had MMX extensions.
> > > This is a 686, performance should improve ~4%.
> > How did you measure the improvement?  Keeping I486_CPU doesn't
> > really
> > do anything except remove a some #ifdef'd conditionals in
> > identcpu.c
> > and initcpu.c.  It doesn't affect whether we use the TSC, MMX,
> > etc.  Those
> > are all runtime checks based the CPU feature flags from cpuid.
> > 
> The number came out from an old posting involving buildworld times,
> which I can’t find now :(.
> Things seem to have changed a lot: it was surely using GCC back then,
> I don’t believe clang does much distinction about 486 at all.
> 
> BTW, does it make sense to keep i586 in the configuration still? Both
> i486 and i586 were once removed but later re-instated in r205336.
> 
> Pedro.

i586 hardware which is not also i686 is still alive and well, but I
think at this point it's mostly used in specialized applications.  I
have no problem with removing i586 from GENERIC, but please don't
remove underlying support for setting it in custom kernel configs.

-- Ian

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Pedro Giffuni]

> Il giorno 04 mar 2017, alle ore 14:43, John Baldwin  ha 
> scritto:
> 
> On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
>> 
>> On 03/04/17 10:32, Slawa Olhovchenkov wrote:
>>> On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
>>> 
 Author: pfg
 Date: Sat Mar  4 15:04:17 2017
 New Revision: 314669
 URL: https://svnweb.freebsd.org/changeset/base/314669
 
 Log:
  Drop i486 from the default i386 GENERIC kernel configuration.
 
  80486 production was stopped by Intel on September 2007. Dropping the 486
  configuration option from the GENERIC kernel improves performance
  slightly.
 
  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved i486
  CPUs, is also gone so we don't test such platforms anymore.
>>> 
>>> What is realy mean?
>> 
>> This means we don't do work-arounds that would be required for raw 486.
>> Instead we will use the 586 instructions by default.
> 
> This doesn't change that.  The kernel already has runtime tests in place
> for new things on 486 and later via cpuid.
> 

Hmm ..then I am wondering if I effectively changed anything?

>>> Some Via CPU is like i486 (by instruction set).
>>> 
>>> CPU: VIA Ezra (800.04-MHz 686-class CPU)
>>>  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
>>>  Features=0x803035
>>>  AMD Features=0x8000<3DNow!>
>>> 
>> 
>> 486 never had MMX extensions.
>> This is a 686, performance should improve ~4%.
> 
> How did you measure the improvement?  Keeping I486_CPU doesn't really
> do anything except remove a some #ifdef'd conditionals in identcpu.c
> and initcpu.c.  It doesn't affect whether we use the TSC, MMX, etc.  Those
> are all runtime checks based the CPU feature flags from cpuid.
> 

The number came out from an old posting involving buildworld times, which I 
can’t find now :(.
Things seem to have changed a lot: it was surely using GCC back then, I don’t 
believe clang does much distinction about 486 at all.

BTW, does it make sense to keep i586 in the configuration still? Both i486 and 
i586 were once removed but later re-instated in r205336.

Pedro.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[John Baldwin]

On Saturday, March 04, 2017 10:52:46 AM Pedro Giffuni wrote:
> 
> On 03/04/17 10:32, Slawa Olhovchenkov wrote:
> > On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
> >
> >> Author: pfg
> >> Date: Sat Mar  4 15:04:17 2017
> >> New Revision: 314669
> >> URL: https://svnweb.freebsd.org/changeset/base/314669
> >>
> >> Log:
> >>   Drop i486 from the default i386 GENERIC kernel configuration.
> >>
> >>   80486 production was stopped by Intel on September 2007. Dropping the 486
> >>   configuration option from the GENERIC kernel improves performance
> >>   slightly.
> >>
> >>   Removing I486_CPU is consistent at this time: we don't support any
> >>   processor without a FPU and the PC-98 arch, which frequently involved 
> >> i486
> >>   CPUs, is also gone so we don't test such platforms anymore.
> >
> > What is realy mean?
> 
> This means we don't do work-arounds that would be required for raw 486.
> Instead we will use the 586 instructions by default.

This doesn't change that.  The kernel already has runtime tests in place
for new things on 486 and later via cpuid.

> > Some Via CPU is like i486 (by instruction set).
> >
> > CPU: VIA Ezra (800.04-MHz 686-class CPU)
> >   Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
> >   Features=0x803035
> >   AMD Features=0x8000<3DNow!>
> >
> 
> 486 never had MMX extensions.
> This is a 686, performance should improve ~4%.

How did you measure the improvement?  Keeping I486_CPU doesn't really
do anything except remove a some #ifdef'd conditionals in identcpu.c
and initcpu.c.  It doesn't affect whether we use the TSC, MMX, etc.  Those
are all runtime checks based the CPU feature flags from cpuid.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Rodney W. Grimes]

> On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:
> 
> > Author: pfg
> > Date: Sat Mar  4 15:04:17 2017
> > New Revision: 314669
> > URL: https://svnweb.freebsd.org/changeset/base/314669
> > 
> > Log:
> >   Drop i486 from the default i386 GENERIC kernel configuration.
> >   
> >   80486 production was stopped by Intel on September 2007. Dropping the 486
> >   configuration option from the GENERIC kernel improves performance
> >   slightly.
> >   
> >   Removing I486_CPU is consistent at this time: we don't support any
> >   processor without a FPU and the PC-98 arch, which frequently involved i486
> >   CPUs, is also gone so we don't test such platforms anymore.
> 
> What is realy mean?
> Some Via CPU is like i486 (by instruction set).
> 
> CPU: VIA Ezra (800.04-MHz 686-class CPU)
>   Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
>   Features=0x803035
>   AMD Features=0x8000<3DNow!>

There is also the whole 486sx family that is 486 die that they turned
the FPU feature off in cause it failed functional test at die sort.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Pedro Giffuni]

On 03/04/17 10:04, Pedro F. Giffuni wrote:

Author: pfg
Date: Sat Mar  4 15:04:17 2017
New Revision: 314669
URL: https://svnweb.freebsd.org/changeset/base/314669

Log:
  Drop i486 from the default i386 GENERIC kernel configuration.

  80486 production was stopped by Intel on September 2007. Dropping the 486
  configuration option from the GENERIC kernel improves performance
  slightly.

  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved i486
  CPUs, is also gone so we don't test such platforms anymore.

  Relnotes: yes
  MFC after:2 weeks
  https://reviews.freebsd.org/D9879



I missed the "Differential Revision:" tag in the log. :(
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Pedro Giffuni]

On 03/04/17 10:32, Slawa Olhovchenkov wrote:

On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:


Author: pfg
Date: Sat Mar  4 15:04:17 2017
New Revision: 314669
URL: https://svnweb.freebsd.org/changeset/base/314669

Log:
  Drop i486 from the default i386 GENERIC kernel configuration.

  80486 production was stopped by Intel on September 2007. Dropping the 486
  configuration option from the GENERIC kernel improves performance
  slightly.

  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved i486
  CPUs, is also gone so we don't test such platforms anymore.


What is realy mean?


This means we don't do work-arounds that would be required for raw 486.
Instead we will use the 586 instructions by default.


Some Via CPU is like i486 (by instruction set).

CPU: VIA Ezra (800.04-MHz 686-class CPU)
  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
  Features=0x803035
  AMD Features=0x8000<3DNow!>



486 never had MMX extensions.
This is a 686, performance should improve ~4%.

Pedro.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Slawa Olhovchenkov]

On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:

> Author: pfg
> Date: Sat Mar  4 15:04:17 2017
> New Revision: 314669
> URL: https://svnweb.freebsd.org/changeset/base/314669
> 
> Log:
>   Drop i486 from the default i386 GENERIC kernel configuration.
>   
>   80486 production was stopped by Intel on September 2007. Dropping the 486
>   configuration option from the GENERIC kernel improves performance
>   slightly.
>   
>   Removing I486_CPU is consistent at this time: we don't support any
>   processor without a FPU and the PC-98 arch, which frequently involved i486
>   CPUs, is also gone so we don't test such platforms anymore.

What is realy mean?
Some Via CPU is like i486 (by instruction set).

CPU: VIA Ezra (800.04-MHz 686-class CPU)
  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
  Features=0x803035
  AMD Features=0x8000<3DNow!>

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r314669 - head/sys/i386/conf

[Pedro F. Giffuni]

Author: pfg
Date: Sat Mar  4 15:04:17 2017
New Revision: 314669
URL: https://svnweb.freebsd.org/changeset/base/314669

Log:
  Drop i486 from the default i386 GENERIC kernel configuration.
  
  80486 production was stopped by Intel on September 2007. Dropping the 486
  configuration option from the GENERIC kernel improves performance
  slightly.
  
  Removing I486_CPU is consistent at this time: we don't support any
  processor without a FPU and the PC-98 arch, which frequently involved i486
  CPUs, is also gone so we don't test such platforms anymore.
  
  Relnotes: yes
  MFC after:2 weeks
  https://reviews.freebsd.org/D9879

Modified:
  head/sys/i386/conf/GENERIC

Modified: head/sys/i386/conf/GENERIC
==
--- head/sys/i386/conf/GENERIC  Sat Mar  4 13:05:04 2017(r314668)
+++ head/sys/i386/conf/GENERIC  Sat Mar  4 15:04:17 2017(r314669)
@@ -18,7 +18,6 @@
 #
 # $FreeBSD$
 
-cpuI486_CPU
 cpuI586_CPU
 cpuI686_CPU
 ident  GENERIC
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"