Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Hi, 2010/7/18 Steve Langasek : > 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. "Multiarch and ABI support" on debian-...@l.d.o and debian-d...@l.d.o Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimu3i_8m5kwqwvh92j7yeeui_s5dku5mejye...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 > executables, but I understand you're asking which architecture gets to > own whatever /lib/ld-linux.so.2 is, since there's only one of them and > we want to preserve compatibility with non-Debian binaries, right? > > On my amd64 system, /bin/rm points at /lib64/ld-linux-x86-64.so.2 for > an interpreter (*cough* /lib64) but on an armel system, it points at > /lib/ld-linux.so.3, and on i386 system /lib/ld-linux.so.2 so perhaps we > can expect 64-bits arches to have a suffix while 32-bits arches so that > one could leave ld-linux to 32-bits arches and use the suffix for > 64-bits arches? No idea whether there's a general rule for this > It's not a general rule. For example, 32-bit sparc is /lib/ld-linux.so.2 while 64-bit sparc is /lib64/ld-linux.so.2. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100718235614.ga4...@volta.aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 own whatever /lib/ld-linux.so.2 is, since there's only one of them and we want to preserve compatibility with non-Debian binaries, right? On my amd64 system, /bin/rm points at /lib64/ld-linux-x86-64.so.2 for an interpreter (*cough* /lib64) but on an armel system, it points at /lib/ld-linux.so.3, and on i386 system /lib/ld-linux.so.2 so perhaps we can expect 64-bits arches to have a suffix while 32-bits arches so that one could leave ld-linux to 32-bits arches and use the suffix for 64-bits arches? No idea whether there's a general rule for this -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100718194011.ga25...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 > > the distribution itself (which really is an overhead) and not in the > > upstream code? > We need a new port because the binaries are incompatible with each > others, we need a different triplet because it's a dpkg limitation. > Perhaps we could change dpkg to not require that anymore, but we'd > 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. I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map port names to triplets, but why does it need to do the inverse? And if it doesn't need to map triplet->port, why would the triplet need to be unique? There is a need for a distinct port name; I think this is also not a Debian-specific problem, it's a problem common to any distributions that want to do what's described here. Paul commented that: > 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. But, er, relying on the target triplet for this shouldn't be done in Debian, either! FWIW, this discussion ties in with one of the known outstanding issues with multiarch, namely we want to support coinstallation of libraries optimized for multiple /compatible/ instruction sets. And we don't want to have to add /lib/i386-linux-gnu, /lib/i486-linux-gnu, /lib/i586-linux-gnu [,...] to the path one by one to accomplish that, especially when we already have hwcaps to do the job for us. So perhaps triplets aren't the right level of abstraction to encode in the library paths after all? I mean, it's ok to have libraries in /lib/i486-linux-gnu/686/cmov, but we definitely don't want to *change* the library path if and when Debian's base compatibility level moves from i486 to i586 (or from armv4t to armv5t, to keep this on topic ;) and have to deal with path transitions. Is there a better identifier we should be using to qualify the library paths, instead of these triplets? I.e., instead of the cpu from the triplet, perhaps there are official names for the ELF architectures that can be used - that can be determined without too much hard-coding all over the place? (BTW... if you want to run both armel and armhf under multiarch... which package's libc gets to own ld.so? :P) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 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 Technologic Systems TS-72xx series of boards (see the noisy yahoo TS7200 forum for an idea of how many) and Glomation, while the Sim.One and Snapper boards are about to be marketed. All these are based on that awful Cirrus EP93xx SoC. I'm asking popcon if it's feasible to extend that package to report CPU arch, since concrete figures are always preferable to hearsay and individual impressions. Cheers M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinlqmterfztlb4v1_rghhgs_po6ys5ubie_h...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On 7/16/10, Aurelien Jarno 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 Technologic Systems TS-72xx series of boards (see the noisy yahoo TS7200 forum for an idea of how many) and Glomation, while the Sim.One and Snapper boards are about to be marketed. All these are based on that awful Cirrus EP93xx SoC. I'm asking popcon if it's feasible to extend that package to report CPU arch, since concrete figures are always preferable to hearsay and individual impressions. Cheers M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinlqmterfztlb4v1_rghhgs_po6ys5ubie_h...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Fri, Jul 16, 2010 at 9:23 AM, Wookey 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 11% on various tests). So definitely faster for >> > real-world stuff, but 4% won't justify a new port from Debian's POV. >> >> 4% won't, but 30% might? > > Yes. Exactly. In reality the speedup could be anything between 0 and maybe 25% with some outliers which perform much, much better for some reason. In any case, compiling the distro for armv7-a instead of armv4t introduces further optimizations by the compiler on top of the FPU ABI change, which improves the chances of it being faster (not tested here yet by Konstantinos, I don't think). >> Or what about the huge gain in povray? > > That was dramatic. I guess it leads on to the question of how many > more really dramatic speedups there are in software people actually > use (or would if it was faster :-) See above. In theory anything that uses the FPU to do anything and that FPU code is handled by being passed floating point arguments in functions. For all we know a standard desktop is not improved: sitting there, clicking a menu with a rectangular shape, showing all of 5 icons at a time. Imagine scrolling a folder with 5000 files with SVG icons for each which need rendering and caching. That may improve a little, but there is much more going on than the math behind the SVG. As I summarized, the idea is that there are no *hidden potentially expensive register transfers* which are inserted by the compiler just to service an ABI which is pretty much pointless on the range of processors we're suggesting optimization for. sinf as a function is not a good test: it's one out of many. You layer 50, 100 calls to other FPU functions with more register usage, more float or double argument passing (hey guys try double, hardfp will win every time IMO) and the benefit is compounding. -- Matt -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinig3tlopbwsum3kuo9lmiitydeu7rtnunbl...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
+++ 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, but 4% won't justify a new port from Debian's POV. > > 4% won't, but 30% might? Yes. Exactly. > Or what about the huge gain in povray? That was dramatic. I guess it leads on to the question of how many more really dramatic speedups there are in software people actually use (or would if it was faster :-) I guess we'll find out soon enough. > > It would be interesting to test on some other hardware too, as A8 is > > expected to be the hardware where this makes the most difference, right? > > I have no other hardware nearby,only A8 -well I have remote access to a quad- > core A9, but I haven't yet tried hardfp on it yet as it's not mine to play :) Yes. I was meaning for other people to try stuff as this is such an easy benchmark to run if you've got a browser built. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716142300.gy7...@dream.aleph1.co.uk
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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% won't, but 30% might? Or what about the huge gain in povray? > It would be interesting to test on some other hardware too, as A8 is > expected to be the hardware where this makes the most difference, right? I have no other hardware nearby,only A8 -well I have remote access to a quad- core A9, but I haven't yet tried hardfp on it yet as it's not mine to play :) Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161604.13585.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
+++ 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). 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. > I also ran the Peacekeeper [1] on the system, this is very simplistic, and > produces only a score. Suffice to say, ARM/Arora is nowhere near the top > browsing speeds. > > for softfp: 259 points > > for hardfp: 278 points or 7% speedup. Not bad for just a recompile. It would be interesting to test on some other hardware too, as A8 is expected to be the hardware where this makes the most difference, right? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716123625.gx7...@dream.aleph1.co.uk
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Hello, 2010/7/16 Aurelien Jarno : >> 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 that. If they are some real users of an armv4t port, > we should probably keep it. Yes, openmoko, based on Samsung s3c2410 SoC is armv4t, also my GP32[1] uses same SoC. Is it worth to lose an much more optimized port within Debian for armv7? Things simplify by rebuilding either Debian or Ubuntu with optimized flags over 'armel' architecture as new fork, is that what we all want (nowadays)? [1] http://ajt.iki.fi/travel/debconf5/img_2606-linuxpda_large.jpg Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik9v8vvbc8k5am53ke8wrn2q3cwfqcmr6due...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Martin Guy a écrit : > On 7/16/10, Martin Michlmayr wrote: >> * Aurelien Jarno [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 moving the >> armel port to armv5 and proving optimized libraries for some things >> might be the way to go. > > A company I work with is hoping to be able (finally!) to start > marketing an armv4t board we've been developing over the last years, > with Debian as the default operating system. I guess we can just > remain with lenny or squeeze... > > Being the cheapest ARM boards on the market, these tend to be used by > the long tail of hobbyists, which include potential contributors to > Debian and the OS community. > > 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 that. If they are some real users of an armv4t port, we should probably keep it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c405165.1020...@aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Fri, Jul 16, 2010, Konstantinos Margaritis wrote: > Ok, here are Arora Sunspider (javascript) benchmarks > for softfp: http://bit.ly/a4bS0V > for hardfp: http://bit.ly/9M0OPo -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716120509.gd2...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 would be very interested in an explanation as to why it goes down from 2:44 to 50s by a simple recompile. I also tried other example scenes, it wasn't the exception, rather the rule. If you believe I manipulated the benchmark in some way, feel free to try it yourself, you'll be surprised. Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161458.20900.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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-
raytrace%22:[630,674,659,668,667],%22access-binary-trees%22:[254,254,254,265,245],%22access-fannkuch%22:[404,449,404,402,403],%22access-nbody%22:
[650,745,742,742,741],%22access-nsieve%22:[161,165,158,161,170],%22bitops-3bit-bits-in-byte%22:[125,125,125,125,125],%22bitops-bits-in-byte%22:
[173,171,172,172,173],%22bitops-bitwise-and%22:[172,182,172,181,172],%22bitops-nsieve-bits%22:[358,358,357,357,367],%22controlflow-recursive%22:
[104,103,103,103,103],%22crypto-aes%22:[234,233,233,232,233],%22crypto-md5%22:[269,277,281,268,272],%22crypto-sha1%22:[253,263,262,259,265],%22date-
format-tofte%22:[542,543,547,538,539],%22date-format-xparb%22:[967,953,958,951,958],%22math-cordic%22:[538,613,535,553,534],%22math-partial-sums%22:
[1021,1148,1024,1027,1013],%22math-spectral-norm%22:[296,331,297,299,298],%22regexp-dna%22:[1593,1749,1586,1568,1579],%22string-base64%22:
[433,447,443,437,442],%22string-fasta%22:[631,618,615,621,613],%22string-tagcloud%22:[978,979,979,984,979],%22string-unpack-code%22:
[1267,1273,1267,1271,1269],%22string-validate-input%22:[805,797,802,795,801]}
for hardfp:
http://www2.webkit.org/perf/sunspider-0.9/sunspider-results.html?{%223d-cube%22:[637,709,712,717,716],%223d-morph%22:[977,1003,992,995,992],%223d-
raytrace%22:[618,655,660,654,660],%22access-binary-trees%22:[249,237,243,246,242],%22access-fannkuch%22:[397,396,400,396,396],%22access-nbody%22:
[641,737,753,747,739],%22access-nsieve%22:[156,155,154,155,154],%22bitops-3bit-bits-in-byte%22:[122,123,122,123,122],%22bitops-bits-in-byte%22:
[176,176,174,172,176],%22bitops-bitwise-and%22:[181,175,174,175,175],%22bitops-nsieve-bits%22:[350,357,360,362,360],%22controlflow-recursive%22:
[100,99,100,98,100],%22crypto-aes%22:[227,227,229,228,229],%22crypto-md5%22:[254,253,268,259,265],%22crypto-sha1%22:[258,250,256,254,256],%22date-
format-tofte%22:[487,486,488,485,485],%22date-format-xparb%22:[940,907,914,912,911],%22math-cordic%22:[537,539,537,537,537],%22math-partial-sums%22:
[955,959,971,949,947],%22math-spectral-norm%22:[295,297,299,296,297],%22regexp-dna%22:[1630,1684,1628,1627,1627],%22string-base64%22:
[417,423,426,425,423],%22string-fasta%22:[589,611,587,609,594],%22string-tagcloud%22:[936,944,952,945,940],%22string-unpack-code%22:
[1174,1176,1173,1173,1178],%22string-validate-input%22:[748,740,761,762,753]}
I also ran the Peacekeeper [1] on the system, this is very simplistic, and
produces only a score. Suffice to say, ARM/Arora is nowhere near the top
browsing speeds.
for softfp: 259 points
for hardfp: 278 points
Konstantinos
[1] http://service.futuremark.com/peacekeeper/index.action
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007161456.17593.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > One way to check how well softfp performs would be to run povray in > > Ubuntu versus in Debian; this will mix noise in the results, but I > > don't expect the minor sourceful differences to make the biggest > > impact, but rather the toolchain opts would. (You're speaking of a > > 3-folds increase.) > > I don't have a debian armel installation here, so I can't test how it > performs there, however running the same version on a g...@1ghz running > squeeze -no altivec- I got total runtime 20 seconds, which is imho > indicative of the potential performance of the imx...@800mhz, as the ARM > vfp is much less powerful than the G4's. 20 vs 50, sounds almost expected, > 20s vs ~3min sounds like a joke. 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. Altivec v.s. NEON is a somewhat different question, there's only a 2x difference in peak performance there. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161230.40496.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On 7/16/10, Martin Michlmayr wrote: > * Aurelien Jarno [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 moving the > armel port to armv5 and proving optimized libraries for some things > might be the way to go. A company I work with is hoping to be able (finally!) to start marketing an armv4t board we've been developing over the last years, with Debian as the default operating system. I guess we can just remain with lenny or squeeze... Being the cheapest ARM boards on the market, these tend to be used by the long tail of hobbyists, which include potential contributors to Debian and the OS community. 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? M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimdda6eba-xoinf9bweqatacsnpdcl3wkc4n...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> hardfp 5% faster than softfp > hardfp 3% faster than softfp > hardfp: 5% faster than softfp But these are negligable differences! M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikckbpazt7jtjg7-5cvdnnsdftqiplehaap_...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Fri, Jul 16, 2010 at 09:55:49AM +0100, Martin Michlmayr wrote: > * Aurelien Jarno [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 moving the > armel port to armv5 My impression is the ARMv4t -> ARMV5 doesn't really gain many useful instructions (PLD, CLZ), so it is not neccesarily worth it, at least as long as there ar ARMv4t users (basicly openmoko). > and proving optimized libraries for some things might be the way to go. And when the performance critical code is not in a library but in a binary? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716094141.ga30...@afflict.kos.to
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Hello Loic, 2010/7/16 Loïc Minier : > 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. Excuse me! Do not exclude me from multiarch, I am interested. I just propose that sysroot (supported by upstream) might be the easy working route, while I can see lots of overhead on current multiarch, plus we need upstream support (it might take another 5 years before we see the baby! - but yeah, go for it!) Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilwh2zaub4ve0op4na34r5yx4fmqujhuchrm...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
* Aurelien Jarno [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 moving the armel port to armv5 and proving optimized libraries for some things might be the way to go. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716085549.gi11...@jirafa.cyrius.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 armel as is, add a new armhf hard-float port - keep Debian armel as is, and provide an archive of Debian armel+vfp rebuilt with softfp - keep Debian armel as is, and change a dozen of libs to provide a VFP version (softfp) One way to check how well softfp performs would be to run povray in Ubuntu versus in Debian; this will mix noise in the results, but I don't expect the minor sourceful differences to make the biggest impact, but rather the toolchain opts would. (You're speaking of a 3-folds increase.) archive disttoolchain defaults --- -- Debian armelsid, squeezearmv4t + soft freevec.org karmic armv6 + hardfp Ubuntu armelkarmic armv6 + softfp Ubuntu armeljaunty armv5t + soft Ubuntu armellucid armv7t2 + softfp Would be nice to know against which userspace you ran your povray "softfp". I think povray is a nice example of a random package where we wouldn't put the effort to create a vfp pass, and where there's no lib, so it might indeed be a good example of a hardfp candidate. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716081124.ga21...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 didn't build anything, I just installed the default package from karmic - which as you already said is softfp. > As I understand it, we have these options: > - keep Debian armel as is, add a new armhf hard-float port > - keep Debian armel as is, and provide an archive of Debian armel+vfp >rebuilt with softfp > - keep Debian armel as is, and change a dozen of libs to provide a VFP >version (softfp) Obviously, I vote for the first option :) > One way to check how well softfp performs would be to run povray in > Ubuntu versus in Debian; this will mix noise in the results, but I > don't expect the minor sourceful differences to make the biggest > impact, but rather the toolchain opts would. (You're speaking of a > 3-folds increase.) I don't have a debian armel installation here, so I can't test how it performs there, however running the same version on a g...@1ghz running squeeze -no altivec- I got total runtime 20 seconds, which is imho indicative of the potential performance of the imx...@800mhz, as the ARM vfp is much less powerful than the G4's. 20 vs 50, sounds almost expected, 20s vs ~3min sounds like a joke. -I know ARM is not a cpu fit for rendering, but that's beside the point. > archive disttoolchain defaults > --- -- > Debian armelsid, squeezearmv4t + soft > freevec.org karmic armv6 + hardfp > Ubuntu armelkarmic armv6 + softfp > Ubuntu armeljaunty armv5t + soft > Ubuntu armellucid armv7t2 + softfp > > Would be nice to know against which userspace you ran your povray > "softfp". I did say that, it is a default karmic installation, the efikas come preinstalled with that. Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161134.30040.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 -and some people argued that softfp is equally good and compatible, so instead of a new hardfp port, Debian could just as well enable softfp and get almost as good performance. The existing armel port has its userbase, but now with modern and more powerful ARM cpus around, we should at least examine the potential of a new and more optimized port. Hence the need -at least on our side- of the hardfp port. > What do you call Debian exactly? > > Experience shows that maintainers usually do not care about a new port > until it blocks migration to testing. > > For the release team and ftpmaster point of view, the best is probably > to ask them first. The discussion originated here in this list -and -dpkg- first. I guess when the port is in a semi-working order, we could ask release and ftpmaster, but until then, I'm pretty sure their answer would be "tell us when you have something ready and we'll see if there is demand for this port" or something similar. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161127.37870.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 these options: > - keep Debian armel as is, add a new armhf hard-float port > - keep Debian armel as is, and provide an archive of Debian armel+vfp >rebuilt with softfp > - keep Debian armel as is, and change a dozen of libs to provide a VFP >version (softfp) > > One way to check how well softfp performs would be to run povray in > Ubuntu versus in Debian; this will mix noise in the results, but I > don't expect the minor sourceful differences to make the biggest > impact, but rather the toolchain opts would. (You're speaking of a > 3-folds increase.) > > archive disttoolchain defaults > --- -- > Debian armelsid, squeezearmv4t + soft > freevec.org karmic armv6 + hardfp > Ubuntu armelkarmic armv6 + softfp > Ubuntu armeljaunty armv5t + soft > Ubuntu armellucid armv7t2 + softfp > > Would be nice to know against which userspace you ran your povray > "softfp". > > I think povray is a nice example of a random package where we wouldn't > put the effort to create a vfp pass, and where there's no lib, so it > might indeed be a good example of a hardfp candidate. > OTOH, I am not sure povray is the most use software on ARM... -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c4014e2.7020...@aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Konstantinos Margaritis a écrit : > 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 need to switch to hardfp instead of >> softfp, while only the second one needs a new port? > > No, no, softfp is faster than _soft_, which is, well, irrelevant here. We're > not comparing to soft, we're comparing softfp vs hardfp. The point is that > the > cpus in the particular family are more than able to perform much better than > they are right now, and it's only a case of recompilation. Why are we comparing softfp vs hardfp? We should compare the existing armel port, that is soft, vs both softfp and hardfp. >> Picking the right name is probably lest than 0.0001% of the work... > > Yes, but we seem to get stuck even there. Anyway, assuming we pick a name > that > Debian likes, would Debian assist us and -if successful- eventually adopt the > port? > I'm aware of the hard work needed, but imho, it's more than worth it. > What do you call Debian exactly? Experience shows that maintainers usually do not care about a new port until it blocks migration to testing. For the release team and ftpmaster point of view, the best is probably to ask them first. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c40143b.9040...@aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 need to switch to hardfp instead of > softfp, while only the second one needs a new port? No, no, softfp is faster than _soft_, which is, well, irrelevant here. We're not comparing to soft, we're comparing softfp vs hardfp. The point is that the cpus in the particular family are more than able to perform much better than they are right now, and it's only a case of recompilation. > Picking the right name is probably lest than 0.0001% of the work... Yes, but we seem to get stuck even there. Anyway, assuming we pick a name that Debian likes, would Debian assist us and -if successful- eventually adopt the port? I'm aware of the hard work needed, but imho, it's more than worth it. Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161109.11309.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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), first using the karmic version (built with softfp) and then my own package built using CS compiler (exact same version). I guess gcc- linaro compiler will perform similarly, but I'm still building this. I chose one sample scene from the examples, and ran it on both softfp/hardfp systems with this command: $ povray +V /usr/share/doc/povray/examples/radiosity/radiosity.pov this produced a radiosity.png file, which on both systems has the same md5sum: $ md5sum radiosity.png c0923759c771679a19a0020c3ac7f6e2 radiosity.png which means both versions produced exactly the same result (as they should). if they didn't the benchmark would be qualitative and not quantitative, even if the image appeared to be exactly the same. Now, here are the results (which will shock you as much they have shocked me): softfp: Total Scene Processing Times Parse Time:0 hours 0 minutes 0 seconds (0 seconds) Photon Time: 0 hours 0 minutes 0 seconds (0 seconds) Render Time: 0 hours 2 minutes 45 seconds (165 seconds) Total Time:0 hours 2 minutes 45 seconds (165 seconds) (ran 3 times, always the same result) hardfp: Total Scene Processing Times Parse Time:0 hours 0 minutes 0 seconds (0 seconds) Photon Time: 0 hours 0 minutes 0 seconds (0 seconds) Render Time: 0 hours 0 minutes 50 seconds (50 seconds) Total Time:0 hours 0 minutes 50 seconds (50 seconds) (no that's not a mistake, I also ran this 3 times). Now, do you believe me? Do I have to do a proper "analysis" at the assembly level of every package to show that hardfp beats the crap out of softfp and it _should_ be made into a new port? Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007161104.21368.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 >> hope > > 30% *measured* (vs promised) speed increase is nothing to sneer at on low-end > cpus like Cortex-A8 is. This speed increase might just make the difference > from a jerky movie playback to a fluid one, or it might make desktop > experience just a bit more pleasant -yes, there is a LOT of floating point > work on the desktop (eg. SVG icon rendering). Actually, come to think of it, Have this 30% have actually been measured on such applications? > according to some people here, Debian uses soft (not even softfp) so the > speed > difference of the fp applications of the new port to the *existing* Debian > port (armel) would be HUGE (more than 10x faster, according to my > measurements). It's not a matter of comparing this port to an existing > hardfloat port -like OpenEmbedded or Gentoo, or whatever, it's offering a > better choice for ARM users who want to use Debian. If softfp is already 10x faster, does the additional 30% between softfp and hardfp really worth it? Do we need to switch to hardfp instead of softfp, while only the second one needs a new port? > Anyway, this is beside the point. We're doing it, one way or the other, the > question here is if Debian itself would be interested to accomodate such a > port -if it becomes successful. If one of the steps needed for Debian to do > so > is picking the right name, I'm all for it -in fact I'd go as far as choose > armhf right now, but I'll get back on that a bit later. > Picking the right name is probably lest than 0.0001% of the work... -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c400e9c.7040...@aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 support in > the distribution itself (which really is an overhead) and not in the > upstream code? We need a new port because the binaries are incompatible with each others, we need a different triplet because it's a dpkg limitation. Perhaps we could change dpkg to not require that anymore, but we'd 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. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716074629.gb12...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716074008.ga12...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 a > system in a Debian port, that you will be able to benchmark a > softfp+vfp system running faster than a hard+vfp one, and the features > outlined above in the VFPv3 spec, the ability to judge the benefits of > VFP vs. NEON without compilers generating special magic in the way, > will help people out and make for a "nicer" system. > I think we all agree that in overall hardfp is faster than softfp+vfp. The question is by how much *from the user experience point of view*. I don't doubt Eigen3 is a lot faster, but it's not the kind of software users usually use on their smartphone/tablet/notebook. What users want is a more reactive machine when doing web browsing, document editing, video playing and so on. Keep in mind that creating a new port is a huge work, and from the experience will take a few years. You have to deal with bootstrapping, patching code, deal with maintainers, build daemons, etc. All of that while the code base also evolve as new versions of packages are uploaded. Moreover at the end to get the port accepted as an official one, you have to convince it is really useful. 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. 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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c400c6b.40...@aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 difference between a real analysis and an example. > You chose sinf as an example of a common critical routine and made a big > show of the effect, predicting that softfp would be over a hundred cycles woud be != could be. Obviously not all the vmovs are executed all the time, but there are cases where many of them will run. Some stalls may overlap, leading to a lesser drop in performance, but which _is_ there. Btw, your first reply seems to be missing some text after "However if the value came from memory", I'd be interested to see it completed. > slower (6 instructions * 20 cycle stalls). In reality it's a dozen cycles > either way, with softfp being faster in some circumstances. .. but slower overall, which again has been my point all the time. Anyway, no point arguing, people are able to choose for themselves I think. We (Genesi) are going for a hardfp port, one way or the other. The real question is, assuming we pick a suitable name (armhf), would Debian be interested in helping -and eventually adopting- this port? If not, we're wasting each other's time trying to prove the obvious. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007160840.06623.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > 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? > So, what exactly did you want to prove? Mainly that your analysis of the code was almost entirely bogus. You chose sinf as an example of a common critical routine and made a big show of the effect, predicting that softfp would be over a hundred cycles slower (6 instructions * 20 cycle stalls). In reality it's a dozen cycles either way, with softfp being faster in some circumstances. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007160558.02615.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 gain would be ~20%. Add some more math optimizations, and we end up > to the ~30-35% speed gain we reached. Still don't believe me? Rereading that, I realise this might be misunderstood. The 20% comes from the rotation functions being rather small in size and fast, in fact most of the time wasted in such a function comes from the sinf/cosf calls, it's obviously not the case in bigger functions with lots of calculations where a sinf would only take a miniscule amount of time -eg. software renderers like blender. A gain in sinf() would benefit there as well, but not as much. Though I do intend to measure blender in the future. Anyway, just a clarification. Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007160744.51484.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 sinf()/sec hardfp 5% faster than softfp 0..M_PI/2 hardfp: 2304147.47 calculations of sinf()/sec softfp: 2232142.86 calculations of sinf()/sec hardfp 3% faster than softfp 0..M_PI hardfp: 1949317.74 calculations of sinf()/sec softfp: 1865671.64 calculations of sinf()/sec hardfp: 5% faster than softfp 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 gain would be ~20%. Add some more math optimizations, and we end up to the ~30-35% speed gain we reached. Still don't believe me? Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007160714.17650.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Friday 16 July 2010 00:29:27 Paul Brook wrote: > A simple benchmark confirms this hypothesis. > softfp is actually faster in many cases. 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 change: 23: y[i] = M_PI* i / (float) N; You obviously are knowledgable enough to work a benchmark that works faster on softfp, but you were wrong with sinf (results from time, real value): //x[i] = sinf(y[i]); // hard 15% slower softfp: 0m4.975s, hard: 0m5.222s, hardfp actually 10% slower //x[i] = sinf(y[i]) + 1.0; // hard 5% slower softfp:0m5.341s, hard: 0m5.325s, not really a difference here //x[i] = sinf(y[i] + 1.0); // hard 0.5% slower softfp: 0m6.347s, hard: 0m6.033s, hardfp 5% faster //x[i] = sinf(y[i] + 1.0) + 1.0; // softfp 2.5% slower softfp: 0m6.842s, hard: 0m6.222s, hardfp 10% faster So, what exactly did you want to prove? That softfp is better? yes, in some cases. What about the other cases? Anyway, I'm not discussing if it's better or not, for *our* needs it's more than better, it's the proper way of using an FPU -all arches use it that way, about time ARM starts using it right too. Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007160653.17172.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Hello Loïc, 2010/7/15, Loïc Minier : > 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 upstream triplet names, as Paul comments, but, indeed when transition from OABI to EABI, they did create another triplet (indeed, another architecture: arm-none-linux-gnueabi). 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 support in the distribution itself (which really is an overhead) and not in the upstream code? Best regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim-xugodbysbugdta-zks_s9h9xwxxygaqe5...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
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 are for which cpu, and providing that via debian infra > would not be possible. Having ABI support in dpkg (already discussed on 'armel' port) could had been helpful, indeed, as all the upcoming differences between processors, could make much sense. But is it worth the extra burden of having to implement such support, arriving to consensus and do the needed changes in the archive as well as deal with dependency solvers? Back the, when, at Extremadura [1], when 'armel' was picked up as new architecture, was said that "in Debian a new ABI is a new architecture". Could we have been wrong and should we had instead tried to add ABI field to then control file? Would you, dpkg maintainers, think that it is worth to go through the extra hassle of adding such field without having an implementation, having to change the archive, dependency solvers and achive a consensus among the rest of the community? Might be the right way for long term support (which does not mean it has to happen now). [1] http://wiki.debian.org/DebianEmbeddedWorkSessionExtremadura2006 Best Regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikereidzmsvjqdjrqxzrfc2rc4gpxoyfinvs...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
+++ Matt Sealey [2010-07-15 16:39 -0500]: > Hi Paul > > Please understand we know what we're talking about here :D And so does Paul :-) > In summary: > > soft > * FPU is all emulated. FPU work is done in integer registers. > > softfp+vfp > * actual FPU used, FPU argument passing done in integer registers due > to the soft/softfp EABI spec. your 10x speedup is here and comes from > using the FPU instead of emulating it > * You can use NEON here but you still are limited to passing float > arguments in integer registers per the ABI > * Each register transfer from integer to float register costs about 20 cycles > * Boost in performance from using the FPU or NEON instead of emulation > * Hidden performance penalty from the register transfers > * Compatible with the above - soft and softfp code can be mixed > > > hard+vfp > * actual FPU is used in the same way > * actual FPU code does not run faster > * Boost in performance from using the FPU or NEON is the same > * No hidden performance penalty > * Completely incompatible ABI with the two above - no code mixing. > > > That is what we're proposing. Thanks for that clear and concise summary. > This, coupled with the benefits of > compiling for an improved ISA (ARMv7-A instead of ARMv4) armel (Debian) is actually v4t. v4 was not supported (too hard, only Strongarm thus disenfranchised) > 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 a > system in a Debian port, that you will be able to benchmark a > softfp+vfp system running faster than a hard+vfp one, This remains a crucial question. If Paul is right then maybe it doesn't actually make as much difference as you think. If we have both of these builds then it shouldn't be too hard to measure their relative performances. Ubuntu's existing armel flavour, (with softfp+vfp+thumb2 (v6.5) (I think)) is close to the necesary direct comparison with your hardfp+vfp+ARM port. The arm/thumb2 thing clouds the waters somewhat, and a genuinely equivalent comparison would be good. (I was under the impression that thumb2 was usally faster in practice - you may want to build for that in fact? Although I note the PB is not convinced on that point). > Anyway I think everyone is agreed on that it should be done, just not the > name.. Well, right at the beginning of this discussion a number of people said 'I'd like to see the numbers'. That remains true, and the results will help determine what flavours are woprth maintaining in the long term. But of course in order to do that someone has to build the necessary flavours/ports, so yes please, go for it. We await results with bated breath/ We need some good benchmarks too. https://blueprints.launchpad.net/ubuntu/+spec/arm-m-ui-and-test-heads is relevant to that I guess. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100716001701.gr7...@dream.aleph1.co.uk
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > > > 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 loose 17 cycles, best > > > case we should be ~10 cycles faster. > > > > A simple benchmark confirms this hypothesis. > > softfp is actually faster in many cases. > > > > // uncomment one of these. > > //x[i] = sinf(y[i]); // hard 15% slower > > //x[i] = sinf(y[i]) + 1.0; // hard 5% slower > > //x[i] = sinf(y[i] + 1.0); // hard 0.5% slower > > //x[i] = sinf(y[i] + 1.0) + 1.0; // softfp 2.5% slower > > Hmm, interesting. > > What hardware/CPU/emulator did you test this on? I guess the answers > will vary to some degree depending what it is run on. A beagleboard and an imx51. Looking a bit closer, some of the hard-float lossage may be due to unrelated GCC issues. Most of my analysis still stands though. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007160127.42937.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
+++ 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 loose 17 cycles, best > > case we should be ~10 cycles faster. > > A simple benchmark confirms this hypothesis. > softfp is actually faster in many cases. > > // uncomment one of these. > //x[i] = sinf(y[i]); // hard 15% slower > //x[i] = sinf(y[i]) + 1.0; // hard 5% slower > //x[i] = sinf(y[i] + 1.0); // hard 0.5% slower > //x[i] = sinf(y[i] + 1.0) + 1.0; // softfp 2.5% slower Hmm, interesting. What hardware/CPU/emulator did you test this on? I guess the answers will vary to some degree depending what it is run on. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715235644.gq7...@dream.aleph1.co.uk
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> 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 stalls the entire pipeline until it is complete. > You can't schedule around it. And it does this 6 times. This is nonsense, as I already explained[1]. The hard-float ABI version of sinf actually has more unavoidable stalls than the soft-float ABI. Paul [1] http://lists.debian.org/debian-arm/2010/07/msg00147.html. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007152338.43976.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 that in soft (no FPU at all) and softfp mode (can use FPU) the EABI is defined such that all floating point arguments to a function are passed in integer registers - r0, r1 and so on, and in pairs of registers for double arguments. In the case where FPU instruction generation is enabled (softfp and fpu=vfpv3 for example - softfp abi does not imply an FPU), there is significant code inserted by the compiler that moves data from integer to floating point registers before the FPU can use it. 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 stalls the entire pipeline until it is complete. You can't schedule around it. And it does this 6 times. The basic benefits for moving around are soft * FPU is all emulated. FPU work is done in integer registers. softfp+vfp * actual FPU used, FPU argument passing done in integer registers due to the soft/softfp EABI spec. your 10x speedup is here and comes from using the FPU instead of emulating it * You can use NEON here but you still are limited to passing float arguments in integer registers per the ABI * Each register transfer from integer to float register costs about 20 cycles * Boost in performance from using the FPU or NEON instead of emulation * Hidden performance penalty from the register transfers * Compatible with the above - soft and softfp code can be mixed hard+vfp * actual FPU is used in the same way * actual FPU code does not run faster * Boost in performance from using the FPU or NEON is the same * No hidden performance penalty * Completely incompatible ABI with the two above - no code mixing. That is what we're proposing. This, coupled with the benefits of compiling for an improved ISA (ARMv7-A instead of ARMv4) with better, more efficient instructions, potentially a slightly different strategy for scheduling instructions, and removing the need to run emulated FPU library code by specifying VFPv3-D16 as the base level of FPU required. Using VFPv3-D16 in the base system means not having to deal with Debian multilib just to get FPU code. Everything is FPU enabled by default. Debian multilib would be used to enable extra features such as NEON (which is still not in every ARMv7 processor) and the FP16 extension (which isn't present on any A8) That's what justifies the port, the fact that the ABI is incompatible, plus the baseline architecture requirement (it will no longer run on ARMv4 or ARMv5 .. ARMv6 is possible if you're lucky) plus the baseline FPU requirement (needs VFPv3-D16 at least). Why VFPv3-D16? Simply because VCVT and VMOV immediate has immediate optimization opportunities. Converting between integer and floating point is a very common need (think floor() and ceil() kind of stuff), and being able to put immediate values in FP registers is the first thing you learn when optimizing for AltiVec (vec_splat is your greatest friend!) to reduce the need to access memory which causes pipeline stalls. Because we're used to using AltiVec we think we'd absolutely, positively miss that functionality if we had to be restricted to VFPv2 which does not include them :) No, we don't need to do anything but change the ABI for the purpose of the port, but all the multilib mess of 10 different FPU types, slightly better architectures (5, 6) than the one the port is compiled for.. this is an opportunity to clean it up a bit and reduce the workload by standardizing at the very least to a common denominator (which just happens to be the Marvell ARMADA 500) while running well on Tegra2 and working at still pretty close to best performance possible on Snapdragon and iMX51 and OMAP3. 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 a system in a Debian port, that you will be able to benchmark a softfp+vfp system running faster than a hard+vfp one, and the features outlined above in the VFPv3 spec, the ability to judge the benefits of VFP vs. NEON without compilers generating special magic in the way, will help people out and make for a "nicer" system. Any optimizations made on this "performance blend" of Debian for armv7+hard+vfp when it comes to NEON will backport easily to the "armel" port and work just the same with the same relative improvement, they just won't have the *base* performance of the port.
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > 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 a stall of 20 cycles,
> > how many cycles do we lose in sinf() alone?
>
> Depends how the function is called. Worst case we loose 17 cycles, best
> case we should be ~10 cycles faster.
A simple benchmark confirms this hypothesis.
softfp is actually faster in many cases.
Paul
#include
#define N 100
float x[N], y[N];
void __attribute__((noinline)) foo(void)
{
int i;
for (i = 0; i < N; i++)
{
// uncomment one of these.
//x[i] = sinf(y[i]); // hard 15% slower
//x[i] = sinf(y[i]) + 1.0; // hard 5% slower
//x[i] = sinf(y[i] + 1.0); // hard 0.5% slower
//x[i] = sinf(y[i] + 1.0) + 1.0; // softfp 2.5% slower
}
}
int main()
{
int i;
for (i = 0; i < N; i++)
y[i] = i / (float) N;
for (i = 0; i < 10; i++)
foo();
return 0;
}
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007152229.28361.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> 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 a stall of 20 cycles, > how many cycles do we lose in sinf() alone? Depends how the function is called. Worst case we loose 17 cycles, best case we should be ~10 cycles faster. Remember that mcr (i.e. vmov sX, rX) has zero latency, and the stall only occurs when the value is used. Also remember that any comparison of a floating point value introduces the same latency, whether it be due to copying the value or the condition flags. By my reading teh only problematic instruction is the move os the return value into r0. However this won't actually stall until the value is used. Even if the caller uses the value immediately the rest of the function epilogue should soak up a few cycles of that latency. In general the first use of a function argument could cause a stall if the caller loaded that argument with mrc. However if the value came from memory or was already in core regs (e.g. because it was a function argument/return value). In this case the first significant use of the value is a comparison. As mentioned above this may cause a stall in the soft-float case, but will always cause a stall in the hard-float case. Likewise the stalls on the call to __kernel_sinf ballance each other out - softfp stalls on the return value, hard-float stalls on the argument comparison. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007152126.26819.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 speed that is promised. I > > hope > > 30% *measured* (vs promised) speed increase is nothing to sneer at on > low-end cpus like Cortex-A8 is. Just to reply to myself: 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: on softfp: $ objdump -S /lib/libm.so.6 --start-address= --stop- address=|grep -c vmov 7 on hardfp: $ objdump -S /lib/libm.so.6 --start-address= --stop- address=|grep -c vmov 2 Mind you the 2nd vmov in hardfp version, is this: vmov.f32s16, s0, which definitely does not cost 20 cycles (it's not an mrc instruction). 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? Still not convinced? Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007152233.53440.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > 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 figure a 10x speedup? A fairly conservative guess at the cost of software floating point. Even a dog-slow FPU like on the Cortex-A8 should be at an order of magnitude faster than software. > > about performance then a NEON optimized version of your critical code > > should get you annother 4x or so on a Cortex-A8. > > Yes it's about 4x mathematically but 2x in practice because of the ABI > fudging. Theoretical peak gain is way more than 4x. VFP on the A8 has a peak single precision performance of about 0.1 FLOP/cycle, maybe 0.2 if you enable runfast mode. NEON peak performance is 4 FLOP/cycle. I've seen 2-3x speedup on plain scalar code without even attempting vectorization, so 4x seems fairly realistic given a bit of effort. > >> What would not be so great is that even if it was fixed, the option to > >> use a faster floating point ABI drags in a clone of > >> every package on your system (at the very least, libc, libm, and all > >> the system library dependencies) increasing the > >> size of the installed system. > > > > What you're describing here is multiarch. > > Yes, which is needed anyway to support NEON where it's available. A new port (or arch) is only required if you break the ABI. Enabling NEON has no effect on the ABI. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007152000.08447.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > 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 have precisely two variants. The base ABI, and the VFP ABI. Everything else is binary compatible, and multiarch is almost certainly the wrong answer. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151944.57133.p...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
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 characteristics. [...] > Currently only x86, x86_64, ia64, powerpc and sparc are supported, but > it should not be difficult to add support for more architectures. Unfortunately, this requires getting it in the ARM ABI spec first, and apparently that can take very long, they avoid rev-ing the ABI too frequently (Linaro intends to work on this later this year [1]) [1] https://blueprints.launchpad.net/binutils-linaro/+spec/stt-gnu-ifunc and https://blueprints.launchpad.net/binutils-linaro/+spec/gold-stt-gnu-ifunc -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715183524.ga6...@bee.dooz.org
Re: armelfp: new architecture name for an armel variant
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 particular symbol. A typical example is to select CPU > specific implementations of memcpy. You still need to supply all the > different implementations, and a function to determine which to use. Er, of course I'd have to supply all the implementations, the difference is that there is now a proper and common way to do it -anyone who's checked xine/mplayer/vlc source will know what I mean. Still, it's very good news that something like this has -at last- been implemented. > All the implementations must use the same ABI. Of course. I totally understand that this is not a way to keep softfp/hardfp versions in the same binary. Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007152118.56343.mar...@genesi-usa.com
Re: armelfp: new architecture name for an armel variant
> 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 by the dynamic loader during relocation > > depending on the hardware characteristics. > > > > This avoid building multiple version of the same software (but still > > multiple versions of a given function), and to introduce more > > granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc). > > So, in essence an application/library can include in the same binary > multiple versions of the same function and the system picks one depending > on the current cpu capabilities? So things like autodetecting SSE/Altivec, > etc are not needed anymore? 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 particular symbol. A typical example is to select CPU specific implementations of memcpy. You still need to supply all the different implementations, and a function to determine which to use. All the implementations must use the same ABI. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151906.52610.p...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
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 versions of a given symbol using an IFUNC symbol > > type. This will be resolved by the dynamic loader during relocation > > depending on the hardware characteristics. > > > > This avoid building multiple version of the same software (but still > > multiple versions of a given function), and to introduce more > > granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc). > > So, in essence an application/library can include in the same binary multiple > versions of the same function and the system picks one depending on the > current cpu capabilities? So things like autodetecting SSE/Altivec, etc are > not needed anymore? For libraries sure. I think it might be possible to also get it working for binaries, though I haven't looked more in details. Note that you need a recent toolchain for that (binutils and glibc). > > Currently only x86, x86_64, ia64, powerpc and sparc are supported, but > > it should not be difficult to add support for more architectures. > > I'm interested in that, is it documented somewhere? ( I know the old hwcap > was > not at all, unless one wanted to read half of glibc source code). > I am afraid there are not a lot of documentation, beside the glibc source code. This patch can be interesting though: http://old.nabble.com/indirect-function-support-td28576476.html -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715174325.gt18...@hall.aurel32.net
Re: armelfp: new architecture name for an armel variant
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 by the dynamic loader during relocation > depending on the hardware characteristics. > > This avoid building multiple version of the same software (but still > multiple versions of a given function), and to introduce more > granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc). So, in essence an application/library can include in the same binary multiple versions of the same function and the system picks one depending on the current cpu capabilities? So things like autodetecting SSE/Altivec, etc are not needed anymore? > Currently only x86, x86_64, ia64, powerpc and sparc are supported, but > it should not be difficult to add support for more architectures. I'm interested in that, is it documented somewhere? ( I know the old hwcap was not at all, unless one wanted to read half of glibc source code). Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007152006.42846.mar...@genesi-usa.com
Re: armelfp: new architecture name for an armel variant
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 hwcaps >> infrastructure in a similar way as how packages like libc6-i686 are >> handled. > > The key limitation with hwcap approach is that it only extends to shared > libraries. Optimized binaries and plugins cannot be provided with hwcaps. > Things like libc-i686 are also problematic for endusers. How do I > quickly install all 686 optimized versions of libraries I already have? > 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 by the dynamic loader during relocation depending on the hardware characteristics. This avoid building multiple version of the same software (but still multiple versions of a given function), and to introduce more granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc). Currently only x86, x86_64, ia64, powerpc and sparc are supported, but it should not be difficult to add support for more architectures. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3f3beb.3030...@aurel32.net
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Thu, Jul 15, 2010 at 11:19 AM, Paul Brook 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 moving >> registers around. This sort of came about from Konstantinos' porting >> of the Eigen2 library (after he had done it for AltiVec) >> to NEON and some of the developers noticed it wasn't so much faster >> because gcc inserts what can only be described as >> evil between the start of the function and the real meat of the code. >> The pipeline stalls for register movement are noticable >> in real code as a 20% or higher performance hit. > > Yes, but the point I was responding to is that you don't necessarily need to > use hard-float ABI to get most of the performance gain. I believe Konstantinos when he says we sort of do. I've been working with him on AltiVec stuff for a long while and what performance gains we saw and tested on this (and eventually got picked up by YellowDog Linux) were pretty good. Exactly what you would expect. Using softfp ABI means that the code you expected to run exactly 4x faster, actually can't because there is a significant prologue and epilogue inserted by the compiler which is causing pipeline stalls in register moves. This means the 4x faster code isn't running for most of the lifetime of the function. > I completely agree that if you want to use the hard-float ABI then you need a > new port. > > 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. ... the point is to not support older hardware. We picked a base level: armv7-a and vfpv3-d16 is our target for it. The same way lpia picked the Pentium III core, SSE2 as an FPU and certain other optimizations as the basis for that port. Not only does compiling it for that CPU and the hardfloat ABI level increase performance (instruction set improvements, reduced amount of code) but it should in the same way improve battery life (lpia was reported as a 10% reduction in power usage). 10% on a 90 minute battery for Atom notebooks is not much but we know we can get 6 hours on a Cortex-A8 already with a 2 cell battery. Bump the battery size to 4 cells and it goes up, oddly enough, to about 12 hours. 10% improvement in power usage on 12 hours is an extra hour of battery life, 30 minutes for the smaller sizes, compared to about enough time to put the system into an emergency standby state on Atom and keep the system on suspend current until it reaches an AC adapter. > 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 figure a 10x speedup? > about performance then a NEON optimized version of your critical code should > get you annother 4x or so on a Cortex-A8. Yes it's about 4x mathematically but 2x in practice because of the ABI fudging. >> What would not be so great is that even if it was fixed, the option to >> use a faster floating point ABI drags in a clone of >> every package on your system (at the very least, libc, libm, and all >> the system library dependencies) increasing the >> size of the installed system. > > What you're describing here is multiarch. Yes, which is needed anyway to support NEON where it's available. But we're considering taking a more comprehensive base CPU and FPU requirement and adding a little bit of multiarch (NEON, -fp16) instead of taking the lowest common denominator and adding an entire distro worth of multiarch and not seeing anything like the performance improvement you'd expect. Using the hard float ABI and picking a base level of the ARM architecture means the port is going to run it's best on a certain subset of CPUs which are going into Smartphones and Smartbooks right now - OMAP3, iMX51, iMX53, Snapdragon, Samsung/Apple.. all benefit. Beagleboard, EfikaMX, Nexus One, Tegra2... That it won't run on other CPUs of a lower pedigree, unfortunate, but armel will always still work for them. What you have to do is weigh the advantage of building for last year's base system against the status quo of 15 years ago. In fact, ARM obseleted 90% of the architecture and cores that "armel" runs on. This base level we have chosen is the new base level... (Genesi has a commercial interest on it running on certain ARM926EJ-S cores and a couple ARM11 cores too, and it won't - i.MX27, i.MX37 and Toshiba TMPA910 will be left out. It's not like we're focusing entirely on what we want to do. This is actually going to be a benefit to every modern smartbook processor, basically lpia done right) -- Matt -- To UNSUBSCRIBE, emai
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 are many optimized distros out there, each of them requiring a specific minimum to run, for a reason. It would be impossible or at the very least, extremely hard for them to maintain backwards compatibility, and in the end, what for? Having yet another substandard performance port and read articles about how Gentoo or even Ubuntu beats the crap out of base Debian in speed? (I know Debian is not about speed, but seriously, it doesn't have to be *slow*). > 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. If you're really serious > about performance then a NEON optimized version of your critical code > should get you annother 4x or so on a Cortex-A8. Yes, and we're working on NEON optimizations as well, but that's much harder, as it requires algorithm optimization and not just a simple recompile - autovectorization is a joke. Eg. optimizing NEON took less than a day, but I already knew how it worked as I had done the AltiVec port before, and because it was such a beautiful design. Stuff like zlib took longer -I had to rework the algorithm to paralellize it- and it was useless after all because the license prevents altered binary releases. > 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. It's much easier and less intrusive to the end user to not force upon him all the variants and just have a lean system that does what it promises to do. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151940.02267.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> > 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 > of the Eigen2 library (after he had done it for AltiVec) > to NEON and some of the developers noticed it wasn't so much faster > because gcc inserts what can only be described as > evil between the start of the function and the real meat of the code. > The pipeline stalls for register movement are noticable > in real code as a 20% or higher performance hit. Yes, but the point I was responding to is that you don't necessarily need to use hard-float ABI to get most of the performance gain. I completely agree that if you want to use the hard-float ABI then you need a new port. 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. 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. If you're really serious about performance then a NEON optimized version of your critical code should get you annother 4x or so on a Cortex-A8. > What would not be so great is that even if it was fixed, the option to > use a faster floating point ABI drags in a clone of > every package on your system (at the very least, libc, libm, and all > the system library dependencies) increasing the > size of the installed system. What you're describing here is multiarch. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151719.14372.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Thu, Jul 15, 2010 at 10:26 AM, Paul Brook 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 providing alternative packages builds within the same port. The >> > important point being that (assuming capable hardware) you can freely >> > mix the two. >> >> It sounded so far like you can't. If a library expects softfloat then >> you can't call it from a hardfloat binary since the calling convension >> is different. They are about as compatible as i386 and amd64 in that >> case. Sure both can run on an amd64 kernel and cpu, both can be on one >> system, but they really aren't mixed together. > > Enabling use of VFP does not require use of the hard-float ABI. Please don't > confuse the two. Hi Paul, 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 of the Eigen2 library (after he had done it for AltiVec) to NEON and some of the developers noticed it wasn't so much faster because gcc inserts what can only be described as evil between the start of the function and the real meat of the code. The pipeline stalls for register movement are noticable in real code as a 20% or higher performance hit. It makes the entire process of using an FPU or NEON kind of a chore, to implement an optimization and see all the benefits removed because of the design of the ABI allowing FPU emulation. Your best option is then to force inline everything and hope for the best. I think I pointed out in the wiki, and I think it was Martin who did the test, while the ARM EABI docs say that generated objects from the compiler have the build information embedded into them, and any compiler (including your version :) will refuse to link together softfp and hardfp objects, somehow this information is lost in the translation to ELF, or ld.so does not bother to check, so a hardfp, linked, stripped or unstripped executable can be linked successfully with a softfp linked, stripped or unstripped dynamic shared object. And this causes something approaching you expect a function to work on FPU arguments but the hardfp executable is operating on FPU registers and the softfp library expects it to be in the integer registers. The work is done but they're looking in the wrong places. I think that checking needs to be looked at somewhere, and I think that's something Codesourcery are good at :) Until that fix goes in the only consideration right now is that you shouldn't be able to even install - without a massive warning from the packager - a hardfloat binary on top of a softfloat system or vice versa - since every dependency needs to be compiled using the same ABI. What would not be so great is that even if it was fixed, the option to use a faster floating point ABI drags in a clone of every package on your system (at the very least, libc, libm, and all the system library dependencies) increasing the size of the installed system. If you can guarantee you're running on a system with certain minimum requirements it makes a lot of sense to design the OS to those certain minimum requirements. armel covers the ones that don't match up, and uses softfp to basically bridge the gap between running a system with FPU vs one without, and selecting the FPU capabilities and loading the right libraries as a matter of course. The same will be true of the new port: but VFPv3-D16 is guaranteed, hard float ABI is guaranteed, and things like NEON or fp16 are loaded automatically depending on capabilities. What it does is increases performance while reducing the installed footprint of the system. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilxmuy-u7_gyv0c0yllymtxzb8snomhpatx7...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> 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 point being that (assuming capable hardware) you can freely > > mix the two. > > It sounded so far like you can't. If a library expects softfloat then > you can't call it from a hardfloat binary since the calling convension > is different. They are about as compatible as i386 and amd64 in that > case. Sure both can run on an amd64 kernel and cpu, both can be on one > system, but they really aren't mixed together. Enabling use of VFP does not require use of the hard-float ABI. Please don't confuse the two. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151626.26486.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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) speed increase is nothing to sneer at on low-end cpus like Cortex-A8 is. This speed increase might just make the difference from a jerky movie playback to a fluid one, or it might make desktop experience just a bit more pleasant -yes, there is a LOT of floating point work on the desktop (eg. SVG icon rendering). Actually, come to think of it, according to some people here, Debian uses soft (not even softfp) so the speed difference of the fp applications of the new port to the *existing* Debian port (armel) would be HUGE (more than 10x faster, according to my measurements). It's not a matter of comparing this port to an existing hardfloat port -like OpenEmbedded or Gentoo, or whatever, it's offering a better choice for ARM users who want to use Debian. Anyway, this is beside the point. We're doing it, one way or the other, the question here is if Debian itself would be interested to accomodate such a port -if it becomes successful. If one of the steps needed for Debian to do so is picking the right name, I'm all for it -in fact I'd go as far as choose armhf right now, but I'll get back on that a bit later. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151820.07808.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 ARMv7 without being a Cortex-A > implementation (e.g. QCM snapdragon isn't, Marvell Dove isn't). Hmm, why is arm so complicated. Do they really need 1000 different CPU variants? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715150415.ga2...@caffeine.csclub.uwaterloo.ca
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 minimum CPU, it's a particular implementation. Cortex-A implies ARMv7, but you can be ARMv7 without being a Cortex-A implementation (e.g. QCM snapdragon isn't, Marvell Dove isn't). -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715145829.gb3...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 default, and Debian has some packages which provided alternate version of libraries which are optimized for a different FPU... > As far as the ABI is concerned, the new roposed one specifically uses > VFP registers to pass FP arguments, so the new arch would require a > VFP coprocessor. Yes, armhf requires a VFP, but armel allows using the VFP, so VFP is not very clear. > > (BTW in the thread Richard Earnshaw makes the point that FPA isn't > > leagel in EABI and that maverick is incompatible with it, so I think > > this is another reason not to have "vfp" in our new port's name) > > You must have misunderstood what Richard said. > I use Maverick hardlfoat in EABI and provide a repository of Maverick > hardfloat debian packages for Debian armel. It all works fine. Perhaps your implementation is not officially supported in the EABI then? Please discuss this with Richard though; I know next to nothing about the EABI specification or about maverick fpus. > As regards what ARM Ltd want: Are you speaking on behalf of ARM? > THe users would be best served by a supporting > the least-common-denominator VFP instruction set that runs on as many > chips as possible, which seems to mean a baseline VFP with 16 > registers. The plan is to configure with vfpv3-d16 anyway, and there is no plan to get rid of the armel port... -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715145609.ga3...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 sounded so far like you can't. If a library expects softfloat then you can't call it from a hardfloat binary since the calling convension is different. They are about as compatible as i386 and amd64 in that case. Sure both can run on an amd64 kernel and cpu, both can be on one system, but they really aren't mixed together. > Until someone makes to the effort to define proper EABI supplements for that > coprocessor, I think it's reasonable to call this "not EABI". -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715145423.gz2...@caffeine.csclub.uwaterloo.ca
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> On 7/15/10, Loïc Minier 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. 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. > > (BTW in the thread Richard Earnshaw makes the point that FPA isn't > > leagel in EABI and that maverick is incompatible with it, so I think > > this is another reason not to have "vfp" in our new port's name) > > You must have misunderstood what Richard said. > I use Maverick hardlfoat in EABI and provide a repository of Maverick > hardfloat debian packages for Debian armel. It all works fine. Until someone makes to the effort to define proper EABI supplements for that coprocessor, I think it's reasonable to call this "not EABI". Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007151547.33783.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 custom design which is compatible to the armv7 architecture)
> * (minor) what if ARM releases a "speedex" which is armv7 or armv7
>compatible?
How is that different than i386 works on i686? The name is essentially
the minimum cpu that can run the code.
> "armvfp" is also being put forward; while this seems to make sense,
> armel can also use vfp instructions, so I personally find it confusing.
>
> If we take a step back and ask ourselves why we're doing this new port,
> it's because of a new ABI using hard-float across library calls. Hence
> armhf. It turns out that we also take an opinionated view that armv7
> and vfpv3-d16 are modern choices for the port, so we could indeed use
> armv7hf or armhfvfp to reflect this, but it's ugly.
>
>
> I think there was consensus that {arm,armel}{hf,fp} were reasonnable
> names; I don't care too much across these, but please avoid armv7, vfp,
> cortex in the port name; it's first about a new ABI.
>
>
> Concerning the triplet choice, I'd highly recommend reading this
> upstream thread:
> http://gcc.gnu.org/ml/gcc/2010-07/threads.html#00179
> Upstream is basically split on whether a new triplet is needed or not.
> In any case, we're free to use the vendor field, but that shouldn't be
> used in upstream software. Upstream software should ignore the vendor
> field and detect whether the current ABI is hard-float or soft-float.
> I think changing the triplet is easier than changing the port name, so
> I wouldn't be too worried if the port were to start with
> arm-hardfloat-linux-gnueabi and change to arm-linux-gnueabi_hf or so
> later.
>
> (BTW in the thread Richard Earnshaw makes the point that FPA isn't
> leagel in EABI and that maverick is incompatible with it, so I think
> this is another reason not to have "vfp" in our new port's name)
Too many arm choices... Argh! :)
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100715143534.gx2...@caffeine.csclub.uwaterloo.ca
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On 7/15/10, Loïc Minier 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 concerned, the new roposed one specifically uses VFP registers to pass FP arguments, so the new arch would require a VFP coprocessor. > In any case, we're free to use the vendor field, but that shouldn't be > used in upstream software. +1, if we must have a new GNU name. > arm-hardfloat-linux-gnueabi Would probably work with most existing build scripts > arm-linux-gnueabi_hf Would probably require modifying again every build script that has already been modified to recognize -gnueabi - to make it do the same as it would have done for -gnueabi, which seems like creating pointless extra work for other people... > (BTW in the thread Richard Earnshaw makes the point that FPA isn't > leagel in EABI and that maverick is incompatible with it, so I think > this is another reason not to have "vfp" in our new port's name) You must have misunderstood what Richard said. I use Maverick hardlfoat in EABI and provide a repository of Maverick hardfloat debian packages for Debian armel. It all works fine. You're right that FPA hardfloat won't work with it, because the ABI specifies FP storage format and FPA's storage format is different (45670123 mixed-endian). However, since the new ABI would mandate passing floating point values in VFP registers, that knocks any other incompatible FPUs out of the water anyway. As regards what ARM Ltd want: to stamp their cortex trademark on a Debian port and to get Debian to optimise an architecture for (and mandate the use of) the very latest version of their product line, this is not necessarily in the best interests of the users or the developers of Debian. THe users would be best served by a supporting the least-common-denominator VFP instruction set that runs on as many chips as possible, which seems to mean a baseline VFP with 16 registers. 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 M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbjxslnllwotrsk4zw0_nwpf1u-b2oic8mb...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
+++ 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 liked the idea of having a debian-cortex port.
I don't know who said this but I guess they were marketing people. We
all know that marketing people love naming things in short-termist,
confusing and meaningless ways. Debian tries hard to avoid this. And
the people I just talked to at ARM said 'Oh no, that's just wrong!'
> 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 custom design which is compatible to the armv7 architecture)
> * (minor) what if ARM releases a "speedex" which is armv7 or armv7
>compatible?
>
> "armvfp" is also being put forward; while this seems to make sense,
> armel can also use vfp instructions, so I personally find it confusing.
>
> If we take a step back and ask ourselves why we're doing this new port,
> it's because of a new ABI using hard-float across library calls. Hence
> armhf. It turns out that we also take an opinionated view that armv7
> and vfpv3-d16 are modern choices for the port, so we could indeed use
> armv7hf or armhfvfp to reflect this, but it's ugly.
> I think there was consensus that {arm,armel}{hf,fp} were reasonnable
> names; I don't care too much across these, but please avoid armv7, vfp,
> cortex in the port name; it's first about a new ABI.
Exactly. I am in total agreement with Loic here. I know names is
always contentious and a classic 'bikeshed' issue, but they do also
last a long time and it's important to do the best we can given the
info available at the time.
Obviously Genesi can do whatever the hell they like - we can't stop
them, and indeed don't want to, but please - think carefully about the
above. I was impressed that they came to this list to try and get a
consensus before doing a load of incompatible work - that's excellent,
and the way things should be done, but Matt's last post suggests they
didn't really like the answers received and will go ahead with 'cortex'.
That's much less good. I don't think Debian (or probably Linaro or
Ubuntu) can accept the cortex name for the reasons Loic outlines above
and it'll mean at least names have to be changed before they can
upstream thier patches, which is a pain for everyone, and we won't be
able to just adopt the Genesi port in due course. And they won't
benefit from Linaro, Ubuntu and Debian work in reverse. That's all
bad. Can we really not agree on something basically correct and not
confusing, either now or in the future, i.e 'armelhf' (or 'armhf' if
that's too long).?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100715141335.gf7...@dream.aleph1.co.uk
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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.
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 custom design which is compatible to the armv7 architecture)
* (minor) what if ARM releases a "speedex" which is armv7 or armv7
compatible?
"armvfp" is also being put forward; while this seems to make sense,
armel can also use vfp instructions, so I personally find it confusing.
If we take a step back and ask ourselves why we're doing this new port,
it's because of a new ABI using hard-float across library calls. Hence
armhf. It turns out that we also take an opinionated view that armv7
and vfpv3-d16 are modern choices for the port, so we could indeed use
armv7hf or armhfvfp to reflect this, but it's ugly.
I think there was consensus that {arm,armel}{hf,fp} were reasonnable
names; I don't care too much across these, but please avoid armv7, vfp,
cortex in the port name; it's first about a new ABI.
Concerning the triplet choice, I'd highly recommend reading this
upstream thread:
http://gcc.gnu.org/ml/gcc/2010-07/threads.html#00179
Upstream is basically split on whether a new triplet is needed or not.
In any case, we're free to use the vendor field, but that shouldn't be
used in upstream software. Upstream software should ignore the vendor
field and detect whether the current ABI is hard-float or soft-float.
I think changing the triplet is easier than changing the port name, so
I wouldn't be too worried if the port were to start with
arm-hardfloat-linux-gnueabi and change to arm-linux-gnueabi_hf or so
later.
(BTW in the thread Richard Earnshaw makes the point that FPA isn't
leagel in EABI and that maverick is incompatible with it, so I think
this is another reason not to have "vfp" in our new port's name)
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100715080028.ga2...@bee.dooz.org
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 and those ABI are incompatible, requiring new Debian architectures. > [1] Those paying attention will note that not all pentium cores are i686. > The > Cortex family includes cores that are not armv7 (Specifically armv6-m). M profiles are out of the scope of the port, only A profiles are interesting and maybe R when compatible. While the name does not seem to conflict within Debian. It seems that Ubuntu/Linaro have a problem with it, and too many politics seem to happen. I would like to have a name that suits all of us (not only Ubuntu/Linaro, but any other posible third party). Maybe Ubuntu/Linaro could develop the way arround the naming if it does not suit them? It was said, the one that bootstraps the port, picks the name. Genesi has always been kind to Debian Developers, giving hardware away, and paying people to do the work, they are really commited to Debian at the moment, and it would be nice (from my point of view) to have a Debian port with such characteristics in Debian. I would also like to state that I am (like Debian) commercial independent, nor Genesi pays me, nor Ubuntu/Linaro pays me. My interest is best for Debian community and good support for my prefered gadgets with my prefered distribution. Cheers and have a good day, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikevkckq6flcja5yqfdbdjmzk4w7nkv0hqha...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> 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 common (in terms of chips using it) variant > > of armv7 is the cortex series. If another manufacturer uses their ARM > > license to make a new core design that is compatible, good for them. > > That doesn't stop the official armv7-a/r/m line being Cortex, and for > > the vast majority of people out there to consistently compare the > > armv7 designs they make to the capabilities of the "standard" ARM > > Cortex designs. > > Oh I hadn't realized cortex was an ARM name for that particular feature > set. 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]. Paul [1] Those paying attention will note that not all pentium cores are i686. The Cortex family includes cores that are not armv7 (Specifically armv6-m). -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007150017.59068.p...@codesourcery.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 I can see how it makes lots of sense as the name. > I for some stupid reason thought that was a product name of some ARM > licensee. It's not really a name for a feature set, so much as.. well.. If you go grab a Cortex-A8 (i.e. a CPU) license you probably get as a job lot the libraries to make an ARMv7-A CPU core, the VFPv3, NEON stuff. It's part of the architecture in about the same way as AMD Vision is the Athlon Neo line, and Intel Centrino is anything with CPU/NB/SB/Wireless all from Intel. A brand that lets you know, these features are in there somewhere and you can count on a certain level of functionality within a limited subset of options. You can directly compare Cortex-A8 "branded" processors from different vendors. This helps ARM sell more licenses and gives companies like Genesi the ultimate choice of silicon vendor based on the IP that the silicon vendor adds and not the CPU core itself. We're solid on the fact that the Cortex-A8 and Cortex-A9 are damn nice little CPUs... the choice is in, what graphics is in there with it, does it support MS-CAN, how many SPI buses.. :) The other option is you go get an architecture license which lets you go out and implement the instruction set with your own special pipelines and bus interfaces to the cache and other bolt-ons like custom SIMD units. You lose the ability to say it's a Cortex-A8 but Freescale, Samsung, TI (all cpu licensees) and Marvell, Qualcomm (architecture licensees) have already spoken with 2 years of chips that meet pretty much a standard set of requirements which you can attribute to this grouping of features that ARM have dictated under the banner of their Cortex-A8 brand even if they don't all use it. The silicon vendors are tied in by what each other are doing and how they can do as little software work as possible :) What a Debian port with hard floating point ABI in use might spur (perhaps once all the derivatives catch on, Ubuntu especially as they have their hooks in commercial interests like Adobe) is greater adoption of a better base level of CPU from ARM-licensee silicon vendors. Yes, Marvell Armada 500 and 600 support a different armv7 core (it's licensed but it's not Cortex-A, it's Sheeva P4J) and Qualcomm's Scorpion core is on some kind of performance-enhancing drug, and even Samsung/Intrinsity/Apple's A4 "Hummingbird" is Cortex-A8 with some special power features and a speed bump but they don't advertise it as ANYTHING (it's just a.. you can't please everyone's brand names or feature sets, so we felt it's best to go up to the top level and ask, what do ARM call this selection of features? They are all ARM licensees so, they are in a common group and it does not pander to individual silicon vendors (except perhaps those who took the Cortex brand where it will be more obvious). Who will this benefit most? Right this very second, all of them, with a little more emphasis on ARM who get to make it look like all their processor designs are suddenly 20-40% faster :) In the end this port will not work on every plausible (even if never produced) Cortex-A series variant. Some might not have an FPU - we haven't seen one yet though. But it will work on some other compatible architectures like Scorpion and Sheeva P4J and Hummingbird. This is a matter for documentation in the same way armelhf would have to explain what CPUs this actually encompasses (and what the difference is between arm and armel in the first place). But it will support pretty much everyone to the specifications we've recommended even if they hate that they are not getting their brand name in there :) -- Matt Sealey Product Development Analyst, Genesi USA, Inc. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimndfo2ym9wockfrz0fz3ch1fekxyn8hhrlh...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 common (in terms of chips using it) variant > of armv7 is the cortex series. If another manufacturer uses their ARM > license to make a new core design that is compatible, good for them. > That doesn't stop the official armv7-a/r/m line being Cortex, and for > the vast majority of people out there to consistently compare the > armv7 designs they make to the capabilities of the "standard" ARM > Cortex designs. Oh I hadn't realized cortex was an ARM name for that particular feature set. In that case I can see how it makes lots of sense as the name. I for some stupid reason thought that was a product name of some ARM licensee. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714222114.gu2...@caffeine.csclub.uwaterloo.ca
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 family. Our targets are Cortex A8/A9-class cpus, with at least > vfpv3 and possibly NEON - we'll provide a separate repository with NEON > binaries where that seems appropriate. So, if Marvell/Qualcomm do provide > Cortex A8/A9-type cpus -I don't know really, I'm not following all cpu > models > from every company- then I don't see a problem. If not, then the port would > probably not work on those cpus from these companies anyway. Plain 'armel' > could/should be used in that case. I personally like 'cortex' as it is much clear. Nowadays we still have users that ask what they should use 'arm' or 'armel' and what are their differences. Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikarwjjvjqnjl7c3ws50tszh3jryaribpxh3...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 series. If another manufacturer uses their ARM license to make a new core design that is compatible, good for them. That doesn't stop the official armv7-a/r/m line being Cortex, and for the vast majority of people out there to consistently compare the armv7 designs they make to the capabilities of the "standard" ARM Cortex designs. Right now we're "fighting" over whether we call it armelhf armelfp or whatever else. Sure, they are nice descriptive names but they do not specify which FPU is in use in most case, or revision, or make it known at first glance that it is the "hard" float EABI. The endianness and ABI version are irrelevant, and only got tacked onto the end to differentiate the arm and armel ports where someone made the decision. The Cortex-A series specification - which even Qualcomm and Marvell adhere to on their own cores since armv7 architecture specification defined in that documentation dictates it - that an armv7 CPU has the option to have a VFPv3 FPU and implement the "d16" variant at the very least, and "d32" if you use NEON, however you implemented it. In order to distance the port from the arm and armel ports which will work *absolutely everywhere* under those restrictions placed by the ports (eabi and little-endian in the latter instance) I think "cortex" works, in lieu of calling it something confusing like "armv7" (which IMO ARM screwed up since there is an ARM7 core and an armv7 core (which is actually ARM11 or so) and the difference between a core and a programmer's interface is absolutely irrelevant to a Linux port anyway, so the numbers are just in the way of instantly knowing which one it works on, and you're going to have to document it. How is it worse to say "cortex" which gives a broad indication of where it will work, and the same documentation to say "all processors in ARM's Cortex-A series, plus Qualcomm Scorpion and whatever is in the Marvell Dove"? Marvell and Qualcomm should be happy that someone is actually doing this in the mainstream, regardless of the name. Ubuntu will accept whatever Debian did. In any case, Genesi is going to proceed with a port under this name regardless of a decision by Debian, because we don't want to be involved in the politiking over how many letters and how recursive the acronym is. We consulted with the ARM Cortex-A9 product manager and he likes the idea, gave us a blessing, we're ready to move forward. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. On Wed, Jul 14, 2010 at 4: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 debian-cortex port. > > I suspect the other architecture licensees (Marvell, Qualcomm) might not be so > enthusiastic about this naming... > > Paul > > > -- > To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/201007142233.20904.p...@codesourcery.com > > -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim8w2ujgbhb-crxqugabhjp-wpq5whufcteb...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 named around a > specific vendor. 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 family. Our targets are Cortex A8/A9-class cpus, with at least vfpv3 and possibly NEON - we'll provide a separate repository with NEON binaries where that seems appropriate. So, if Marvell/Qualcomm do provide Cortex A8/A9-type cpus -I don't know really, I'm not following all cpu models from every company- then I don't see a problem. If not, then the port would probably not work on those cpus from these companies anyway. Plain 'armel' could/should be used in that case. > Something vendor neutral like "armfp", > "armel_hardfloat", etc. is much more appropriate (although we should > probably try to make it clear in the vendor name that you need > specific CPU features to fully support it). If 'cortex' for some reason becomes unsuitable, the next option is armelvfp - again to denote that the port is strictly for cpus that do include a vfp (as Matt said before in this list, armelhf though it sounds really nice, it still is not clear whether it supports vfp, fpa, etc.). Regards Konstantinos Margaritis -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007150106.14820.mar...@genesi-usa.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 debian-cortex port. > > 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 named around a specific vendor. Something vendor neutral like "armfp", "armel_hardfloat", etc. is much more appropriate (although we should probably try to make it clear in the vendor name that you need specific CPU features to fully support it). > Paul > > > -- > To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/201007142233.20904.p...@codesourcery.com > > -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin64_hqbm0ew1e6rvudy4ixjnqjnlkznxjia...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 very very wrong. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714214543.gt2...@caffeine.csclub.uwaterloo.ca
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
> 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 (Marvell, Qualcomm) might not be so enthusiastic about this naming... Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007142233.20904.p...@codesourcery.com
cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
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 name. 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. So, thanks all for the comments and the high interest. As Debian Developer I would like to see this port to become an official Debian port someday and have it hosted at debian-ports.org whenever posible. I am really trying my best for this work to be part of the community if community wants it (and it is the right thing to do (TM)), but you also have to understand, that Genesi (always kind and willing to work with Debian community) would like to push this in the best interests of performance for their products present and future. [1] http://lists.linaro.org/pipermail/linaro-dev/2010-July/subject.html [2] http://wiki.debian.org/ArmHardFloatPort -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikdnxa7bu1kqlu6-eidmkntpxhr0nbgci9ni...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
On Tue, Jul 13, 2010 at 11:49:48PM +0200, Hector Oron wrote: > Dear Aurelien, > > 2010/7/13, Aurelien Jarno : > > 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 I can do to help out? It's mostly about buying the hardware and finding a moment to get there (Paris) to do the change. OTOH if we don't add new ports we have enough space. > > Alternatively we can move one port (SH4 ?) to the official Debian > > archive ;-) > > Great! Those are great news! Congrats! Nothing is done, it's just a proposal. SH4 looks the most advanced port of the ones hosted on debian-ports. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713221110.gl18...@hall.aurel32.net
Re: armelfp: new architecture name for an armel variant
Dear Aurelien, 2010/7/13, Aurelien Jarno : > 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 I can do to help out? > Alternatively we can move one port (SH4 ?) to the official Debian > archive ;-) Great! Those are great news! Congrats! Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikylxyuu4hkuarv-rvquuawu8sbbhvkqi5jz...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
Loïc Minier a écrit : > In fact, I chatted with a couple of people about this port, with the > proposal that we should have an ad hoc BoF at Debconf to chose a good > name. > > During these chats, I heard other suggestions around a new port > notably, optimizing for much more recent CPUs such as armv7+. Ubuntu > did see quite a difference by moving all the way up to armv7 + thumb-2. > > Some technical issues to be aware of: > * hard float needs gcc 4.5 or a bunch of patches from 4.4; CodeSourcery >GCC 4.4 (and hopefully soon Linaro GCC 4.4) has these > * hard float is quite a win on Cortex A8, but might be much less so >on A9 -- I think on the long term we want hard float support in a >port > * there's the question of which vfp version we turn on, vfpv3 is not >supported on all armv7 SoCs (e.g. Marvell's Dove only supports >vfpv3-d16) > * some libraries need porting to hard-float, such as libffi and others > 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. Alternatively we can move one port (SH4 ?) to the official Debian archive ;-) -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3c90f8.4050...@aurel32.net
Re: armelfp: new architecture name for an armel variant
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 similar way as how packages like libc6-i686 are > handled. The key limitation with hwcap approach is that it only extends to shared libraries. Optimized binaries and plugins cannot be provided with hwcaps. Things like libc-i686 are also problematic for endusers. How do I quickly install all 686 optimized versions of libraries I already have? > Adding a new (official) architecture variant is a huge overhead for > everyone, it implies adding new porter boxes, patching packages (but > hopefully not many) to handle the new arch, having someone handle the > build daemons, Adding a new arch creates a big overhead for *selected* people, rather than everyone - most packagers in debian are unaffected. Multiple libraries is not exactly zero-effort either, there could easily be hundreds libraries we could want optimized. That is if we want to provide a *good* service to users with VFP's rather than a lipservice. And we still wouldn't have a vfp version of quake2. > The lpia is a great example of an architecture variant that was a > mistake, and should haver never been created. LPIA was mainly a issue since people used it as "if arch=lpia then build mobile ui". That prevented users from installing full versions of software or trying mobile UI's in regular i386 installations. If dpkg had subarchitecture support, lpia wouldn't have been as big a issue. Ubuntu decided to shortcut and not add support for compatible subarchs in dpkg, and the result was what it always is when people make shortcuts... 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 are for which cpu, and providing that via debian infra would not be possible. But the key difference with lpia and hardfloat armel is that they are not binary compatible. And if we use it as a opportunity to target armv7+, do not really share much of hardware either. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713130615.ga14...@afflict.kos.to
Re: armelfp: new architecture name for an armel variant
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 it). > > Yes, this would be nice, by some mechanism or other. It's currently > harder than is helpful. > > You are conflating ABI with optional build/instruction set features. > > Debian arches should be reserved for _incompatible_ ABIs (OABI, EABI > hard-float, EABI softfloat). With/without VFP and cortex A8 > optimisations is not incompatible - it's orthogonal. Each Debian arch > has a _default_ for those (which can change over time as i386 used to > be built for i386, then i486, now i586). It was still i486 last I checked. > Encoding those flavours/build options in the (incompatible ABI) 'Arch' > name is the wrong way to go (IMHO). It's too heavyweight and intrusive and > you get get alphabet soup. We should use other mechanisms to build and > select optimisations and instruction-set extensions (at either > install-time or runtime, maybe both). > > 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 ELF headers and making sure that the loaders and > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch > for every combination. I think there is a difference in instruction set versus calling convention. You should be able to mix binaries with different instruction sets as long as your hardware supports them all. You can't mix binaries with different calling convensions (so where you pass arguments matters). The ABI covers the calling convension, not the instruction set as far as I know. Certainly on i386 you can run i386 and i486 optimized and instruction set binaries on an i686 processor. You can even mix libraries with i486 instructions with programs using i686 instructions. You can't mix them with amd64 binaries and libraries though, because that's a different ABI (fortunately the amd64 kernel supports both ABIs of course). So yeah the tricky bit is picking a name for the ABI without encoding instruction set into it that isn't relevant to the ABI. Arm sure is a big mess with all those incompatible extensions to the instruction set. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712175037.gp2...@caffeine.csclub.uwaterloo.ca
Re: armelfp: new architecture name for an armel variant
> 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 we're trying to get it agreed upstream in advance. If they > say no, then that'll be the end of it, and we'll have to do as you suggest. Any configure script that infers the ABI from the target triplet is fundamentally broken. It is wrong to assume that arm-eabi is soft-float and arm-hf-eabi uses the VFP ABI. We may decide to make this assumption hold within Debian (thought even that is somewhat questionable if you consider multiarch systems), but is definitely not true outside those constraints Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007121547.42159.p...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
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 we're trying to get it agreed upstream in advance. If they say no, then that'll be the end of it, and we'll have to do as you suggest. The only way to reliably determine the current ABI is to ask the compiler, probably checking for a preprocessor macro that doesn't exist yet :-/ We have a bug to fix this: https://bugs.launchpad.net/gcc-linaro/+bug/602745 Once I get to this and push it upstream debian should be able to backport it easy enough, as can anybody else. Andrew -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3b1d32.8090...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
> 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 probably somebody would have to port these anyway. I strongly encourage this solution. 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. The only way to reliably determine the current ABI is to ask the compiler, probably checking for a preprocessor macro that doesn't exist yet :-/ Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007121434.42292.p...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
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 probably somebody would have to port these anyway. >armhf-linux-gnueabi This is wrong. The processor has not changed, and you'd have to handle armv7hf- and many others. Ugh. It's the OS part of the triplet that indicates binary compatibility, so the "proper" way to do it would be something like: arm-linux-gnueabihf Of course, if you want to do it "properly", you need to get upstream approval first, or else you'll find yourself hung out to dry. Also, if a toolchain supports multiple ABIs (such as CodeSourcery SG++ does), then the correct triplet would be whichever is the default configuration. Linaro are also interested in having hard-FP, so they have asked me to start the discussion upstream and get a name agreed. Andrew Stubbs CodeSourcery (currently working with Linaro) -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3b01ed.7030...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
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 will report back ASAP. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712104441.ga6...@bee.dooz.org
Re: armelfp: new architecture name for an armel variant
+++ 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 to deal with that by > > correctly decorating ELF headers and making sure that the loaders and > > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch > > for every combination. > > At the object file level (i.e. static linker) this is already handled by the > EABI object attributes. > > At the executable/shared library level (i.e. dynamic linker) the EABI defines > PT_ARM_ARCHEXT for this purpose. This is not currently implemented by either > binutils or glibc. Right - that's the thing I was thinking it would be helpful to actually fill in as that makes it possible for the linker to prevent you trying to run things you can't run (with better error messages than 'instruction abort') or for it to choose alternative variants. Can we use this feature to mark alternate functions within a binary - e.g. a 'tubby-elf' format version of libm containing both soft-emulation and VFP versions of functions?), or does it apply to the whole binary? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100711133956.gd7...@dream.aleph1.co.uk
Re: armelfp: new architecture name for an armel variant
> 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 ELF headers and making sure that the loaders and > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch > for every combination. At the object file level (i.e. static linker) this is already handled by the EABI object attributes. At the executable/shared library level (i.e. dynamic linker) the EABI defines PT_ARM_ARCHEXT for this purpose. This is not currently implemented by either binutils or glibc. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007111416.47476.p...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
> > 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 ELF headers and making sure that the loaders and > > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch > > for every combination. > > 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? Only if you assume a single set of builds per architecture. There are several ways to allow different variants within the existing architecture port. Ranging from third party repositories, though libc6-i686 type hacks to a new dpkg field to distinguish different builds of the same package. Paul -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007111412.05622.p...@codesourcery.com
Re: armelfp: new architecture name for an armel variant
On 7/11/10, Bill Gatliff 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 pretty much all ARM processors. After all, Debian's tagline is "The Universal Operating System", while cpu-specific tweaking is the speciality of Gentoo, OpenEmbedded and so on. But, since "arm" was already taken, and it used emulated hardfloat instructions instead of softfloat, the main advantage of facing the pain and embarassment of a new port was that it would make FP 11 times faster on all ARM CPUs, as well as permitting use of real FPUs, making it 30 or 40 times faster. That's the difference between encoding a 30-second MP3 in a minute or encoding it in 2 seconds. The argument in favour of yet another ARM Debian arch (making four so far) is the figure of another 30% being waved about. Not another factor of 30, just another 30%, and presumably that figure comes from beating some worst-case situation to death. Actual figures would be nice. > I'm ok with that, actually--- an ecosystem of unofficial "armel" > repositories cropping up containing optimized packages for specific > configurations. Yes. That is the right way to go to leverage FPUs in the Debian framework, and was one of the justifications for the upheavals that the "armel" port caused. Where does this "30%" figure that's been floated around for hardfloat ABI over softfloat ABI with VFP instructions come from? Do we have any actual measurements? Wanting to politick a fourth Debian ARM architecture into dpkg, with all the work that involves for other people, just to get a few percent speed increase in a few packages doesn't seem worth doing. You can get a 3 or 4 times speed increase with an FPU-specific armel repository, which is a mechanism well suited to supporting specific combinations. It doesn't seem worth causing all that pain again just to get an extra 30% of frames per second in glgears. It's an optimization, yes, but look at the cost. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikcay4wm1vgdvnt-irv5b357esxpu6fyebw4...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
> > > 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 ELF headers and making sure that the loaders and > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch > for every combination. > 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? I'm ok with that, actually--- an ecosystem of unofficial "armel" repositories cropping up containing optimized packages for specific configurations. Especially if it's true that Debian won't officially support much more than armeb/armel. b.g. -- Bill Gatliff b...@billgatliff.com
Re: armelfp: new architecture name for an armel variant
+++ 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 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 it). > I don't see them all becoming official Debian ports, but it would be awfully > nice to someday have several repositories to choose from depending on whether > you want least-common-denominator Debian for ARM, packages that have been > built > with compiler optimizations for Cortex A8, or XScale, or whatever. And then > big/little-endian, EABI/OABI, SMP, and whatever else comes along later. Yes, this would be nice, by some mechanism or other. It's currently harder than is helpful. > I think the howls of maintenance protest are somewhat justified, but you just > can't go wrong with names like "arma8vfpel", "arm920tel", and so on. > > It would be really cool if we could find a way to make it easy to launch a > buildd to create packages for, say, "A8 with VFP and EABI", You are conflating ABI with optional build/instruction set features. Debian arches should be reserved for _incompatible_ ABIs (OABI, EABI hard-float, EABI softfloat). With/without VFP and cortex A8 optimisations is not incompatible - it's orthogonal. Each Debian arch has a _default_ for those (which can change over time as i386 used to be built for i386, then i486, now i586). Encoding those flavours/build options in the (incompatible ABI) 'Arch' name is the wrong way to go (IMHO). It's too heavyweight and intrusive and you get get alphabet soup. We should use other mechanisms to build and select optimisations and instruction-set extensions (at either install-time or runtime, maybe both). 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 ELF headers and making sure that the loaders and dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch for every combination. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100711024016.gb7...@dream.aleph1.co.uk
Re: armelfp: new architecture name for an armel variant
> > > 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 later. For example, I'm glad we dropped "arm" because it tells me very little in detail about _which_ ARM machines are supported. And there aren't a lot of people you can ask about stuff like that who have a truly informed answer. I don't see them all becoming official Debian ports, but it would be awfully nice to someday have several repositories to choose from depending on whether you want least-common-denominator Debian for ARM, packages that have been built with compiler optimizations for Cortex A8, or XScale, or whatever. And then big/little-endian, EABI/OABI, SMP, and whatever else comes along later. I think the howls of maintenance protest are somewhat justified, but you just can't go wrong with names like "arma8vfpel", "arm920tel", and so on. In an ideal world, I would prefer we go that route. To me, names like "armel" are just too generic to be meaningful. I'm speaking from the perspective of someone who uses Debian (and emDebian) across the full range of ARM machines. For embedded applications, mostly. So the clarity is important to me, even if the names are somewhat inconsistent with the tidy, generic names that Debian uses for its architectures now. It would be really cool if we could find a way to make it easy to launch a buildd to create packages for, say, "A8 with VFP and EABI", and the package scripts somehow tolerate a new ARM-based arch name that they haven't seen before because I'm the first guy to try to optimize for a certain machine. b.g. -- Bill Gatliff b...@billgatliff.com
Re: armelfp: new architecture name for an armel variant
Hello, 2010/7/10, Hector Oron : > 2010/7/10, Martin Guy : >> 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, > please expand. Rethinking on the name, Debian already has 3 names (arm, armel, armeb). There is real use of two out of the three, but soon, there only be one of current use. If we had picked generic names, maybe nowadays, we could change 'armeb' defaults to another setup. The same will happen soon with 'arm'. 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? -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilfnxhysvs3eajhuls5n3tc9nra55csrm15s...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
Hello, 2010/7/10, Martin Guy : > 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, please expand. > Sorry, I didn't mean that literal string, I meant changes to build > scripts where the architecture name is fished out and matched against > a pattern beginning with "arm", for example in shell script case > statements or in Makefiles using that awful "findstring" syntax. Like toolchain packages, those need patching. It might be wise to add arm* instead "arm armel armeb" in some cases, where it fits. > Even once the bootstrapping is done, adding a new architecture to > Debian is a lot of work. I know, but what should we do? Step back and use another distro for hardfloating point? I think we are more than enough "capable" people interested to bring this port to Debian. BTW, thanks for the hints. -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilbuyblljc3jrkl_htcabrnfrirqllbnfozc...@mail.gmail.com
