Hi,
2010/7/18 Steve Langasek vor...@debian.org:
On Fri, Jul 16, 2010 at 09:46:29AM +0200, Loïc Minier wrote:
On Fri, Jul 16, 2010, Hector Oron wrote:
[...]
Just an email to note that this thread has been forked to another
subject name and points future mailing lists readers to the right
place.
On Fri, Jul 16, 2010 at 09:46:29AM +0200, Loïc Minier wrote:
On Fri, Jul 16, 2010, Hector Oron wrote:
to take it as another architecture, but, nowadays,
arm-none-linux-gnueabi supports hard, soft and softfp. Bringing old
discussions up to front, would not make sense to have ABI support in
On Sun, Jul 18, 2010, Steve Langasek wrote:
(BTW... if you want to run both armel and armhf under multiarch... which
package's libc gets to own ld.so? :P)
I understand ld.so can be wherever we want, since it's part of the
executables, but I understand you're asking which architecture gets to
On Sun, Jul 18, 2010 at 09:40:11PM +0200, Loïc Minier wrote:
On Sun, Jul 18, 2010, Steve Langasek wrote:
(BTW... if you want to run both armel and armhf under multiarch... which
package's libc gets to own ld.so? :P)
I understand ld.so can be wherever we want, since it's part of the
On 7/16/10, Aurelien Jarno aurel...@aurel32.net wrote:
Martin Guy a écrit :
users of armv4t boards, from using the universal operating system
Debian?
I was not aware of that. If they are some real users of an armv4t port,
we should probably keep it.
The most widespread is the
I am absolutely gobsmacked that popcon DOESN'T report CPU architecture.
On Sat, 17 Jul 2010, Martin Guy wrote:
On 7/16/10, Aurelien Jarno aurel...@aurel32.net wrote:
Martin Guy a écrit :
users of armv4t boards, from using the universal operating system
Debian?
I was not aware of that.
Matt Sealey a écrit :
I am fairly sure (oh you did!) find a contrived benchmark to show that
some code is faster on softfp in some cases, but taking a holistic
approach I find it hard to believe that every time a floating point
function is called across any of 20,000 packages possibly running
On Thu, Jul 15, 2010, Paul Brook wrote:
A simple benchmark confirms this hypothesis.
softfp is actually faster in many cases.
Could we consider it a gcc bug that when hardfp is turned on, it could
still pick a faster soft float code path and doesn't?
--
Loïc Minier
--
To UNSUBSCRIBE,
On Fri, Jul 16, 2010, Hector Oron wrote:
In that case, Debian was clear
to take it as another architecture, but, nowadays,
arm-none-linux-gnueabi supports hard, soft and softfp. Bringing old
discussions up to front, would not make sense to have ABI
Konstantinos Margaritis a écrit :
On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
I still doubt that the disruption and extra work for the community of
Debian package maintainers, and the lower quality of the resulting
archive, is worth the small increment in speed that is promised. I
On Friday 16 July 2010 10:38:19 Aurelien Jarno wrote:
I don't say a hardfp port should not be done, but that starting such a
port should be done based on solid *facts*, benchmarks, tests and so on.
Ok, I just couldn't help it and ran another benchmark, this time I chose
povray (3.6.1-12),
On Friday 16 July 2010 10:47:40 Aurelien Jarno wrote:
Have this 30% have actually been measured on such applications?
how can I benchmark the desktop? It feels faster, that's definite.
If softfp is already 10x faster, does the additional 30% between softfp
and hardfp really worth it? Do we
Loïc Minier a écrit :
On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
softfp:
I wonder what you built with softfp exactly? Did you rebuild
libc6, libpng12-0 for instance? Not that I expect that most of the
time is spent in libpng12-0, but still.
As I understand it, we have
On Friday 16 July 2010 11:11:39 Aurelien Jarno wrote:
Why are we comparing softfp vs hardfp? We should compare the existing
armel port, that is soft, vs both softfp and hardfp.
Er, that's the whole point of the discussion. There is no question about
having a new soft port, but a hardfp port
On Friday 16 July 2010 11:11:24 Loïc Minier wrote:
On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
softfp:
I wonder what you built with softfp exactly? Did you rebuild
libc6, libpng12-0 for instance? Not that I expect that most of the
time is spent in libpng12-0, but still.
I
On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
softfp:
I wonder what you built with softfp exactly? Did you rebuild
libc6, libpng12-0 for instance? Not that I expect that most of the
time is spent in libpng12-0, but still.
As I understand it, we have these options:
- keep Debian
* Aurelien Jarno aurel...@aurel32.net [2010-07-16 09:38]:
BTW, has anybody thought about increasing the minimum requirement for
the armel port, for example to armv5? Available machines has evolved,
maybe the port should do the same.
Indeed. From Paul's emails, I'm getting the feeling that
Hello Loic,
2010/7/16 Loïc Minier l...@dooz.org:
still need a new port. We also need a different triplet for the
multiarch use case; I know you're not too interested in multiarch
yourself anymore, but it's safer to pick a different triplet
nevertheless IMHO, using the vendor field.
On Fri, Jul 16, 2010 at 09:55:49AM +0100, Martin Michlmayr wrote:
* Aurelien Jarno aurel...@aurel32.net [2010-07-16 09:38]:
BTW, has anybody thought about increasing the minimum requirement for
the armel port, for example to armv5? Available machines has evolved,
maybe the port should do
Ok, here are Arora Sunspider (javascript) benchmarks
for softfp:
http://www2.webkit.org/perf/sunspider-0.9/sunspider-results.html?{%223d-cube%22:[649,737,722,721,720],%223d-morph%22:[1050,1070,1058,1058,1053],%223d-
On Friday 16 July 2010 14:30:38 Paul Brook wrote:
Based on what evidence?
The G4 has an single cycle pipelined out-of-order FPU. The A8 has a
non-pipelined FPU that takes between 5 and 20 (normal single precision is
10) cycles to give a result. A 9x slowdown sounds right on the ball.
Ok, I
Martin Guy a écrit :
On 7/16/10, Martin Michlmayr t...@cyrius.com wrote:
* Aurelien Jarno aurel...@aurel32.net [2010-07-16 09:38]:
BTW, has anybody thought about increasing the minimum requirement for
the armel port, for example to armv5? Available machines has evolved,
maybe the port
Hello,
2010/7/16 Aurelien Jarno aurel...@aurel32.net:
So, the same question: what is the measured speed up for users of ARM
architectures =5, and is it worth excluding the significant number of
users of armv4t boards, from using the universal operating system
Debian?
I was not aware of
+++ Konstantinos Margaritis [2010-07-16 14:56 +0300]:
Ok, here are Arora Sunspider (javascript) benchmarks
Handy benchmark. I didn't know about that before (just found out my
desktop is 2.8 times faster than my laptop on this).
snip monster URLs
Just to save others a bit of time:
The
On Friday 16 July 2010 15:36:26 Wookey wrote:
Just to save others a bit of time:
The summary from that lot is that hardfp is about 4% faster on average
(between 0 and 11% on various tests). So definitely faster for
real-world stuff, but 4% won't justify a new port from Debian's POV.
4%
+++ Konstantinos Margaritis [2010-07-16 16:04 +0300]:
On Friday 16 July 2010 15:36:26 Wookey wrote:
Just to save others a bit of time:
The summary from that lot is that hardfp is about 4% faster on average
(between 0 and 11% on various tests). So definitely faster for
real-world stuff,
On Fri, Jul 16, 2010 at 9:23 AM, Wookey woo...@wookware.org wrote:
+++ Konstantinos Margaritis [2010-07-16 16:04 +0300]:
On Friday 16 July 2010 15:36:26 Wookey wrote:
Just to save others a bit of time:
The summary from that lot is that hardfp is about 4% faster on average
(between 0 and
Hello,
2010/7/15, Paul Brook p...@codesourcery.com:
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
On Wed, Jul 14, 2010, Hector Oron 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 debian-cortex port.
+++ Loïc Minier [2010-07-15 10:00 +0200]:
On Wed, Jul 14, 2010, Hector Oron 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
On 7/15/10, Loïc Minier l...@dooz.org wrote:
armel can also use vfp instructions, so I personally find it confusing.
No it can't. Any binary that contains a vfp instruction will die with
SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
Debian armel.
As far as the ABI is
On Thu, Jul 15, 2010 at 10:00:28AM +0200, Loïc Minier wrote:
cortex as the port name sounds very wrong, as others have commented
already:
* some CPUs we explicitly targe t(by configuring for vfpv3-d16) aren't
cortex (they don't instantiate the Cortex-A8 gates on the silicon,
but a
On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
Yes, however fixing this this does not require a new port. It only requires
providing alternative packages builds within the same port. The important
point being that (assuming capable hardware) you can freely mix the two.
It
On Thu, Jul 15, 2010, Martin Guy wrote:
No it can't. Any binary that contains a vfp instruction will die with
SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
Debian armel.
Yes, it will die /on chips without a VFP/, but Ubuntu has an armel port
with vfp turned on by
On Thu, Jul 15, 2010, Lennart Sorensen wrote:
How is that different than i386 works on i686? The name is essentially
the minimum cpu that can run the code.
First, i386 was a bad name (it should have been called x86, or ia32),
let's not redo the same mistake.
Second, cortex is not a
On Thu, Jul 15, 2010 at 04:58:29PM +0200, Loïc Minier wrote:
First, i386 was a bad name (it should have been called x86, or ia32),
let's not redo the same mistake.
Good point.
Second, cortex is not a minimum CPU, it's a particular implementation.
Cortex-A implies ARMv7, but you can be
On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
I still doubt that the disruption and extra work for the community of
Debian package maintainers, and the lower quality of the resulting
archive, is worth the small increment in speed that is promised. I
hope
30% *measured* (vs promised)
On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
armel can also use vfp instructions, so I personally find it
confusing.
Yes, however fixing this this does not require a new port. It only
requires providing alternative packages builds within the same port. The
important
On Thu, Jul 15, 2010 at 10:26 AM, Paul Brook p...@codesourcery.com wrote:
On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
armel can also use vfp instructions, so I personally find it
confusing.
Yes, however fixing this this does not require a new port. It only
requires
Enabling use of VFP does not require use of the hard-float ABI. Please
don't confuse the two.
The whole point of the port is that we get rid of the softfloat ABI in
order to use the VFP unit without playing around moving
registers around. This sort of came about from Konstantinos' porting
On Thursday 15 July 2010 19:19:13 Paul Brook wrote:
However changing the ABI doesn't solve many of the underlying problem.
Specifically how to provide optimized binaries that take advantage of new
features on modern CPUs while still supporting older hardware.
You can't bridge that gap. There
On Thu, Jul 15, 2010 at 11:19 AM, Paul Brook p...@codesourcery.com wrote:
Enabling use of VFP does not require use of the hard-float ABI. Please
don't confuse the two.
The whole point of the port is that we get rid of the softfloat ABI in
order to use the VFP unit without playing around
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 resolved
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 different
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
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
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
What you're describing here is multiarch.
Multiarch still isn't there, even after at least 5 years when I saw the
first presentation. It may have been hard on x86/x86_64 or ppc/ppc64 where
there were only 2 variants, here we have what? 5? 10? I seriously think
it's not worth it.
No. We
Switching to the hard-float ABI certainly does give some benefit. While
20% isn't a trivial difference, it's important to keep this in context.
This is on top of what I'd guess is a 10x (i.e. 1000%) speedup achieved
without breaking the ABI and requiring a whole new port.
How do you
On Thursday 15 July 2010 18:20:07 Konstantinos Margaritis wrote:
On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
I still doubt that the disruption and extra work for the community of
Debian package maintainers, and the lower quality of the resulting
archive, is worth the small increment
In libm.so, I took sinf() -a very often used function, absolutely
necessary for any trig stuff- and tried to actually find the differences
using
objdump:
...
Do the math, there are 6 more vmov instructions (all between rX and sX
registers) in the softfp versions. Ok, if one gives
Hi Paul
Please understand we know what we're talking about here :D
In summary:
We want a new port that uses the hard floating point version of the
EABI - floating point arguments to functions are passed in floating
point registers (sN, dN, qN) as the ABI allows.
This is to get around the fact
As Konstantinos explained, this is something of the order of 6 moves
around from integer to float and back again for a relatively simple
function like sinf() which takes one floating point argument and
returns one. vmov rN, sN has a penalty of around 20 cycles. Nothing is
being done here, it
+++ Paul Brook [2010-07-15 22:29 +0100]:
Do the math, there are 6 more vmov instructions (all between rX and sX
registers) in the softfp versions. Ok, if one gives a stall of 20 cycles,
how many cycles do we lose in sinf() alone?
Depends how the function is called. Worst case we
Dear developers,
2010/7/13, Riku Voipio riku.voi...@iki.fi:
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
Hello Loïc,
2010/7/15, Loïc Minier l...@dooz.org:
Concerning the triplet choice, I'd highly recommend reading this
upstream thread:
http://gcc.gnu.org/ml/gcc/2010-07/threads.html#00179
Thanks for sharing it. Quite interesting.
For my point of view, ABI should not be encoded in the
On Friday 16 July 2010 00:29:27 Paul Brook wrote:
A simple benchmark confirms this hypothesis.
softfp is actually faster in many cases.
snip
If you want to do a benchmark on sinf, next time do it right, span the values
on 0..M_PI at least (not 0..1.0), here are the results with only one
Oh, btw, I also had done some benchmarking -much more elaborate than yours,
I'm afraid- when rewriting these functions using another algorithm (Pade
approximants, but that's not the discussion here):
0..M_PI/4
hardfp: 3184713.38 calculations of sinf()/sec
softfp: 3039513.68 calculations of
On Friday 16 July 2010 07:14:17 Konstantinos Margaritis wrote:
No comment needed. Such results are consistent with all math functions that
I have tested (cosf, tanf, expf, etc). Speed gain is accumulative, so in
say a rotation matrix function, with (usually) 2 cosf+2 sinf calls, the
speed
On Friday 16 July 2010 07:58:02 Paul Brook wrote:
Mainly that your analysis of the code was almost entirely bogus.
You are free of course to take my analysis any way you like -btw it wasn't an
analysis, it was just an indication of the possible performance hit on softfp,
I'm sure you know the
Hello,
2010/7/6, Hector Oron hector.o...@gmail.com:
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
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 licensees
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
On Wed, Jul 14, 2010 at 5:33 PM, Paul Brook p...@codesourcery.com 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
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 be
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
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
On Wed, Jul 14, 2010 at 5:21 PM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca 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
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
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
Dear Aurelien,
2010/7/13, Aurelien Jarno aurel...@aurel32.net:
One more technical issue, though not directly related to ARM: we need to
upgrade the hard drives on the debian-ports.org machine before accepting
a new port. Nothing hudge, but that may introduce a bit of delay.
Is there something
On Tue, Jul 13, 2010 at 11:49:48PM +0200, Hector Oron wrote:
Dear Aurelien,
2010/7/13, Aurelien Jarno aurel...@aurel32.net:
One more technical issue, though not directly related to ARM: we need to
upgrade the hard drives on the debian-ports.org machine before accepting
a new port.
Hey
Just wanted to raise that it might be wise to check whether any ABI
changes or tweaks are in the pipe upstream before kicking a new port;
it's not happening that frequently after all, so worth the extra
burden.
I'm happy to take action to check that with upstream GCC folks, and
On 09/07/10 19:16, Hector Oron wrote:
arm-hardfloat-linux-gnueabi
This would be the path of least resistance. You can do this without
breaking much, and without annoying anybody upstream. You might need to
do a few hacks to various packages that want to know which ABI is in
use, but
On 09/07/10 19:16, Hector Oron wrote:
arm-hardfloat-linux-gnueabi
This would be the path of least resistance. You can do this without
breaking much, and without annoying anybody upstream. You might need to
do a few hacks to various packages that want to know which ABI is in
use, but
On 12/07/10 14:34, Paul Brook wrote:
Anything that relies on the target triplet is going to break as soon
as you move outside a pure Debian system. i.e. any patches relying on
a particular target triplet are inherently Debian specific, and IMO
should never be pushed upstream.
Which is why
On 12/07/10 14:34, Paul Brook wrote:
Anything that relies on the target triplet is going to break as soon
as you move outside a pure Debian system. i.e. any patches relying on
a particular target triplet are inherently Debian specific, and IMO
should never be pushed upstream.
Which is
On Sun, Jul 11, 2010 at 03:40:16AM +0100, Wookey wrote:
I don't think you can re-use Debian arch names. They mean something
and if it's been used at all widely you can't just change it later (or
at least not for 10-20 years or so). (armeb was little-enough used
that we probably could change
On 7/11/10, Bill Gatliff b...@billgatliff.com wrote:
But then doesn't that mean that everything is armel, so we never have a
hope of having Debian officially support more than one combination?
Well, armel should be as generic as possible. In an ideal world, it
would be called arm and run on
The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
NEON) and instruction set versions (v4, v5, v6a, v7) can also be
incompatible in the sense that they won't run on hardware without
those features. But I really think we should try to deal with that by
correctly
The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
NEON) and instruction set versions (v4, v5, v6a, v7) can also be
incompatible in the sense that they won't run on hardware without
those features. But I really think we should try to deal with that by
correctly decorating
+++ Paul Brook [2010-07-11 14:16 +0100]:
The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
NEON) and instruction set versions (v4, v5, v6a, v7) can also be
incompatible in the sense that they won't run on hardware without
those features. But I really think we should try
Hello Martin,
2010/7/10, Martin Guy martinw...@gmail.com:
What are the effects of the name choice?
If we pick up the wrong name, then we would need to start over the
bootstrapping again, and we would like to avoid that.
Is it really just a matter of personal taste?
For the Debian
On 09/07/10 21:40, Paul Brook wrote:
[...]
There are several variants of VFPv3. Some have the additional registers
(typically the implementations that also have NEON), some do not. VFPv3 also
introduces some new instructions, so even the variants with the restricted
register file will not
This just makes it even more important that any hypothetical FPU-based
Debian variant thinks very, very carefully about the ABI it uses. There
is a standard EABI variant for passing parameters in FPU registers ---
but is it sufficiently common to be useful in a cross-platform OS? Are
there
On 7/10/10, Hector Oron hector.o...@gmail.com wrote:
2010/7/10, Martin Guy martinw...@gmail.com:
What are the effects of the name choice?
If we pick up the wrong name, then we would need to start over the
bootstrapping again, and we would like to avoid that.
Sure. So my question was what
Hello,
2010/7/10, Hector Oron hector.o...@gmail.com:
2010/7/10, Martin Guy martinw...@gmail.com:
Sure. So my question was what are the technical impacts of the string
chosen as an arch name? -or- What would make it 'wrong'?
AFAICS, there are no technical impacts. If someone knows it better,
I would suggest to pick a generic, short name, with we could reuse
later if it is proven that hardfloat has no sense in the next years.
Comments?
I suggest just the opposite. :)
We should pick a name that is clear and concise, so that it doesn't collide
with another name we'd like to use
+++ Bill Gatliff [2010-07-10 21:05 -0500]:
I would suggest to pick a generic, short name, with we could reuse
later if it is proven that hardfloat has no sense in the next years.
Comments?
I don't think you can re-use Debian arch names. They mean something
and if it's been used
The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
NEON) and instruction set versions (v4, v5, v6a, v7) can also be
incompatible in the sense that they won't run on hardware without
those features. But I really think we should try to deal with that by
correctly decorating
+++ Hector Oron [2010-07-09 01:54 +0200]:
Hello,
2010/7/8, Wookey woo...@wookware.org:
...snip...
armarm-linux-gnu
...snip...
I guess that's (more than) enough for now. Thoughts welcome.
Would be sane to use old deprecated OABI name?
armarm-linux-gnu
One day, that
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
+++ Konstantinos Margaritis [2010-07-08 15:38 +0300]:
Even now, libc arch specific optimizations -like libc6-i686
that you mentioned- are undocumented, very few packages actually provide
support for them, and in short, software ends up totally unoptimized for no
good reason.
That's too
On Thu, Jul 08, 2010, Wookey wrote:
The first thing I've found is that whilst we can build for
--mfloat-abi=hard there is no macro set by GCC to detect this state.
For the record:
https://bugs.launchpad.net/gcc-linaro/+bug/602745
manufacturer/vendor doesn't really supply useful information
Hello,
2010/7/9, Loïc Minier l...@dooz.org:
Please, let's not use the last field; there is not only the default
target of the toolchain, there is also the toolchain itself. An
arm-linux-gnueabi toolchain can target both soft and hard float calling
conventions, so a single triplet. It
On Fri, Jul 09, 2010 at 07:27:23PM +0200, Hector Oron wrote:
Have we got a Debian architecture name yet? 'armelhf' is most reasonable one?
I prefer 'armhf', FWIW.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On 2010-07-06 21:55, Loïc Minier wrote:
[...]
I would be a bit scared that this has a chance of getting out of date,
or be confusing because other ports might be v7 as well, or also
because this only reflects a subset of the ports' requirement (VFP
level for instance isn't reflected,
On Thu, Jul 08, 2010 at 02:58:58PM +0300, Riku Voipio wrote:
On Tue, Jul 06, 2010 at 10:55:25PM +0200, Loïc Minier wrote:
On Tue, Jul 06, 2010, Joey Hess wrote:
Could the targeted CPU be used in the name? Ie, armelv7.
Or even just armv7. It is just a name, so it should be short and
not
Hello again,
2010/7/9, Clint Adams sch...@debian.org:
I prefer 'armhf', FWIW.
Somebody against 'armhf'? Have we got it?
And for the triplet, is it OK to use vendor tag as explained in the
wiki page[1]?
arm-hardfloat-linux-gnueabi
or
armhf-linux-gnueabi
Please, remember, that this effort
On Fri, Jul 09, 2010, Hector Oron wrote:
Somebody against 'armhf'? Have we got it?
arm-hardfloat-linux-gnueabi
Sounds good
armhf-linux-gnueabi
Oh no, not the CPU field; it really can only go in vendor
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
1 - 100 of 127 matches
Mail list logo
