All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] Naming of packages for x86 archs
@ 2008-07-25 12:53 Marcin Juszkiewicz
  2008-07-25 13:17 ` Thomas Kunze
  2008-07-25 14:27 ` Phil Blundell
  0 siblings, 2 replies; 3+ messages in thread
From: Marcin Juszkiewicz @ 2008-07-25 12:53 UTC (permalink / raw)
  To: openembedded-devel


Hi

OpenEmbedded supports granulated packaging and tuning to get as much as 
possible from each CPU. This works fine for ARM and PowerPC platforms as 
their cores are easy to recognize (armv4t, armv5te, armv6, armv7a for 
ARM). The problem lies in x86 land where there is no such order in 
cores...

Currently we have following tunings for x86:

name		| -march value	| packaging
---------------------------------------------
athlonmp	| i686		| i686
c3		| c3		| i586
geodelx		| k6-2		| geode
pentium		| pentium	| i586
prescott	| prescott	| i686p4c
pentiumpro	| pentiumpro	| i686
x86-nocona	| nocona	| NOT SET
x86-prescott	| prescott	| NOT SET
x86		| i486		| i486

And we have Progear machine which use Transmeta Crusoe which can have 
own optimisations (I have to unpack mine one day and build something for 
it).

I would like to start discussion about naming for x86 package archs. One 
of propositions in past was use something like "tune-prescott" does - 
adding description after arch name (i686p4c). This way we can have list 
like:

i486

i586      - pentium
i586mmx   - pentium with mmx, Geode GX1
i586c3    - VIA C3
i586k6    - AMD K6
i586k62   - AMD K6-2, Geode LX
i586geode - Geode LX with gcc 4.3 or patched 4.2

i686      - pentium pro, Crusoe TM5xxxx (MMX only)
i686p2    - pentium II
i686sse   - pentium III
i686sse2  - pentium-m, Transmeta Efficeon
i686sse3  - pentium with SSE3, VIA C7
i686p4    - pentium 4 cores
i686p4c   - celeron with pentium 4 core
i686c32   - VIA Eden, Nehemiah (-march=c3-2)
i686ath   - AMD Athlon Thunderbird core
i686axp   - AMD Athlon XP cores
i686asse3 - AMD64 cpus in 32bit mode (those with SSE3 support)

Names are ofcourse to define in more sane way but to make it easy to 
recognize does package will work on target platform or not. So if my 
target platform cpu will handle sse1/2/3 and 3dnow then I can run 
everything from above list, but if it GeodeLX then I can run every i586 
variants on it.

What does other developer think about it? Does it have a sense?







^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] Naming of packages for x86 archs
  2008-07-25 12:53 [RFC] Naming of packages for x86 archs Marcin Juszkiewicz
@ 2008-07-25 13:17 ` Thomas Kunze
  2008-07-25 14:27 ` Phil Blundell
  1 sibling, 0 replies; 3+ messages in thread
From: Thomas Kunze @ 2008-07-25 13:17 UTC (permalink / raw)
  To: openembedded-devel

Marcin Juszkiewicz wrote:
> Hi
>
> OpenEmbedded supports granulated packaging and tuning to get as much as 
> possible from each CPU. This works fine for ARM and PowerPC platforms as 
> their cores are easy to recognize (armv4t, armv5te, armv6, armv7a for 
> ARM). The problem lies in x86 land where there is no such order in 
> cores...
>
> Currently we have following tunings for x86:
>
> name		| -march value	| packaging
> ---------------------------------------------
> athlonmp	| i686		| i686
> c3		| c3		| i586
> geodelx		| k6-2		| geode
> pentium		| pentium	| i586
> prescott	| prescott	| i686p4c
> pentiumpro	| pentiumpro	| i686
> x86-nocona	| nocona	| NOT SET
> x86-prescott	| prescott	| NOT SET
> x86		| i486		| i486
>
> And we have Progear machine which use Transmeta Crusoe which can have 
> own optimisations (I have to unpack mine one day and build something for 
> it).
>
> I would like to start discussion about naming for x86 package archs. One 
> of propositions in past was use something like "tune-prescott" does - 
> adding description after arch name (i686p4c). This way we can have list 
> like:
>
> i486
>
> i586      - pentium
> i586mmx   - pentium with mmx, Geode GX1
> i586c3    - VIA C3
> i586k6    - AMD K6
> i586k62   - AMD K6-2, Geode LX
> i586geode - Geode LX with gcc 4.3 or patched 4.2
>
> i686      - pentium pro, Crusoe TM5xxxx (MMX only)
> i686p2    - pentium II
> i686sse   - pentium III
> i686sse2  - pentium-m, Transmeta Efficeon
> i686sse3  - pentium with SSE3, VIA C7
> i686p4    - pentium 4 cores
> i686p4c   - celeron with pentium 4 core
> i686c32   - VIA Eden, Nehemiah (-march=c3-2)
> i686ath   - AMD Athlon Thunderbird core
> i686axp   - AMD Athlon XP cores
> i686asse3 - AMD64 cpus in 32bit mode (those with SSE3 support)
>
> Names are ofcourse to define in more sane way but to make it easy to 
> recognize does package will work on target platform or not. So if my 
> target platform cpu will handle sse1/2/3 and 3dnow then I can run 
> everything from above list, but if it GeodeLX then I can run every i586 
> variants on it.
>
> What does other developer think about it? Does it have a sense?
>
>   
I'm not really into x86 for oe or details of x86 cpus, but this sounds
as a good idea.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC] Naming of packages for x86 archs
  2008-07-25 12:53 [RFC] Naming of packages for x86 archs Marcin Juszkiewicz
  2008-07-25 13:17 ` Thomas Kunze
@ 2008-07-25 14:27 ` Phil Blundell
  1 sibling, 0 replies; 3+ messages in thread
From: Phil Blundell @ 2008-07-25 14:27 UTC (permalink / raw)
  To: openembedded-devel

On Fri, 2008-07-25 at 14:53 +0200, Marcin Juszkiewicz wrote:
> I would like to start discussion about naming for x86 package archs. One 
> of propositions in past was use something like "tune-prescott" does - 
> adding description after arch name (i686p4c). This way we can have list 
> like:
> 
> i586      - pentium
> i586mmx   - pentium with mmx, Geode GX1
> i586c3    - VIA C3
> i586k6    - AMD K6
> i586k62   - AMD K6-2, Geode LX
> i586geode - Geode LX with gcc 4.3 or patched 4.2

I'm not totally thrilled with the idea of jamming the tune flags into
the architecture name.  This seems like it will give you an explosion of
new arch names which, for 99% of packages, will not be usefully
different to one another.

If any particular distro needs that level of distinction then fine, let
them go it for their packages.  But I don't think it should necessarily
be the default.

p.





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-07-25 14:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-25 12:53 [RFC] Naming of packages for x86 archs Marcin Juszkiewicz
2008-07-25 13:17 ` Thomas Kunze
2008-07-25 14:27 ` Phil Blundell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.