Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Hector Oron
Dear developers, 2010/7/13, Riku Voipio : > Subarchs could also be useful if we wanted to build softfp abi compatible > armv6/armv7 armel builds of the whole debian repository. Of course we could > do > builds without subarchs, but then users would be unable distinguish which > installed packages

Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Loïc Minier
On Thu, Jul 15, 2010, Aurelien Jarno wrote: >It allows > to provide different versions of a given symbol using an IFUNC symbol > type. This will be resolved by the dynamic loader during relocation > depending on the hardware characteri

Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Konstantinos Margaritis
On Thursday 15 July 2010 21:06:52 Paul Brook wrote: > Not quite. It provides a mechanism for selecting different routines without > the runtime overhead of a check on every call. It effecitvely provides a > hook into the dynamaic linker that allows you to decide which function to > export for a

Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Paul Brook
> On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote: > > Note that the new alternative to hwcap is called "multiarch" in the GNU > > libc (something totally different than "multiarch" in Debian). It allows > > to provide different versions of a given symbol using an IFUNC symbol > > type. This

Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Aurelien Jarno
On Thu, Jul 15, 2010 at 08:06:42PM +0300, Konstantinos Margaritis wrote: > On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote: > > Note that the new alternative to hwcap is called "multiarch" in the GNU > > libc (something totally different than "multiarch" in Debian). It allows > > to provide

Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Konstantinos Margaritis
On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote: > Note that the new alternative to hwcap is called "multiarch" in the GNU > libc (something totally different than "multiarch" in Debian). It allows > to provide different versions of a given symbol using an IFUNC symbol > type. This will be r

Re: armelfp: new architecture name for an armel variant

2010-07-15 Thread Aurelien Jarno
Riku Voipio a écrit : > On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote: >> Personally, before any further discussion I'd like to see some numbers >> with core libraries (libc, libgcc, libgmp, libatlas? etc) built with >> softfp, which eventually might be able to switch to use the hwc

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-15 Thread Hector Oron
Hello, 2010/7/15, Paul Brook : > It isn't. "Cortex" is the marketing name for the current set of CPU core > implementations designed by ARM ltd. Calling the armv7 port "cortex" is > equivalent to calling the i686 port "pentium" [1]. But i?86 is ABI compatible, while ARM ABI is a full mess AFAICS

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Paul Brook
> On Wed, Jul 14, 2010 at 05:11:16PM -0500, Matt Sealey wrote: > > It's ARM's architecture and theirs to license, not Marvell's or > > Qualcomm's. > > > > Qualcomm won't be so particularly annoyed as they get a big reference > > in ARM's manuals (Qualcomm Scorpion is referenced). > > > > In the e

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Matt Sealey
On Wed, Jul 14, 2010 at 5:21 PM, Lennart Sorensen wrote: > On Wed, Jul 14, 2010 at 05:11:16PM -0500, Matt Sealey wrote: >> It's ARM's architecture and theirs to license, not Marvell's or Qualcomm's. >> > > Oh I hadn't realized cortex was an ARM name for that particular feature > set.  In that case

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Lennart Sorensen
On Wed, Jul 14, 2010 at 05:11:16PM -0500, Matt Sealey wrote: > It's ARM's architecture and theirs to license, not Marvell's or Qualcomm's. > > Qualcomm won't be so particularly annoyed as they get a big reference > in ARM's manuals (Qualcomm Scorpion is referenced). > > In the end by far the most

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Matt Sealey
It's ARM's architecture and theirs to license, not Marvell's or Qualcomm's. Qualcomm won't be so particularly annoyed as they get a big reference in ARM's manuals (Qualcomm Scorpion is referenced). In the end by far the most common (in terms of chips using it) variant of armv7 is the cortex serie

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Konstantinos Margaritis
On Thursday 15 July 2010 00:45:56 Michael Casadevall wrote: > > I suspect the other architecture licensees (Marvell, Qualcomm) might not > > be so enthusiastic about this naming... > > Seconded. Since this port will work on all ARM SoCs that meet the > minimal hardware requirements, it should not

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Lennart Sorensen
On Wed, Jul 14, 2010 at 10:33:20PM +0100, Paul Brook wrote: > I suspect the other architecture licensees (Marvell, Qualcomm) might not be > so > enthusiastic about this naming... Does marvell and qualcomm have hardfloat on their chips? Certainly if it will run on other chips, the name does seem

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Hector Oron
Hello, 2010/7/15, Konstantinos Margaritis : > First, 'cortex' is not a vendor. it's a cpu family. It's not owned by > Marvell > or Qualcomm, but by ARM, if they are OK with us using the name, I don't see > why the other companies would mind, esp. if they don't offer a cpu in that > particular fami

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Paul Brook
> Genesi have recommended 'cortex' as Debian architecture name and > 'arm-hardfloat-linux-gnueabi' as triplet. This has been in fact > approved and endorsed -and actually encouraged- by ARM itself, they > really liked the idea of having a debian-cortex port. I suspect the other architecture licens

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Michael Casadevall
On Wed, Jul 14, 2010 at 5:33 PM, Paul Brook wrote: >> Genesi have recommended 'cortex' as Debian architecture name and >> 'arm-hardfloat-linux-gnueabi' as triplet. This has been in fact >> approved and endorsed -and actually encouraged- by ARM itself, they >> really liked the idea of having a debi

cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

2010-07-14 Thread Hector Oron
Hello, 2010/7/6, Hector Oron : > Dear armel porters, [...] It is past over a week and people is wanting to start. I would like to point you to a parallel discussion hold at recent created Linaro group [1] There is also a wiki page for the port [2] The one that bootstraps the port picks the nam

Re: armelfp: new architecture name for an armel variant

2010-07-13 Thread Riku Voipio
On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote: > Personally, before any further discussion I'd like to see some numbers > with core libraries (libc, libgcc, libgmp, libatlas? etc) built with > softfp, which eventually might be able to switch to use the hwcaps > infrastructure in a s

Re: armelfp: new architecture name for an armel variant

2010-07-09 Thread Loïc Minier
On Thu, Jul 08, 2010, Guillem Jover wrote: > The > lpia is a great example of an architecture variant that was a mistake, > and should haver never been created. This is a bit oversimplified; when lpia was created, there were pro

Re: armelfp: new architecture name for an armel variant

2010-07-08 Thread Konstantinos Margaritis
On Thursday 08 July 2010 14:06:58 Guillem Jover wrote: > Actually, this only seems to me to indicate the option that Aurelien > was mentioning (building few core packages with softfp) should be strongly > considered instead of adding a whole new architecture, which didn't look > had been properly e

Re: armelfp: new architecture name for an armel variant

2010-07-08 Thread Guillem Jover
Hi! On Tue, 2010-07-06 at 21:07:10 +0300, Konstantinos Margaritis wrote: > On Tuesday 06 July 2010 20:45:33 Paul Brook wrote: > > Debian is pure soft-float (i.e. -mfloat-abi=soft). > > Right, all the more reason for a new flavour then :) Actually, this only seems to me to indicate the option tha

Re: armelfp: new architecture name for an armel variant

2010-07-06 Thread Konstantinos Margaritis
On Tuesday 06 July 2010 20:45:33 Paul Brook wrote: > Debian is pure soft-float (i.e. -mfloat-abi=soft). Right, all the more reason for a new flavour then :) > -mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and > libraries can be freely mixed). Obviously softfp code will wi

Re: armelfp: new architecture name for an armel variant

2010-07-06 Thread Paul Brook
A couple of inaccuracies: > These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}. > Softfp is the default in pretty much every distro out there (incl. Ubuntu, > Debian, etc). Only some OpenEmbedded builds have enabled hardfp, but these > are too specialized. Debian is pure soft-f

Re: armelfp: new architecture name for an armel variant

2010-07-06 Thread Konstantinos Margaritis
On Tuesday 06 July 2010 20:30:13 Hector Oron wrote: ... > some preliminary results gave me 20-25% speed increase on exactly the same > software/hardware configuration (eg. glxgears on software mesa reports 145 > fps vs 120 fps). Just one comment, some more benchmarking [1] revealed ~35% speed

armelfp: new architecture name for an armel variant

2010-07-06 Thread Hector Oron
Dear armel porters, I am writting this letter to you by out concern of having to pick up a name for a new armel architecture variant optimized for hard floating point, instead soft floating point. Konstantinos (and I shall be also supporting him) is willing to maintain a new architecture fo