Re: default CPU target for ix86 based ports
On Thu, 2003-08-07 01:13:18 +0200, Matthias Klose <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Marcus Brinkmann writes: > > On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote: > > > IIRC the Hurd can be built for i586 only, so it could be used as the > > > default target CPU as well. > > > > We only require a coprocessor, but anything < i586 doesn't make much sense > > at all at this stage. So no problem on our side. > > so make -mcpu=i586 -mtune=i686 the default? anything else as the default? -mcpu=i386 -mtune=i486, at least for Linux based targets:-) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); pgpKy1dg7DVVZ.pgp Description: PGP signature
Re: default CPU target for ix86 based ports
On Thu, 2003-08-07 00:48:04 -0400, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Thu, Aug 07, 2003 at 06:43:35AM +0200, Jan-Benedict Glaw wrote: > > On Wed, 2003-08-06 23:08:22 +0200, Matthias Klose <[EMAIL PROTECTED]> > > wrote in message <[EMAIL PROTECTED]>: > > > Jan-Benedict Glaw writes: > Suggest you read the list archives before raising this discussion > again. It had nothing at all to do with optimization, either ours or > theirs. However, that's what I got out of it. OTOH, -march and -mtune = i386 would break Pentium-IV and Athlons, wouldn't it? Why not stick to that? MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); pgpO661weFEby.pgp Description: PGP signature
Re: default CPU target for ix86 based ports
On Wed, 2003-08-06 17:22:19 -0400, Ben Collins <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Wed, Aug 06, 2003 at 11:08:22PM +0200, Matthias Klose wrote: > > Jan-Benedict Glaw writes: > > Someone is making statements without knowing the real situation. > Changing to hwmul ops in libc and other key libraries makes a _huge_ > difference. Just for libssl alone it makes an UltraSPARC sshd server go > from 5 seconds for a login, to almost instant. But if you start using that libssl on a hwmul-less system, it'll get even worse there, won't it? So the slow ones get slower and the fast ones get faster. > This decision for sparc wasn't made just for the fuck of it. It actually > has a purpose. You call it broken, I call it "older hardware is no > longer supported in order to benefit newer machines". Sooner or later Thanks for that statement. I think this one is _really_ honest and describes the situation - more-or-less even for i386. > the shit has to happen. Supporting sun4m-hwmul means we are still > supporting machines that are almost 20 years old. I'd say that's pretty > damn good. Well, kernel already patches .mul and .div - can't something like that be done in userspace, too? So a given app would neither need to do softmath all the time (while the CPU could do hwmath) nor take an extra penalty if it's compiled to use hwmath and need to emulate all the way. Is there enough room in the ABI to implement something like this? (...and yes, there are some sparcs in my cellar...) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); pgpoaOstzlLkD.pgp Description: PGP signature
Re: default CPU target for ix86 based ports
On Wed, 2003-08-06 15:52:31 -0400, Nathanael Nerode <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jan-Benedict Glaw said: > >...and up to now, I haven't seen real hard numbers that show that > >optimizing for i486 does really make anything noticeable faster. From > > I've given such numbers for the use of i486 instructions. The speed > increase applies to specific applications only and is quite large in > those applications. I don't think there is any significant use of the That's what I expected:) > Making the emulator available for the latest kernel is certainly > important. Volunteering? ;-) Yes - currently in Oopsing state:) > >Maybe we'd go another way and build two distributions - i386 as well as > >i486 or i586. I bet there are still i386 machines out there, but > Feel free; this appears to have been rejected by the Debian project in > favor of the emulator. (I can certainly understand why, since it's a > lot easier!) Well, I'm fully behind that. Don't get me as the "there's only i386 out there and some small number of Pentium+ machines" man. I *know* that it's the other way around. Would Debian accept two ix86 distributions? One i386 and, say, i[56]86? I'd even volunteer to rebuild all the packages... What's needed for that? Basically some changes to dpkg --print-architecture, if I'm right... As well as changing a number of configure statements... MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); pgpJyiky6xyRB.pgp Description: PGP signature
Re: default CPU target for ix86 based ports
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes: > Am I wrong or did we, "forced" because we wanted to be binary compatible > to some major distributions, just follow others and doing optimization > just as they did? You are wrong. There are two versions of atomicity.h, one for i486+, and the other for i386+ (at the time the other distributors released their compilers, there was only the i486+ version, and it was assumed to work for i386+, but didn't). The two versions are binary-incompatible, providing the same feature using entirely different data structures. As everybody else is using the i486+ version (given that no other version existed when they released their systems), Debian needs to follow, for binary compatibility. Regards, Martin
Re: default CPU target for ix86 based ports
On Thu, 2003-08-07 07:58:01 +0200, Martin v. Löwis <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jan-Benedict Glaw <[EMAIL PROTECTED]> writes: > > Am I wrong or did we, "forced" because we wanted to be binary compatible > > to some major distributions, just follow others and doing optimization > > just as they did? > > You are wrong. There are two versions of atomicity.h, one for i486+, > and the other for i386+ (at the time the other distributors released > their compilers, there was only the i486+ version, and it was assumed > to work for i386+, but didn't). The two versions are So we now suffer from a former bug? > binary-incompatible, providing the same feature using entirely > different data structures. As everybody else is using the i486+ > version (given that no other version existed when they released their > systems), Debian needs to follow, for binary compatibility. Debian is constantly recompiling it's packages (at least for unstable), and I assume other distributors are doing basically the same. As we already had (official) ABI changes (C++ comes to mind again) and where now a (hopefully correct) i386 version is available, can't we all (Debian and non-Debian) do as we did it the last time (TM)? However, thanks a lot for your explanation, I was under the impression that it was exactly the other way around (i386 version first, then i486 version). After all argueing/ranting, there seem to be two outcomings. Either have an own i386 distro or work on the emulator (for 2.6.x). I've started with the emulator, but it doesn't work yet. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); pgpoGMmMFCvLj.pgp Description: PGP signature
Re: default CPU target for ix86 based ports
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes: > > You are wrong. There are two versions of atomicity.h, one for i486+, > > and the other for i386+ (at the time the other distributors released > > their compilers, there was only the i486+ version, and it was assumed > > to work for i386+, but didn't). The two versions are > > So we now suffer from a former bug? Yes and no. We see the effects from a former bug, but we are not suffering (atleast, I'm not :-) This bug went unnoticed (or unreported) for several GCC releases, which hints as how widely i386 machines are still used with current software... > Debian is constantly recompiling it's packages (at least for unstable), > and I assume other distributors are doing basically the same. As we > already had (official) ABI changes (C++ comes to mind again) and where > now a (hopefully correct) i386 version is available, can't we all > (Debian and non-Debian) do as we did it the last time (TM)? Unfortunately, the LSB and other relevant specs are silent on this specific issue. Most other vendors support only i586+, anyway, and would not agree to a change that would require them to recompile, yielding binary incompatibility with earlier versions of their own releases. > After all argueing/ranting, there seem to be two outcomings. Either have > an own i386 distro or work on the emulator (for 2.6.x). I've started > with the emulator, but it doesn't work yet. Indeed. Regards, Martin
Re: default CPU target for ix86 based ports
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes: > Would Debian accept two ix86 distributions? One i386 and, say, i[56]86? Most developers probably would, if presented with a sound plan that makes that happen and has no downsides (except for the obvious one that ftp archives will need more space). One issue is to consider whether the current i386 distribution "becomes" the i586 distribution (which most people probably would agree it should), and if so, how to migrate all existing installations (which people would prefer to not touch at all), and, if the architecture name "i386" really indicates "i586+" in 2003, then what name should the i386-proper architecture use? > I'd even volunteer to rebuild all the packages... What's needed for > that? That is part of the problem. Somebody would need to identify all necessary changes in advance, convince people, and in general "make it happen". No such volunteer has materialized, and any potential volunteer should expect not only technical but also social challenges. Regards, Martin
Re: default CPU target for ix86 based ports
Jan-Benedict Glaw writes: > Would Debian accept two ix86 distributions? One i386 and, say, i[56]86? No, unless you can explain why you need to run KDE, eclipse and openoffice on an i386. This has to be a subset due to bandwidth and disk limitations. > I'd even volunteer to rebuild all the packages... What's needed for > that? Basically some changes to dpkg --print-architecture, if I'm > right... As well as changing a number of configure statements... rebuilding is not the problem. come up with a plan to introduce the new architecture and how packages can be built for both archs without many changes to the packaging. prove your plan by setting up a mini-archive of such a restricted/subset architecture. If you have to make changes to packages collect these patches and submit these as bug report after your plan has been accepted (at least that's the way, how the amd and bsd ports did it). Maybe you should move the discussion to some other list, maybe -devel. Matthias
Re: default CPU target for ix86 based ports
On Thu, 2003-08-07 08:34:37 +0200, Matthias Klose <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jan-Benedict Glaw writes: > > Would Debian accept two ix86 distributions? One i386 and, say, i[56]86? > > No, unless you can explain why you need to run KDE, eclipse and > openoffice on an i386. This has to be a subset due to bandwidth and > disk limitations. Personally, I don't really care for that monster applications. But having apt-get would be nice, especially on a Debian system:) > > I'd even volunteer to rebuild all the packages... What's needed for > > that? Basically some changes to dpkg --print-architecture, if I'm > > right... As well as changing a number of configure statements... > > rebuilding is not the problem. come up with a plan to introduce the > new architecture and how packages can be built for both archs without > many changes to the packaging. prove your plan by setting up a Thinking about it... Seems I'll soon learn something about Debian's real internals... MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA)); pgpx7qKHSDuBN.pgp Description: PGP signature
[Bug target/11716] [mips] branch out of range when building fold-const.c
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11716 --- Additional Comments From rsandifo at redhat dot com 2003-08-07 18:24 --- Subject: Re: New: [mips] branch out of range when building fold-const.c "debian-gcc at lists dot debian dot org" <[EMAIL PROTECTED]> writes: > when building a mips-linux -> mips64-linux crosscompiler current gcc > creates assembler code as can't handle (Branch out of range) > The exact error messages is attached. Same happens with HEAD 20030722. Which assembler are you using? Richard --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Bug target/11716] [mips] branch out of range when building fold-const.c
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11716 rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2003-08-07 19:49:03 date|| --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Bug target/11716] [mips] branch out of range when building fold-const.c
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11716 --- Additional Comments From doko at cs dot tu-berlin dot de 2003-08-07 22:10 --- Subject: Re: [mips] branch out of range when building fold-const.c rsandifo at redhat dot com writes: > Which assembler are you using? binutils-2.14.90.0.5 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
gcc-3.3_3.3.1ds3-1_sparc.changes ACCEPTED
Accepted: cpp-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/cpp-3.3_3.3.1-1_sparc.deb fastjar_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/fastjar_3.3.1-1_sparc.deb fixincludes_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/fixincludes_3.3.1-1_sparc.deb g++-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/g++-3.3_3.3.1-1_sparc.deb g77-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/g77-3.3_3.3.1-1_sparc.deb gcc-3.3-base_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/gcc-3.3-base_3.3.1-1_sparc.deb gcc-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/gcc-3.3_3.3.1-1_sparc.deb gcj-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/gcj-3.3_3.3.1-1_sparc.deb gij-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/gij-3.3_3.3.1-1_sparc.deb gnat-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/gnat-3.3_3.3.1-1_sparc.deb gobjc-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/gobjc-3.3_3.3.1-1_sparc.deb gpc-2.1-3.3_3.3.1.20030507-1_sparc.deb to pool/main/g/gcc-3.3/gpc-2.1-3.3_3.3.1.20030507-1_sparc.deb lib64gcc1_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/lib64gcc1_3.3.1-1_sparc.deb lib64stdc++5_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/lib64stdc++5_3.3.1-1_sparc.deb libffi2-dev_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libffi2-dev_3.3.1-1_sparc.deb libffi2_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libffi2_3.3.1-1_sparc.deb libg2c0_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libg2c0_3.3.1-1_sparc.deb libgcc1_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libgcc1_3.3.1-1_sparc.deb libgcj-common_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libgcj-common_3.3.1-1_sparc.deb libgcj4-dev_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libgcj4-dev_3.3.1-1_sparc.deb libgcj4_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libgcj4_3.3.1-1_sparc.deb libobjc1_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libobjc1_3.3.1-1_sparc.deb libstdc++5-3.3-dbg_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libstdc++5-3.3-dbg_3.3.1-1_sparc.deb libstdc++5-3.3-dev_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libstdc++5-3.3-dev_3.3.1-1_sparc.deb libstdc++5-3.3-pic_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libstdc++5-3.3-pic_3.3.1-1_sparc.deb libstdc++5_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/libstdc++5_3.3.1-1_sparc.deb protoize_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/protoize_3.3.1-1_sparc.deb treelang-3.3_3.3.1-1_sparc.deb to pool/main/g/gcc-3.3/treelang-3.3_3.3.1-1_sparc.deb Thank you for your contribution to Debian.
Re: default CPU target ix86 based ports
Matthias Klose wrote: >Marcus Brinkmann writes: >> On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote: >> > IIRC the Hurd can be built for i586 only, so it could be used as >the >> > default target CPU as well. >> >> We only require a coprocessor, but anything < i586 doesn't make much >sense >> at all at this stage. So no problem on our side. > >so make -mcpu=i586 -mtune=i686 the default? anything else as the >default? Just to clarify, that would be the default for *hurd* only, right? There's no good reason to drop 486 support under Linux. So for Linux, it would be -mcpu=i486 -mtune-i686 as the default, correct? -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
