Am Montag, 8. Oktober 2012, 11:49:35 schrieb Alexander Graf:
On 08.10.2012, at 11:46, Adrian Schröter wrote:
Am Montag, 8. Oktober 2012, 11:30:24 schrieb Guillaume Gardet:
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote: > Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: > ... >>>>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. >>>> Or at least make a sym link as a workaround. >>> We have currently a broken rpm package on armv5, I bootstrap i currently manually. >>> Afterwards we need to do a clean rebuild, so please do not add workarounds until >>> we tried that. >>> >>> I hope it solves the problem. >>> >> Ok. Ping us when it can be tested. > checking this again, using armv5 without thumb would make us quite special. Debian > and Fedora are using both thumb. And ubuntu gave up on v5 at all. > > So, I really wonder if the decision to not use thumb on v5 is really the right one > or if we should revisit this. > I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness.
I think it is a good idea.
okay
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it.
Yes. We just save space since compiled code is smaller. So, I would not enable it.
However, that means that we use a different default than built-in of gcc and used by other distros. Do you think this speedup is it really worth to become different here?
Are you sure? Please double-check. I very much doubt that anyone else builds thumb-1 code.
Okay, you are right, they don't use it. However they also do not explicit set --with-mode=arm So, the assumption that the t in armv5tel is for thumb mode is wrong? Anyone knows what it means exactly?
And also the cpu/arch short name does not 5tel as we use it means thumb mode. And we would need to patch a number of packages, including rpm to introduce the armv5el architecture ...
We can call it armv5tel and compile ARM mode code, no? IIUC that's what the other distros do.
Seems so. So we may should rename the OBS scheduler architecture to armv5tel for completeness, but that is cosmetic. And I would like to know what the t means for officially. So, we just need to switch armv7 thumb on now in gcc by using --with-mode=thumb configure switch again. And disable it explicit for libgcj47 build. Right? thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org