Re: Bug#198158: architecture i386 isn't i386 anymore
On Mon, 30 Jun 2003 18:17:57 +0200 Karsten Merker <[EMAIL PROTECTED]> wrote: > > I think ports to other kernels are generally worthwhile in and of > > themselves, simply for cleaning up the codebase and getting rid of > > unportable stuff. > > > > It's just plain old healthy is all. The previous comment about it was > > just meant in an informative manner is all. (I've never heard of a > > "Turbochannel" machine either, so I won't bother looking into it.) > > TurboChannel is a 32bit bus system used in Digital Equipment systems like > the MIPS-based DECstation series and the Alpha-based DEC 3000 series. The > former (at least some models) is supported by Linux/MIPS (and Debian/MIPS) > as well as by NetBSD/OpenBSD, the latter is only supported by *BSD. Thanks :) pgpS2MBhvRyC8.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 29, 2003 at 02:13:48PM -0400, Nathan Hawkins wrote: > On Thu, Jun 26, 2003 at 04:24:23PM -0400, Matt Zimmerman wrote: > > On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote: > > > > > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: > > > > ports - NetBSD gives us the potential to bring Debian to _many_ new > > > > platforms. > > > > > > It's not that many actually. The only CPU that NetBSD claims to support > > > but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 > > > aren't really useable unlike their NetBSD counterparts. > > > > However, NetBSD doesn't run on IA64 or S/390 as far as I know, while Debian > > does. > > Of course, FreeBSD (5.0) does run on IA64, so I suspect it won't be that > long before NetBSD has a port to it. I also recall seeing that people > are in the process of porting both FreeBSD and NetBSD to S/390. Not to mention a (reasonably close to?) working amd64 port (recently renamed). -- Joel Baker <[EMAIL PROTECTED]> pgpllBGNSltA2.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sat, 28 Jun 2003 15:53:56 -0600 Joel Baker <[EMAIL PROTECTED]> wrote: > > No it doesn't. I've yet to even hear of an architecture that NetBSD runs > > on but which Linux doesn't. They just have a different definition of > > "architecture" than us. (ie: our "hppa" may be three or four arches to > > the NetBSD kernel folk.) > > There are a couple. I don't think most people care about any of them, > right now (and quite possibly never will, in the case of old VAXen, > for example). There's a working VAX port including a relatively complete driver set, at least, so that's not one. :) But, regardless; > In discussing it the other day, I actually found a concise way to > express one of the major reasons I choose to work on the port and find > it worthwhile: I think ports to other kernels are generally worthwhile in and of themselves, simply for cleaning up the codebase and getting rid of unportable stuff. It's just plain old healthy is all. The previous comment about it was just meant in an informative manner is all. (I've never heard of a "Turbochannel" machine either, so I won't bother looking into it.) pgp0LjEdvp7zM.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 04:24:23PM -0400, Matt Zimmerman wrote: > On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote: > > > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: > > > ports - NetBSD gives us the potential to bring Debian to _many_ new > > > platforms. > > > > It's not that many actually. The only CPU that NetBSD claims to support > > but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 > > aren't really useable unlike their NetBSD counterparts. > > However, NetBSD doesn't run on IA64 or S/390 as far as I know, while Debian > does. Of course, FreeBSD (5.0) does run on IA64, so I suspect it won't be that long before NetBSD has a port to it. I also recall seeing that people are in the process of porting both FreeBSD and NetBSD to S/390. ---Nathan
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote: > No it doesn't. I've yet to even hear of an architecture that NetBSD runs > on but which Linux doesn't. pc532 > They just have a different definition of > "architecture" than us. (ie: our "hppa" may be three or four arches to > the NetBSD kernel folk.) Yupp. But under this different arch concepts there's also hidden lots of hardware supported by only either NetBSD or Linux even if the CPU is supported by both..
Re: Bug#198158: architecture i386 isn't i386 anymore
Christoph Hellwig wrote: >On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: >> ports - NetBSD gives us the potential to bring Debian to _many_ new >> platforms. > >It's not that many actually. The only CPU that NetBSD claims to support >but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 >aren't really useable unlike their NetBSD counterparts. It depends a bit on your definition of platform - NetBSD supports the Turbochannel Alphas while Linux doesn't, for instance. There's various chunks of architectures that are better supported by one than the other. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote: > On Wed, 25 Jun 2003 14:04:54 -0500 > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > And not only 80386 needs this - There is the Sparc64 port which would > > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we > > had support for subarchtectures, not only would the ix86 mess be able to > > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever > > you fancy). And I am sure this can somehow help maintain the non-Linux > > ports - NetBSD gives us the potential to bring Debian to _many_ new > > platforms. > > No it doesn't. I've yet to even hear of an architecture that NetBSD runs > on but which Linux doesn't. They just have a different definition of > "architecture" than us. (ie: our "hppa" may be three or four arches to > the NetBSD kernel folk.) They support the vax, and openbsd (nearly) supports the m88k. The others look (to me, I didn't look very hard) like their CPUs are supported Frank
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > had support for subarchtectures, not only would the ix86 mess be able to
> > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
> > you fancy). And I am sure this can somehow help maintain the non-Linux
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms.
>
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't. They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the NetBSD kernel folk.)
There are a couple. I don't think most people care about any of them,
right now (and quite possibly never will, in the case of old VAXen,
for example).
In discussing it the other day, I actually found a concise way to
express one of the major reasons I choose to work on the port and find
it worthwhile:
NetBSD's motto is "Yes, it runs NetBSD".
NetBSD other motto is "correctness above all" (by comparison, OpenBSD is
"security above all", FreeBSD is "features above most", and Linux would
probably be "bleeding edge above most").
Sort of like Debian's release schedule is "when it's ready", and for the
same reasons.
Their -current is more or less like our unstable ("It may break, but people
always scream at us when it does so for any significant length of time").
They don't release fast (other than security patches), but they do have a
good history of their releases being rock-stable.
--
Joel Baker <[EMAIL PROTECTED]>
pgpVPPhefbfAy.pgp
Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
Hi, On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote: > On Wed, 25 Jun 2003 14:04:54 -0500 > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > And not only 80386 needs this - There is the Sparc64 port which would > > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we > > had support for subarchtectures, not only would the ix86 mess be able to > > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever > > you fancy). And I am sure this can somehow help maintain the non-Linux > > ports - NetBSD gives us the potential to bring Debian to _many_ new > > platforms. > > No it doesn't. I've yet to even hear of an architecture that NetBSD runs > on but which Linux doesn't. They just have a different definition of > "architecture" than us. (ie: our "hppa" may be three or four arches to > the NetBSD kernel folk.) Turbochannel machines? VAXen? Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: [proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)
On Thu, Jun 26, 2003 at 08:29:41PM -0500, Adam Heath wrote: > On Thu, 26 Jun 2003, Michael Banck wrote: > > > Also, please note that at least half of the dpkg-maintainers don't read > > -devel, you probably want to post this to -dpkg. Incidently, there is a > > proposal and patch by Gerhard Tonn for handling lib64 under > > discussion[2]. > > Well, considering there are most likely only 2 dpkg maintainers(of which I am > one), and I read your mail, does that mean the other isn't on this list? :) Wiggy told me multiple times that the only debian list he was on was -dpkg (and probably -devel-announce) these days. Perhaps he changed his mind recently, dunno. Michael
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 27, 2003 at 02:08:46PM -0400, Nathanael Nerode wrote: > >* what opcodes need to be emulated? > > >* all 386->486 opcodes (there's just a few of them, right?) > This is the correct answer. :-) Then all programs can be compiled with > gcc --arch=i486 --tune=i686 (which should probably be mandated as the > standard, in fact). > > >* do you need SMP on 80386? Is there even such thing as 80386 SMP > > machines? Not requiring SMP support would make the ABI change > > trivial... > I think there is no such thing as SMP for 80386. There is afaik. Not in widespread use though, and the Linux kernel hasn't been ported to that hardware. I think we can safely ignore this hardware without stepping on anyone's toes... /David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, 26 Jun 2003, "Martin v. Löwis" wrote: > Marcelo E. Magallon wrote: > > The patch has been already written: http://lwn.net/Articles/8634/ I'm > > sure theere's a better link, but that's the best I could extract out of > > google without resorting to bribery :-) > > This patch is insufficient. It does not implement xaddl. Patches welcome. Ie, put up, or shut up.
Bug#198158: architecture i386 isn't i386 anymore
>* what opcodes need to be emulated? >* all 386->486 opcodes (there's just a few of them, right?) This is the correct answer. :-) Then all programs can be compiled with gcc --arch=i486 --tune=i686 (which should probably be mandated as the standard, in fact). >* do you need SMP on 80386? Is there even such thing as 80386 SMP > machines? Not requiring SMP support would make the ABI change > trivial... I think there is no such thing as SMP for 80386. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: [proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)
On Thu, 26 Jun 2003, Michael Banck wrote: > Also, please note that at least half of the dpkg-maintainers don't read > -devel, you probably want to post this to -dpkg. Incidently, there is a > proposal and patch by Gerhard Tonn for handling lib64 under > discussion[2]. Well, considering there are most likely only 2 dpkg maintainers(of which I am one), and I read your mail, does that mean the other isn't on this list?
Re: Bug#198158: architecture i386 isn't i386 anymore
Marcelo E. Magallon wrote: The patch has been already written: http://lwn.net/Articles/8634/ I'm sure theere's a better link, but that's the best I could extract out of google without resorting to bribery :-) This patch is insufficient. It does not implement xaddl. Regards, Martin
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote: > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: > > ports - NetBSD gives us the potential to bring Debian to _many_ new > > platforms. > > It's not that many actually. The only CPU that NetBSD claims to support > but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 > aren't really useable unlike their NetBSD counterparts. However, NetBSD doesn't run on IA64 or S/390 as far as I know, while Debian does. -- - mdz
Re: [proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)
On Thu, Jun 26, 2003 at 11:40:21AM +0200, Andreas Barth wrote: > * Michael Banck ([EMAIL PROTECTED]) [030626 08:20]: > > On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote: > > > What does oppose us to make subarchitectures quite more easy than now? > > > (That would also be useful for the AMD Opteron and the like that could > > > use normal i386-code, but can profit from optimized code.) > > > Nothing opposes it, we're just missing something: The correct patch. > > I would start with a proposal first before writing code. Below is a > draft, comments to it? Sorry, I don't have time right now to look at it. But did you consider marcus' several years old arch-handling proposal[1]? Also, please note that at least half of the dpkg-maintainers don't read -devel, you probably want to post this to -dpkg. Incidently, there is a proposal and patch by Gerhard Tonn for handling lib64 under discussion[2]. cheers, Michael -- [1] http://master.debian.org/~brinkmd/arch-handling.txt [2] http://lists.debian.org/debian-dpkg/2003/debian-dpkg-200306/msg00032.html
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, 25 Jun 2003 14:04:54 -0500 Gunnar Wolf <[EMAIL PROTECTED]> wrote: > And not only 80386 needs this - There is the Sparc64 port which would > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we > had support for subarchtectures, not only would the ix86 mess be able to > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever > you fancy). And I am sure this can somehow help maintain the non-Linux > ports - NetBSD gives us the potential to bring Debian to _many_ new > platforms. No it doesn't. I've yet to even hear of an architecture that NetBSD runs on but which Linux doesn't. They just have a different definition of "architecture" than us. (ie: our "hppa" may be three or four arches to the NetBSD kernel folk.) pgpecAblVDzu4.pgp Description: PGP signature
[proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)
* Michael Banck ([EMAIL PROTECTED]) [030626 08:20]: > On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote: > > What does oppose us to make subarchitectures quite more easy than now? > > (That would also be useful for the AMD Opteron and the like that could > > use normal i386-code, but can profit from optimized code.) > Nothing opposes it, we're just missing something: The correct patch. I would start with a proposal first before writing code. Below is a draft, comments to it? (I know it doesn't specify every detail. It is a start, not more nor less, and it should be expanded if acceptable in general. Also a list of subarchitectures must be created. I'm also willing to produce code once this or another proposal is accepted.) DRAFT - Subarchitectures for debian [0.1] Subarchitectures are an extension to a given architecture that provides optimized binaries that work only (optimized) on a part of machines of the whole architecture. For example: Code using the MMX-extensions can not work on all i386-machines. In this text I will use architecture_subarchitecture or _subarchitecture in examples if speaking of a subarchitecture (e.g. i386_i386). This text speaks only of the debian archive and the user interface at installing packages. If this proposal is adopted it must be expanded to the packaging tools of course. Goal: The addition of subarchitectures must not break the current archiving system, but enhance it. On the other hand, it must be easy to use and most transparent to the users. I assume that most packages need not to be present in an extra subarchitecture-specified version in the archive, otherwise it would be useful to make a full new architecture. control-Files: The syntax of the control-Files is extended in the following way: The field "Filename" gives the default file for this package. It must be able to run on each machine of the given architecture, as tools not knowing of subarchitectures will use this file. (Of course it might be neccassary to use the standard emulator provided by debian as discussed at the moment for i386_i386. And I didn't say "make good performance". No, it just must run. It might be really very suboptimal, e.g. using much too much emulation code as in "optimized for _i686, opcodes from _i586, running on _i386, and opcode emulation in the default linux kernel by debian".) It is possible to specify another file for subarchitectures with "Filename[+-]", e.g. Filename-i486. A '-' says: Use this file exactly for the given subarchitecture. A '+' means: For this and any 'higher' subarchitecture, unless there is a closer match. '+' has the advantage of making the control-files a bit smaller, but might be too unfocussed. So both alternatives are given, and the package maintainer can choose which one suits better in his case. Meta-Subarchitectures: Sometimes it is usefull to put some subarchitectures together again by a specific criterium like existence of a MMU. For this meta-subarchitectures can be used. Creating of new subarchitectures (and exceptions to the said): If a new subarchitecture is created there are usually no specific files for it at the beginning. But it is usually suboptimal to start at the very beginning and the lowest common denominator for the whole architecture. So at selecting the filename of an old package for a new subarchitecture the selecting tools uses instead a predefined other subarchitecture. (As a simple example just imagine Debian is running on _i286, _i386 and _i486 and we just created new _i486. If a system using _i486 is installing an old package, the selection tools just behaves as the system is _i386.) "Old" is a package that gives a Standards-Version where the given subarchitecture was not defined. Packages only for parts of the architecture: Sometimes a package is only usable on specific subarchitectures because of allowing to manipulate specific things, eg microcode updates, http://packages.debian.org/microcode.ctl. In this case the package must not specify the filename-field in the control-file. The package selection tools must show by default these packages exactly on the subarchitectures where it provide files. Such a package must make a Pre-Depend on an dpkg-Version knowing of subarchitectures and such a package must not be uploaded to woody or any older release, including security or proposed-updates. Next steps: I put this list up on http://home.arcor.de/andreas-barth/subarch.html and will update this file according to the discussion. The next steps are to get a decision whether to use subarchitectures or not, and about the above proposal. As soon as this is done the next steps are to enhance the archive tools. But step after step. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: > ports - NetBSD gives us the potential to bring Debian to _many_ new > platforms. It's not that many actually. The only CPU that NetBSD claims to support but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 aren't really useable unlike their NetBSD counterparts.
Re: Bug#198158: architecture i386 isn't i386 anymore
Morning .. On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: >And not only 80386 needs this - There is the Sparc64 port which would >also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we >had support for subarchtectures, not only would the ix86 mess be able to >be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever >you fancy). And I am sure this can somehow help maintain the non-Linux >ports - NetBSD gives us the potential to bring Debian to _many_ new >platforms. In my opinion, this would be the right way. Sure, this is a lot of work, but we, if we splitt the arches up into suparches, we will be able to use optimization for eg. 586/686 or on PowerPC altivec for G4 and so on. And, of course, we can keep the support 80386. Regards Jan -- .''`.Jan-Hendrik Palic | : :' : ** Debian GNU/ Linux ** | ** OpenOffice.org ** ,.. ,.. `. `' http://www.debian.org | http://www.openoffice.org ,: ..` ` `- [EMAIL PROTECTED] | ' ` ` pgpQvAYMV2GzT.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 12:35:53PM -0400, Colin Walters wrote: > I'm surprised that pthreads apparently doesn't use it. nptl doesn't support i386 anymore because of that.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 01:26:38PM +0900, GOTO Masanori wrote: > Performance improvement is _not_ my primary intention.At least it needs to > support libc6-686: > > - LinuxThreads floating stack support. It's ready for i686 and later. > > - NPTL/TLS support. NPTL currently supports i486 and later because > pthread_spin_trylock uses cmpxchgl instruction (well, it's not > difficult to support i386, but imagine pthread on i386 with the > max clock (I recall it was 20MHz?) speed and memory...) > > and so on. Ah, I was not aware of this. I am very interested in both of these features. > BTW, I also think that 5% performance improvement with optimization is > valuable. It's not easy to accelerate 5% performance without any source > code modification and hardware improvement. In addition, it reduces the > user responce time, I think it's more important than increasing throughput > (= computational speed). 5% may or may not be valuable depending on the cost. Where did this particular figure come from (5%)? > IMHO, the problem is the lack of real data which compares non- optimized > vs optimized binary performance on the actual environment. I often heard > the perfomance improvement issue using gcc optimization like Gentoo, but I > merely saw the real perfomance comparison graph. So, supporting optimized > library is not primary issue for at least libc. I see a lot of handwaving from gentoo users and the like, but no convincing concrete measurements. Most of what I see is: - "I switched from to and now is much faster!" - "I run on one PC, and on the other, and the optimized one is way faster! They're exactly the same hardware except [they're not]" - "I compared an un-optimized build of (no -O at all) to one compiled with -O27 -pipe -fomit-frame-pointer -funroll-all-loops -march=pentium3 -mcpu=pentium3 -mfpmath=sse -mmmx -msse -mother-options-i-dont-even-understand -mi-didnt-read-the-manual" These claims are usually subjective, but sometimes they come with numbers, which are meaningless because there are so many variables involved. -- - mdz
Re: Bug#198158: architecture i386 isn't i386 anymore
Colin Watson dijo [Wed, Jun 25, 2003 at 11:05:56AM +0100]: > > We should foist the job of supporting i386 onto some specialized Debian > > port for it. > > The problem is that we really don't have sensible support for > subarchitectures at all. This makes the job of creating such a > specialized port much greater than just "I have some hardware and need > to make a small tweak to support it"; you need to patch dpkg and make > substantial changes in the archive organization to share packages > between architectures, or else take a multi-gigabyte hit in disk space > and a huge amount of pointless effort rebuilding packages for some new > 'i386only' architecture. 386 people would be quite entitled to look at > all this mess and say "well, why don't you just leave everything as it > is and let us make this small kernel change, until we can standardize on > gcc-3.3 with a fixed ABI"? And not only 80386 needs this - There is the Sparc64 port which would also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we had support for subarchtectures, not only would the ix86 mess be able to be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever you fancy). And I am sure this can somehow help maintain the non-Linux ports - NetBSD gives us the potential to bring Debian to _many_ new platforms. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: subarchitectures? (was: Bug#198158: architecture i386 isn't i386 anymore)
On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote: > What does oppose us to make subarchitectures quite more easy than now? > (That would also be useful for the AMD Opteron and the like that could > use normal i386-code, but can profit from optimized code.) Nothing opposes it, we're just missing something: The correct patch. Michael
subarchitectures? (was: Bug#198158: architecture i386 isn't i386 anymore)
* Colin Watson ([EMAIL PROTECTED]) [030625 12:35]: > The problem is that we really don't have sensible support for > subarchitectures at all. This makes the job of creating such a > specialized port much greater than just "I have some hardware and need > to make a small tweak to support it"; you need to patch dpkg and make > substantial changes in the archive organization to share packages > between architectures, What does oppose us to make subarchitectures quite more easy than now? (That would also be useful for the AMD Opteron and the like that could use normal i386-code, but can profit from optimized code.) Of course, that doesn't resolve the actual bug right now, but ... > all this mess and say "well, why don't you just leave everything as it > is and let us make this small kernel change, until we can standardize on > gcc-3.3 with a fixed ABI"? ... this is the right thing to do that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, 2003-06-25 at 06:05, Colin Watson wrote: > I disagree. Unlike 286, we've got the kernel, the libc, and *almost* > everything else. The only thing missing is part of the C++ ABI, which as > described can be handled by a small kernel patch (at least this has been > claimed and nobody has immediately said "it's impossible" ...). The problem isn't just the C++ ABI; it's any application that uses an insn like cmpxchg. Basically any application that wants to have atomic integers or similar will be using this insn. Of software I'm familiar with, this includes gstreamer and dbus right now. And glib will soon have atomic integers too (for refcounting). I'm surprised that pthreads apparently doesn't use it. > I don't think this one lack puts it straight into the 286 camp just yet. Maybe. > The problem is that we really don't have sensible support for > subarchitectures at all. Yes, I agree, that is by far the biggest bug. > [...] 386 people would be quite entitled to look at > all this mess and say "well, why don't you just leave everything as it > is and let us make this small kernel change, until we can standardize on > gcc-3.3 with a fixed ABI"? Note that the current situation is that we don't run on i386, unless they emulate opcodes. In which case, we really can still say we don't run on i386.
Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 08:51:12PM +1000, Herbert Xu wrote: > It certainly is feasible. In fact, such a patch has been in existence > for at least a year. Cool. > I have no problems with integrating such a patch. I will look at it > right now. Excellent. Thanks! -- G. Branden Robinson|I am sorry, but what you have Debian GNU/Linux |mistaken for malicious intent is [EMAIL PROTECTED] |nothing more than sheer http://people.debian.org/~branden/ |incompetence! -- J. L. Rizzo II pgpkPCNTJaCM3.pgp Description: PGP signature
Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 01:42:04PM +0200, Adam Borowski wrote: > As the person who originally submitted this idea, I'm probably the > one who is morally obliged to write it, even though: The patch has been already written: http://lwn.net/Articles/8634/ I'm sure theere's a better link, but that's the best I could extract out of google without resorting to bribery :-) -m.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wednesday 25 June 2003 12:00, Marcelo E. Magallon wrote: > On Wed, Jun 25, 2003 at 09:57:57AM +0100, David Goodenough wrote: > > and remember that many embedded processors still use 486 and 586 > > based chips, and some 386. Lossing 386 might be acceptable in the > > embedded market (many 386 based systems have too little memory to run > > Debian) but loosing 486 and 586 would mean that Debian was no longer > > an option for embedded systems which would be a great loss. > > Do these people really use what we put out the door, or do they prune > the distribution and recompile with different settings and things like > that? In the later case I don't see why our decision should affect > them. > > -m. For simple, short run projects why do a whole lot of work when the standard off the shelf component will do it for you. Yes I go around deleting a whole bunch of documentation and the like, or rather I only copy the bits I really need to the CF disk, but wherever possible I use what gets shipped. The kernel and associated modules I will rebuild, but I would rather not rebuild everything else, otherwise I would use Gentoo rather than Debian. David
Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 02:52:31AM -0500, Branden Robinson wrote: > The drawbacks: > * Someone actually has to write this kernel patch. http://miaif.lip6.fr/~tarreau/linux-patches/486emulation/
Bug#198158: architecture i386 isn't i386 anymore
On Wed, 25 Jun 2003, Branden Robinson wrote:
> > Hmm... I'm not sure about this as the last time I used assembler was
> > in the times of real mode DOS, but there is a yet another option:
> > we can patch the kernel so when an invalid opcode occurs, whatever
> > instruction was at CS:EIP gets emulated in software, similar to the
> > way i387 emulation is done.
> > (arch/i386/kernel/entry.S)
> > Of course, this would further slow down the speed demon known as 80386,
> > but since (AFAIK) the 486-specific opcodes get used pretty rarely in
> > non-kernel code, the performance hit wouldn't be crippling. And, there
> > is no performance hit at all for >386 machines, as no legitimate process
> > ever triggers the invalid opcode fault.
>
> If this indeed feasible, then this is the solution that appeals most to
> me personally.
>
> * It seems the least intrusive. 80386 users are probably going to want
> and use an 80386-specific kernel, if they don't already *have* to.
> * Our hand is forced by the fact that the rest of the Linux distributors
> in the world, and apparently the GCC folks, don't care about C++ ABI
> portability to 80386 processors.
> * This doesn't require recompiling anything except the kernel.
>
> The drawbacks:
> * Someone actually has to write this kernel patch.
As the person who originally submitted this idea, I'm probably the one
who is morally obliged to write it, even though:
* I'm not a kernel hacker,
* I was once good at _8086_ assembly, but the times of real mode are
long gone, and I have no recent assembler experience,
* I'm moving home later this week, and won't be able to write this
while my desktop machine is in transit (all the other boxes I got
root access to are production servers),
* my skills are probably no match for most of you.
The pros and cons for the idea:
Pro:
this kernel patch would make the 486 ABI transition flawless for all
80386 users who have it applied, and (optionally) it can be used to
make other software built for i486, i586 and i686 work on lesser CPUs.
Con:
those on 80386 who don't have this patch applied will be screwed
I've made some proof-of-concept patches, and I'm ready for actually
emulating the opcodes. However, you would need to answer the following
questions:
* what opcodes need to be emulated?
* just those needed for C++ ABI
* all 386->486 opcodes (there's just a few of them, right?)
* most 386->586 opcodes (it's impossible to emulate at least RDTSC,
but the majority of code doesn't use it)
* 386->686?
* do you need SMP on 80386? Is there even such thing as 80386 SMP
machines? Not requiring SMP support would make the ABI change
trivial...
* would you want some other emulation, like 486->586, 586->686? MMX?
Once the infrastructure for emulation is done, adding new opcodes
is a simple task.
And, some patches for you to play with:
1. just reporting the invalid opcodes encountered
--- arch/i386/kernel/traps.c.0 2003-06-25 11:19:53.0 +0200
+++ arch/i386/kernel/traps.c2003-06-25 12:09:16.0 +0200
@@ -388,7 +388,6 @@
DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
DO_VM86_ERROR( 5, SIGSEGV, "bounds", bounds)
-DO_ERROR_INFO( 6, SIGILL, "invalid operand", invalid_op, ILL_ILLOPN,
regs->eip)
DO_VM86_ERROR( 7, SIGSEGV, "device not available", device_not_available)
DO_ERROR( 8, SIGSEGV, "double fault", double_fault)
DO_ERROR( 9, SIGFPE, "coprocessor segment overrun",
coprocessor_segment_overrun)
@@ -397,6 +396,32 @@
DO_ERROR(12, SIGBUS, "stack segment", stack_segment)
DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN,
get_cr2())
+
+asmlinkage void do_invalid_op(struct pt_regs * regs, long error_code)
+{
+ siginfo_t info;
+ int i;
+
+ printk("Invalid opcode: ");
+ for(i=0;i<20;i++)
+ {
+ unsigned char c;
+ if(__get_user(c, &((unsigned char*)regs->eip)[i]))
+ {
+ printk(" Bad EIP value.");
+ break;
+ }
+ printk("%02x ", c);
+ }
+ printk("\n");
+
+ info.si_signo = SIGILL;
+ info.si_errno = 0;
+ info.si_code = ILL_ILLOPN;
+ info.si_addr = regs->eip;
+ do_trap(6, SIGILL, "invalid operand", 1, regs, error_code, &info);
+}
+
asmlinkage void do_general_protection(struct pt_regs * regs, long error_code)
{
if (regs->eflags & VM_MASK)
2. an ugly hack that proves that the emulation can be done. I took some
random opcode that just happened to be not present on my machine (you
would probably need to choose something else), and "emulated" it by
a token operation: swapping eax and ebx. I didn't even bother with
making it nice, readable or anything -- it's just a test code.
--- arch/i386/kernel/traps.c.0 2003-06-25 11:19:53.0 +0200
+++ arch/i386/kernel/traps.c2003-06-25 13:09:5
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 09:57:57AM +0100, David Goodenough wrote: > and remember that many embedded processors still use 486 and 586 > based chips, and some 386. Lossing 386 might be acceptable in the > embedded market (many 386 based systems have too little memory to run > Debian) but loosing 486 and 586 would mean that Debian was no longer > an option for embedded systems which would be a great loss. Do these people really use what we put out the door, or do they prune the distribution and recompile with different settings and things like that? In the later case I don't see why our decision should affect them. -m.
Bug#198158: architecture i386 isn't i386 anymore
Branden Robinson <[EMAIL PROTECTED]> wrote:
>
> If this indeed feasible, then this is the solution that appeals most to
> me personally.
It certainly is feasible. In fact, such a patch has been in existence
for at least a year.
> Also, Herbert Xu, the 80386 kernel-flavor maintainer, would have to be
> agreeable, and I don't believe I saw him offer an opinion on this
> approach in this discussion.
I have no problems with integrating such a patch. I will look at it
right now.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#198158: architecture i386 isn't i386 anymore
Hi, On Wed, Jun 25, 2003 at 01:07:12PM +0200, Tollef Fog Heen wrote: > * Colin Walters > > | On Wed, 2003-06-25 at 03:52, Branden Robinson wrote: > | > | > I believe it would be a mistake to kill off support for the 80386 chip. > | > | Well, we're limited by what we can sanely support. After all, we don't > | support running Debian on a 286. The 386 is really in the same class > | nowadays, in my opinion anyways. > > 386 has protected mode, 286 doesn't. That makes a bit of a > difference. It does. It's just that the 286 is a 16-bit CPU and its protected mode MMU mode offers only segmentation, no paging. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Bug#198158: architecture i386 isn't i386 anymore
* Colin Walters | On Wed, 2003-06-25 at 03:52, Branden Robinson wrote: | | > I believe it would be a mistake to kill off support for the 80386 chip. | | Well, we're limited by what we can sanely support. After all, we don't | support running Debian on a 286. The 386 is really in the same class | nowadays, in my opinion anyways. 386 has protected mode, 286 doesn't. That makes a bit of a difference. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 04:55:56AM -0400, Colin Walters wrote: > On Wed, 2003-06-25 at 03:52, Branden Robinson wrote: > > I believe it would be a mistake to kill off support for the 80386 chip. > > Well, we're limited by what we can sanely support. After all, we don't > support running Debian on a 286. The 386 is really in the same class > nowadays, in my opinion anyways. I disagree. Unlike 286, we've got the kernel, the libc, and *almost* everything else. The only thing missing is part of the C++ ABI, which as described can be handled by a small kernel patch (at least this has been claimed and nobody has immediately said "it's impossible" ...). I don't think this one lack puts it straight into the 286 camp just yet. > We should foist the job of supporting i386 onto some specialized Debian > port for it. The problem is that we really don't have sensible support for subarchitectures at all. This makes the job of creating such a specialized port much greater than just "I have some hardware and need to make a small tweak to support it"; you need to patch dpkg and make substantial changes in the archive organization to share packages between architectures, or else take a multi-gigabyte hit in disk space and a huge amount of pointless effort rebuilding packages for some new 'i386only' architecture. 386 people would be quite entitled to look at all this mess and say "well, why don't you just leave everything as it is and let us make this small kernel change, until we can standardize on gcc-3.3 with a fixed ABI"? Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wednesday 25 June 2003 08:40, Branden Robinson wrote: > On Wed, Jun 25, 2003 at 07:47:42AM +0200, Tollef Fog Heen wrote: > > * GOTO Masanori > > > > | - NPTL/TLS support. NPTL currently supports i486 and later because > > | pthread_spin_trylock uses cmpxchgl instruction (well, it's not > > | difficult to support i386, but imagine pthread on i386 with the > > | max clock (I recall it was 20MHz?) speed and memory...) > > > > 33MHz, and ISTR that AMD made a 40MHz version as well. > > Yup. AMD also made the fastest 486 ever[1], clocked at 133MHz. My > first Linux box (also my first Debian box) ran on that chip. > > [1] to my knowledge and remember that many embedded processors still use 486 and 586 based chips, and some 386. Lossing 386 might be acceptable in the embedded market (many 386 based systems have too little memory to run Debian) but loosing 486 and 586 would mean that Debian was no longer an option for embedded systems which would be a great loss. David
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, 2003-06-25 at 03:52, Branden Robinson wrote: > I believe it would be a mistake to kill off support for the 80386 chip. Well, we're limited by what we can sanely support. After all, we don't support running Debian on a 286. The 386 is really in the same class nowadays, in my opinion anyways. We should foist the job of supporting i386 onto some specialized Debian port for it. If they don't come into existence, that just is another nail in the i386 coffin.
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote: > The solution I would favour would be: > > - drop the i386 support > > - keep the i386 architecture name > > - let dpkg-architecture output the new configuration string > (i.e. i486-linux) > > - if anybody wants to start the mini-i386 architecture, we have to > find an architecture name for it. > > changing the dpkg-architecture's ARCH string to i.e. i486 would break > a lot of build scripts ... > > comments welcome. [...] > Hmm... I'm not sure about this as the last time I used assembler was > in the times of real mode DOS, but there is a yet another option: > we can patch the kernel so when an invalid opcode occurs, whatever > instruction was at CS:EIP gets emulated in software, similar to the > way i387 emulation is done. > (arch/i386/kernel/entry.S) > Of course, this would further slow down the speed demon known as 80386, > but since (AFAIK) the 486-specific opcodes get used pretty rarely in > non-kernel code, the performance hit wouldn't be crippling. And, there > is no performance hit at all for >386 machines, as no legitimate process > ever triggers the invalid opcode fault. If this indeed feasible, then this is the solution that appeals most to me personally. * It seems the least intrusive. 80386 users are probably going to want and use an 80386-specific kernel, if they don't already *have* to. * Our hand is forced by the fact that the rest of the Linux distributors in the world, and apparently the GCC folks, don't care about C++ ABI portability to 80386 processors. * This doesn't require recompiling anything except the kernel. The drawbacks: * Someone actually has to write this kernel patch. Also, Herbert Xu, the 80386 kernel-flavor maintainer, would have to be agreeable, and I don't believe I saw him offer an opinion on this approach in this discussion. I believe it would be a mistake to kill off support for the 80386 chip. -- G. Branden Robinson| "There is no gravity in space." Debian GNU/Linux | "Then how could astronauts walk [EMAIL PROTECTED] | around on the Moon?" http://people.debian.org/~branden/ | "Because they wore heavy boots." pgpLuaK3S5tNT.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 07:47:42AM +0200, Tollef Fog Heen wrote: > * GOTO Masanori > > | - NPTL/TLS support. NPTL currently supports i486 and later because > | pthread_spin_trylock uses cmpxchgl instruction (well, it's not > | difficult to support i386, but imagine pthread on i386 with the > | max clock (I recall it was 20MHz?) speed and memory...) > > 33MHz, and ISTR that AMD made a 40MHz version as well. Yup. AMD also made the fastest 486 ever[1], clocked at 133MHz. My first Linux box (also my first Debian box) ran on that chip. [1] to my knowledge -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | pgpeKA09VOTK2.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
* GOTO Masanori | - NPTL/TLS support. NPTL currently supports i486 and later because | pthread_spin_trylock uses cmpxchgl instruction (well, it's not | difficult to support i386, but imagine pthread on i386 with the | max clock (I recall it was 20MHz?) speed and memory...) 33MHz, and ISTR that AMD made a 40MHz version as well. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#198158: architecture i386 isn't i386 anymore
At Tue, 24 Jun 2003 11:32:17 -0400, Matt Zimmerman wrote: > > On Tue, Jun 24, 2003 at 01:47:55PM +0900, GOTO Masanori wrote: > > > At 21 Jun 2003 00:27:18 +0200, > > Mathieu Roy wrote: > > > RedHat provide glibc for i386, i586 and i686. Why doesn't Debian > > > provide several packages for i*86 when the package can be optimized a > > > lot depending on the CPU type? > > > > We're planning. i686 optimized binary does not work on my machine, so > > it's currently dropped. We need to check whether it's ok to upgrade > > smoothly or not. > > There used to be libc6-686 and so on, but they caused a lot of problems with > upgrades. Then they were re-enabled, then disabled again in the same > release. Yup. I investigate a good way to support them. > I wasn't able to measure a significant performance increase with > the optimized library anyway, so I haven't missed it. Good point. I agree with your thought. Performance improvement is _not_ my primary intention. At least it needs to support libc6-686: - LinuxThreads floating stack support. It's ready for i686 and later. - NPTL/TLS support. NPTL currently supports i486 and later because pthread_spin_trylock uses cmpxchgl instruction (well, it's not difficult to support i386, but imagine pthread on i386 with the max clock (I recall it was 20MHz?) speed and memory...) and so on. BTW, I also think that 5% performance improvement with optimization is valuable. It's not easy to accelerate 5% performance without any source code modification and hardware improvement. In addition, it reduces the user responce time, I think it's more important than increasing throughput (= computational speed). IMHO, the problem is the lack of real data which compares non- optimized vs optimized binary performance on the actual environment. I often heard the perfomance improvement issue using gcc optimization like Gentoo, but I merely saw the real perfomance comparison graph. So, supporting optimized library is not primary issue for at least libc. Regards, -- gotom
Re: Bug#198158: architecture i386 isn't i386 anymore
On Tue, Jun 24, 2003 at 01:47:55PM +0900, GOTO Masanori wrote: > At 21 Jun 2003 00:27:18 +0200, > Mathieu Roy wrote: > > RedHat provide glibc for i386, i586 and i686. Why doesn't Debian > > provide several packages for i*86 when the package can be optimized a > > lot depending on the CPU type? > > We're planning. i686 optimized binary does not work on my machine, so > it's currently dropped. We need to check whether it's ok to upgrade > smoothly or not. There used to be libc6-686 and so on, but they caused a lot of problems with upgrades. Then they were re-enabled, then disabled again in the same release. I wasn't able to measure a significant performance increase with the optimized library anyway, so I haven't missed it. -- - mdz
Re: Bug#198158: architecture i386 isn't i386 anymore
Hi Arnd Bergmann, > On Tuesday 24 June 2003 02:00, Adam Heath wrote: >> On Tue, 24 Jun 2003, "Martin v. Löwis" wrote: >> > In g++ 3.2, this code was distributed as "i386", and nobody noticed >> > that it doesn't work on i386 for quite some time. In gcc 3.3, an >> > implementation is provided that works on i386, and this >> > implementation here is declared i486. Unfortunately, the two >> > implementations are not binary compatible. Debian has to pick one of >> > these, and it needs to pick the i486 version for compatibility with >> > other Linux distributions (which either ship with gcc 3.2 today, or >> > target i586+ only, anyway). >> >> Er, if this function is inlined, then how can it be part of some >> published api? If it's not part of some published api, then how can >> using an i386 variation cause problems with other distributions? > > The API requires that access to atomic variables is truly atomic. > > The i386 version uses a semaphore to synchronize the access to an atomic > variable, the i486+ version uses the lock prefix. When you mix these two > in one program, two threads might access the variable without locking > against each other because the code inside the semaphore does not lock > the memory bus. This has been a very informative discussion. While hesitant about dropping i386 support I am now convinced that: (a) i386 support should be dropped so that binary compatibility can be maintained with other Linux distributions. Debian's binary compatibility is a very important feature, especially as a lot of proprietary Linux software companies provide no official support for Debian. Binary compatibility helps fulfil the social contract where "although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages." (b) i486+ should be targeted, but GCC-compiled code optimised for either i586 or i686 (consider whichever is also best for P4 and Athlon). Debian has the goal of being a universal distribution and operating system, and even ditching i386 support is chilling enough. Pragmatically, even though i486 desktops are now relatively scarce i486 laptops still make very useful portable routers. (c) Just keep the i386 name. Changing it will break too many scripts when all that is needed to resolve confusion is a release note. i486+ would still be misleading to those who need to understand that even though i486 is supported the binaries are still optimised for a more recent architecture. One day support for i486 will be dropped and then we also won't need to worry about changing the architecture name. I'd appreciate replies to this message to be CCed to my email address. Regards, Adam
Re: Bug#198158: architecture i386 isn't i386 anymore
At 21 Jun 2003 00:27:18 +0200, Mathieu Roy wrote: > RedHat provide glibc for i386, i586 and i686. Why doesn't Debian > provide several packages for i*86 when the package can be optimized a > lot depending on the CPU type? We're planning. i686 optimized binary does not work on my machine, so it's currently dropped. We need to check whether it's ok to upgrade smoothly or not. Regards, -- gotom
Re: Bug#198158: architecture i386 isn't i386 anymore
At Sat, 21 Jun 2003 12:11:36 +0200, Erwan MAS wrote: > Please keep , a i386 or i586 architecture , for the via C3 processor . > i686 architecture is not compatible with C3 . > > This processor is very used in the Via EPIA motherboard : > > See : > http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21 > > http://www.mini-itx.com/ You confused. VIA C3 Ezra (not Nehemiah) does not have CMOV instruction, and gcc create assembler code including CMOV if you set --cpu=i686. It's i686 processor, but it does not support full i686 capability. Regards, -- gotom
Re: Bug#198158: architecture i386 isn't i386 anymore
"Martin v. L?wis" <[EMAIL PROTECTED]> wrote:
> __asm__ __volatile__ ("lock; xaddl %0,%2"
> : "=r" (__result)
> : "0" (__val), "m" (*__mem)
> : "memory");
> In particular, the lock prefix is not available on i386. Since this is
No it's xaddl that is not available on 386.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#198158: architecture i386 isn't i386 anymore
On Mon, Jun 23, 2003 at 07:00:21PM -0500, Adam Heath wrote:
> On Tue, 24 Jun 2003, "Martin v. Löwis" wrote:
> >
> > static inline _Atomic_word
> > __attribute__ ((__unused__))
> > __exchange_and_add (volatile _Atomic_word *__mem, int __val)
> > {
> >register _Atomic_word __result;
> >__asm__ __volatile__ ("lock; xaddl %0,%2"
> > : "=r" (__result)
> > : "0" (__val), "m" (*__mem)
> > : "memory");
> >return __result;
> > }
> >
> Er, if this function is inlined, then how can it be part of some published
> api? If it's not part of some published api, then how can using an i386
> variation cause problems with other distributions?
It's pretty clear by comparing the implementations. The i386 version
aquires a global spinlock, and once aquired, increments the variable.
The i486 version increments the variable using an atomic instruction.
Code compiled against the i386 header and code compiled against the
i486 header will have problems using __exchange_and_add() on the
same memory location. It appears that this inlined function is
used by other inline functions, which are actually exported by the
API, and thus could appear in the application.
dave...
Re: Bug#198158: architecture i386 isn't i386 anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 June 2003 02:00, Adam Heath wrote: > On Tue, 24 Jun 2003, "Martin v. Löwis" wrote: > > In g++ 3.2, this code was distributed as "i386", and nobody noticed that > > it doesn't work on i386 for quite some time. In gcc 3.3, an > > implementation is provided that works on i386, and this implementation > > here is declared i486. Unfortunately, the two implementations are not > > binary compatible. Debian has to pick one of these, and it needs to pick > > the i486 version for compatibility with other Linux distributions (which > > either ship with gcc 3.2 today, or target i586+ only, anyway). > > Er, if this function is inlined, then how can it be part of some published > api? If it's not part of some published api, then how can using an i386 > variation cause problems with other distributions? The API requires that access to atomic variables is truly atomic. The i386 version uses a semaphore to synchronize the access to an atomic variable, the i486+ version uses the lock prefix. When you mix these two in one program, two threads might access the variable without locking against each other because the code inside the semaphore does not lock the memory bus. Arnd <>< -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+95p45t5GS2LDRf4RAkJoAJ4xU1jRtxdrvFkh3iserV7AlbOFmwCfd6kw 4ihYAIhj2bMefEpvIcXgu1E= =BmdC -END PGP SIGNATURE-
Re: Bug#198158: architecture i386 isn't i386 anymore
On Tue, 24 Jun 2003, "Martin v. Löwis" wrote:
> John Goerzen wrote:
>
> > Nobody has even explained WHY we have this issue. The summary posted on the
> > bug report just said that there is a problem with atomicity.h, not what the
> > problem is or why it exists.
>
> Just look at the file for yourself. It is easy enough to see: it uses
> inline assembly that is only available on i486:
>
> static inline _Atomic_word
> __attribute__ ((__unused__))
> __exchange_and_add (volatile _Atomic_word *__mem, int __val)
> {
>register _Atomic_word __result;
>__asm__ __volatile__ ("lock; xaddl %0,%2"
> : "=r" (__result)
> : "0" (__val), "m" (*__mem)
> : "memory");
>return __result;
> }
>
> In particular, the lock prefix is not available on i386. Since this is
> an inline function, this code is inserted into any C++ binary, so you
> can't change its implementation by replacing the library.
>
> In g++ 3.2, this code was distributed as "i386", and nobody noticed that
> it doesn't work on i386 for quite some time. In gcc 3.3, an
> implementation is provided that works on i386, and this implementation
> here is declared i486. Unfortunately, the two implementations are not
> binary compatible. Debian has to pick one of these, and it needs to pick
> the i486 version for compatibility with other Linux distributions (which
> either ship with gcc 3.2 today, or target i586+ only, anyway).
Er, if this function is inlined, then how can it be part of some published
api? If it's not part of some published api, then how can using an i386
variation cause problems with other distributions?
Re: Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote:
Nobody has even explained WHY we have this issue. The summary posted on the
bug report just said that there is a problem with atomicity.h, not what the
problem is or why it exists.
Just look at the file for yourself. It is easy enough to see: it uses
inline assembly that is only available on i486:
static inline _Atomic_word
__attribute__ ((__unused__))
__exchange_and_add (volatile _Atomic_word *__mem, int __val)
{
register _Atomic_word __result;
__asm__ __volatile__ ("lock; xaddl %0,%2"
: "=r" (__result)
: "0" (__val), "m" (*__mem)
: "memory");
return __result;
}
In particular, the lock prefix is not available on i386. Since this is
an inline function, this code is inserted into any C++ binary, so you
can't change its implementation by replacing the library.
In g++ 3.2, this code was distributed as "i386", and nobody noticed that
it doesn't work on i386 for quite some time. In gcc 3.3, an
implementation is provided that works on i386, and this implementation
here is declared i486. Unfortunately, the two implementations are not
binary compatible. Debian has to pick one of these, and it needs to pick
the i486 version for compatibility with other Linux distributions (which
either ship with gcc 3.2 today, or target i586+ only, anyway).
Regards,
Martin
Bug#198158: architecture i386 isn't i386 anymore
On Mon, Jun 23, 2003 at 01:54:43PM -0500, Adam Majer wrote:
> On Mon, Jun 23, 2003 at 12:41:48PM -0500, John Goerzen wrote:
> > On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> > > John Goerzen <[EMAIL PROTECTED]> wrote:
> > > Talk is cheap. If you can come up with a solution to the C++ problem that
> > > ignited this debate then i386 would be safe.
> >
> > Nobody has even explained WHY we have this issue. The summary posted on the
> > bug report just said that there is a problem with atomicity.h, not what the
> > problem is or why it exists.
>
> Where is automicity.h?
("atomicity.h")
You could use locate(1) ...
--
Colin Watson [EMAIL PROTECTED]
Bug#198158: architecture i386 isn't i386 anymore
On Monday 23 June 2003 19:41, John Goerzen wrote: > On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote: > > John Goerzen <[EMAIL PROTECTED]> wrote: > > Talk is cheap. If you can come up with a solution to the C++ problem > > that ignited this debate then i386 would be safe. > > Nobody has even explained WHY we have this issue. The summary posted on > the bug report just said that there is a problem with atomicity.h, not what > the problem is or why it exists. You can find the original description by Matthias Klose in http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html In one thread following that message, see http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02163.html, it was concluded that a solution to the problem exists, but no one worked out the details or created a patch. Arnd <><
Bug#198158: architecture i386 isn't i386 anymore
On Mon, Jun 23, 2003 at 12:41:48PM -0500, John Goerzen wrote: > On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote: > > John Goerzen <[EMAIL PROTECTED]> wrote: > > Talk is cheap. If you can come up with a solution to the C++ problem that > > ignited this debate then i386 would be safe. > > Nobody has even explained WHY we have this issue. The summary posted on the > bug report just said that there is a problem with atomicity.h, not what the > problem is or why it exists. Where is automicity.h?
Bug#198158: architecture i386 isn't i386 anymore
On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> John Goerzen <[EMAIL PROTECTED]> wrote:
> Talk is cheap. If you can come up with a solution to the C++ problem that
> ignited this debate then i386 would be safe.
Nobody has even explained WHY we have this issue. The summary posted on the
bug report just said that there is a problem with atomicity.h, not what the
problem is or why it exists.
> --
> Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
Bug#198158: architecture i386 isn't i386 anymore
John Goerzen <[EMAIL PROTECTED]> wrote:
>
> This is a disturbing trend. You can't claim that Debian is usable on a
> machine if it requires another machine or Internet access to work basically.
>
> And no, there are not necessarily other machines reachable with scp, since
> some of these machines sit outside the firewall. Not only that, but this is
> a big pain as it requires the same version of Debian over there. It is not
> a workable solution.
Talk is cheap. If you can come up with a solution to the C++ problem that
ignited this debate then i386 would be safe.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote: > On Sat, 21 Jun 2003, John Goerzen wrote: > > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > > Note that my idea was about patching the kernel that so the newer opcodes > > > would be emulated in software. Everything would still work even on a > > > 386, > > > just slower -- and the speed decrease can be removed by running apt-build. > > I don't see how that suggestion can possibly be taken seriously. Very few > > i386 machines have the requisite disk space, memory, and swap space to build > > large applications in Debian today. > You do have a Pentium 17 10^38Mhz machine nearby, don't you? Apt-build > doesn't even give the option of avoiding creation of .debs, and the bigger > machine is one scp (or two mcopys in an extreme case) away. This is a disturbing trend. You can't claim that Debian is usable on a machine if it requires another machine or Internet access to work basically. And no, there are not necessarily other machines reachable with scp, since some of these machines sit outside the firewall. Not only that, but this is a big pain as it requires the same version of Debian over there. It is not a workable solution.
Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 09:52:17AM +0200, Adam Borowski wrote: > On Sat, 21 Jun 2003, John Goerzen wrote: > > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > > Note that my idea was about patching the kernel that so the newer opcodes > > > would be emulated in software. Everything would still work even on a > > > 386, > > > just slower -- and the speed decrease can be removed by running apt-build. > > I don't see how that suggestion can possibly be taken seriously. Very few > > i386 machines have the requisite disk space, memory, and swap space to build > > large applications in Debian today. > You do have a Pentium 17 10^38Mhz machine nearby, don't you? Apt-build > doesn't even give the option of avoiding creation of .debs, and the bigger > machine is one scp (or two mcopys in an extreme case) away. Our operating system should not be wholly dependant on external factors (other machines, Internet access, whatever) to run. To make it so makes it virtually unusable in a number of situations. In this particular case, no, there is not always another machine network-reachable, as some of these sit outside the firewall. Not just that, but forcing that removes most of the benefits of Debian (apt-get dist-upgrade, etc) and we might as well just to back to Slackware from 1997.
Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 11:24:57AM +0200, "Martin v. Löwis" wrote: > John Goerzen wrote: > > >As I say this, I'm sure people can say the same about i486 and even i386 > >machines. Why exactly do we need to remove this support? > > Read the bug report with the number you put in your Subject. Which is little help, as I've already posted in this thread that I'm reading mail offline for a few days.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 12:06:16PM +0200, Andreas Barth wrote: > * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > > problem here (C++ ABI compatibility with other Linux distributions). The > > discussion is now about *how* to fix this bug: > > 1. just bump minimum supported i386-family processor to i486 > 1a. like 1, but just for c++-packages. 1b. Ban C++ and rewrite everything in C, and rejoice over the fact the we are rid of the horrid kludge that is C++. (No, I do not expect this to happen, and I do indeed expect flames for this... I've donned the asbestos suite...) > > 2. like 1, but bump to some other processor. this is not strictly needed > >to fix the bug, but it might be a good idea for other reasons. > >Dropping other architectures to fix this bug is probably not a good > >idea, as it won't fix the bug. > > 3. bump the supported processor, and rename the port > > 4. like 3, and also add an i386 distribution which does not support > >C++ at all > > 5. like 4, but support C++ in a way incompatible with other Linux > >distributions in the i386 distribution. /David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, 2003-06-22 at 00:48, Adam Majer wrote: > I once read somewhere that you should _never_ compile in 486 > optimizations for use in processors other than the 486. Apparently > since 486 optimized code is padded a lot with NOPs. > > Apparently you are much better off on a Pentium or Athlon with > i386 optimized code than i486 optimized one. > > > Hence if we are going to migrate from i386, we should not > go to CPU like i486 and just move to a Pentium Classic > code (i586). You're forgetting that we can actually have it both ways; we compile with -march=i486 (or i586), and -mcpu=i686.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 02:46:12PM +0100, Andrew Suffield wrote: > > Apparently you are much better off on a Pentium or Athlon with > > i386 optimized code than i486 optimized one. > I vaguely recall something similar about the i586. FWIK, almost everything that can be done in two ways on ix86, like loop / dec jnz and frame / sub ebp blah, is faster one way on i586 and the other on i686. Moreover, i586 gets most performance boost from keeping everything in registers, while i686 gets most from using registers and memory evenly (!) - I don't know whether compilers support these optimisations, though. So if there will be a split, it should IMO be to i386 and i686. Of course, if C++ progs are going to be broken anyway, dropping i386 might be viable - in that case we'll get i486 and i686. Just my two cents... -- personal contact: [EMAIL PROTECTED], +35841 5323835 work contact: [EMAIL PROTECTED], +35850 3678003 kotisivu (henkkoht):http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sat, Jun 21, 2003 at 11:48:26PM -0500, Adam Majer wrote: > Sebastian Kapfer wrote: > >I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote > >would count... > > > > I once read somewhere that you should _never_ compile in 486 > optimizations for use in processors other than the 486. Apparently > since 486 optimized code is padded a lot with NOPs. > > Apparently you are much better off on a Pentium or Athlon with > i386 optimized code than i486 optimized one. > > > Hence if we are going to migrate from i386, we should not > go to CPU like i486 and just move to a Pentium Classic > code (i586). I vaguely recall something similar about the i586. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpGGQSuO4gzE.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
Andreas Barth wrote: > * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > >>problem here (C++ ABI compatibility with other Linux distributions). The >>discussion is now about *how* to fix this bug: >>1. just bump minimum supported i386-family processor to i486 > > 1a. like 1, but just for c++-packages. As has been pointed out many times before and in this thread, dropping c++ support for i386 is much like dropping support completely, as important base packages (e.g. apt [0]) depend on it. Cheers T. 0. According to the priority and section, of course. pgpwGTXt3rchh.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
* "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]: > problem here (C++ ABI compatibility with other Linux distributions). The > discussion is now about *how* to fix this bug: > 1. just bump minimum supported i386-family processor to i486 1a. like 1, but just for c++-packages. > 2. like 1, but bump to some other processor. this is not strictly needed >to fix the bug, but it might be a good idea for other reasons. >Dropping other architectures to fix this bug is probably not a good >idea, as it won't fix the bug. > 3. bump the supported processor, and rename the port > 4. like 3, and also add an i386 distribution which does not support >C++ at all > 5. like 4, but support C++ in a way incompatible with other Linux >distributions in the i386 distribution. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
RE: Bug#198158: architecture i386 isn't i386 anymore
Hi all, I feel this whole discussion is somehow going into the wrong direction. What does it matter now whether we drop support for i386 and i486 (and possibly more), or just i386? Sooner or later we'll have the same problem (of changing the arch support being so difficult) again, if not with ix86 architectures, then with some other architecture. If you ask me, the proper long-term solution would be to make the arch names sub-arch independent (i.e. "ix86" or "ia32" instead of "i386"), and then make the archs have versions (i.e. "ix86 3" = "i386", "ix86 5" = "i586") and -- if this can be viably done somehow -- features (i.e. "ix86 5 +mmx" = P MMX, "ix86 6 +sse" = P III). This would ease adding and dropping (and specifying required) arch support immensely in the future. (A different syntax like "ix86-5-mmx" might be better, consider this a matter of discussion.) I know it isn't simple to make these changes in Debian. What do you think? Julian.
Re: Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote: While we're at it, I fail to see the logic of removing support for i386 while we still support m68k. Because there is a bug that only applies to i386 (see the subject). I wish everybody would focus on fixing this specific bug. There may be many good or bad things that can be said about dropping architecture support. This is not what this bug is about: we need to fix a real problem here (C++ ABI compatibility with other Linux distributions). The discussion is now about *how* to fix this bug: 1. just bump minimum supported i386-family processor to i486 2. like 1, but bump to some other processor. this is not strictly needed to fix the bug, but it might be a good idea for other reasons. Dropping other architectures to fix this bug is probably not a good idea, as it won't fix the bug. 3. bump the supported processor, and rename the port 4. like 3, and also add an i386 distribution which does not support C++ at all 5. like 4, but support C++ in a way incompatible with other Linux distributions in the i386 distribution. There are probably more options, but anybody proposing them, or speaking in favour or against one of these options should ask herself whether the message really helps in resolving this bug. Regards, Martin
Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote: As I say this, I'm sure people can say the same about i486 and even i386 machines. Why exactly do we need to remove this support? Read the bug report with the number you put in your Subject. Regards, Martin
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sat, Jun 21, 2003 at 12:37:21PM -0500, John Goerzen wrote: > On Fri, Jun 20, 2003 at 09:11:41PM +0200, Cyrille Chepelov wrote: > > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support > > for 386 and 486, I'd love if I could keep my home edgge router running the > > way it is thank you very much (and I'm happy with the great job the Security > > Team is doing). Not that the flea market value of a Pentium Classic is that > > high nowadays, but why fix what works? I thought Free Software was above > > planned obsolescence... > > While we're at it, I fail to see the logic of removing support for i386 > while we still support m68k. Because there are m68k maintainers and m68k boxes with enough disk-space and memory to buildall the packages. And a 68060 should be a match for low-end pentiums, should it not ? Friendly, Sven Luther
Bug#198158: architecture i386 isn't i386 anymore
On Sat, 21 Jun 2003, John Goerzen wrote: > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > Note that my idea was about patching the kernel that so the newer opcodes > > would be emulated in software. Everything would still work even on a 386, > > just slower -- and the speed decrease can be removed by running apt-build. > I don't see how that suggestion can possibly be taken seriously. Very few > i386 machines have the requisite disk space, memory, and swap space to build > large applications in Debian today. You do have a Pentium 17 10^38Mhz machine nearby, don't you? Apt-build doesn't even give the option of avoiding creation of .debs, and the bigger machine is one scp (or two mcopys in an extreme case) away. -- 1KB
Re: Bug#198158: architecture i386 isn't i386 anymore
Sebastian Kapfer wrote: I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote would count... I once read somewhere that you should _never_ compile in 486 optimizations for use in processors other than the 486. Apparently since 486 optimized code is padded a lot with NOPs. Apparently you are much better off on a Pentium or Athlon with i386 optimized code than i486 optimized one. Hence if we are going to migrate from i386, we should not go to CPU like i486 and just move to a Pentium Classic code (i586). - Adam PS. ASAIK, i486 is very similar to i386 if you compare them to a i585 processor. Not too many new instructions there.
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > On Fri, 20 Jun 2003, Stephen Stafford wrote: > > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > > > What about perusing the INT 6 idea, and going all the way up to i686? > > While I support the removal of 386 support, I absolutely and strenuously > > object to going to 686. 686 isn't all that old at all (1997 IIRC), and I > > use a nunber of 4/586 machines still (I have one 486 which I use for > > embedded development and 3 P100 boxen which are used for various things like > > CVS server, gateway/firewall, testing various things). > Note that my idea was about patching the kernel that so the newer opcodes > would be emulated in software. Everything would still work even on a 386, > just slower -- and the speed decrease can be removed by running apt-build. I don't see how that suggestion can possibly be taken seriously. Very few i386 machines have the requisite disk space, memory, and swap space to build large applications in Debian today. -- John
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > What about perusing the INT 6 idea, and going all the way up to i686? > As i686 is already like ten(?) years old, I would say 99.9% [1] machines > that run sarge are 686 and higher -- thus, moving to i686-specific > optimizations would be good for the vast majority of users (this comes > from someone who set up two servers on P MMX two weeks ago :p) I have *numerous* i586 machines installed at work. Not everyone can afford to upgrade for no good reason. Our i586 makes a perfectly good and reliable firewall (thanks to the Debian shorewall package). We have another one running a few dial-in lines for our traveling employees. There are others at various times doing specific tasks. An i586 works fine for these, even 100MHz or lower, and I think removing support for it would be a fairly silly thing. As I say this, I'm sure people can say the same about i486 and even i386 machines. Why exactly do we need to remove this support? While we're at it: not everyone reading e-mail has a network connection at the same time. I can't see what those URLs are pointing to, and it would be a lot better to post at least a summary in the e-mail.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 09:11:41PM +0200, Cyrille Chepelov wrote: > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support > for 386 and 486, I'd love if I could keep my home edgge router running the > way it is thank you very much (and I'm happy with the great job the Security > Team is doing). Not that the flea market value of a Pentium Classic is that > high nowadays, but why fix what works? I thought Free Software was above > planned obsolescence... While we're at it, I fail to see the logic of removing support for i386 while we still support m68k.
Bug#198158: architecture i386 isn't i386 anymore
Sven Luther <[EMAIL PROTECTED]> wrote: [...] > Come on, we already support 11 or so arches officially, and a bunch of > other unofficially, surelly this would not be so expensive for us. IMHO it's better to be coherent with the ARCH name. If i386 arch is no more supported, let's go to the next generation until the gcc support will drop the i486. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation.
Bug#198158: architecture i386 isn't i386 anymore
On Sat, Jun 21, 2003 at 02:13:03PM +0200, Allan Sandfeld Jensen wrote: > server, and it's pleanty fast. But more specialized libraries for i686 would > be a welcomed thing, both the scheduling and additional instructions can give > _significant_ speed-ups for many applications. Prove it or lose it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpmF5MQLLh5i.pgp Description: PGP signature
Bug#198158: architecture i386 isn't i386 anymore
On Friday 20 June 2003 15:40, Josip Rodin wrote: > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > > As i686 is already like ten(?) years old, > > I was intrigued by this statement and went to look it up. > > CPU: Released: > - > 80386 1985 > 80486 1989 > Pentium 1993 > Pentium Pro 1995 > > > I would say 99.9% [1] machines that run sarge are 686 and higher > > > > [1] 90% of statistics are made up on the spot. > > Right. I can't say I have many at least one i586 and one i486 that I'd like to be able upgrade to 3.1 when > it comes out. > I think there are a few more
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote: | Package: general | Severity: serious | Tags: sarge, sid | | [please don't reassign to any gcc/libstdc++ package] | | Nathanel's summary: | http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02112.html | | A list of proposals what to do: | http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00360.html | | Some questions on this topic: | http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html | | | The solution I would favour would be: | | - drop the i386 support | | - keep the i386 architecture name | | - let dpkg-architecture output the new configuration string | (i.e. i486-linux) | | - if anybody wants to start the mini-i386 architecture, we have to | find an architecture name for it. | | changing the dpkg-architecture's ARCH string to i.e. i486 would break | a lot of build scripts ... | | comments welcome. | | | | -- | To UNSUBSCRIBE, email to [EMAIL PROTECTED] | with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] | | Please keep , a i386 or i586 architecture , for the via C3 processor . i686 architecture is not compatible with C3 . This processor is very used in the Via EPIA motherboard : See : http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21 http://www.mini-itx.com/ -- / Erwan MAS /\ | mailto:[EMAIL PROTECTED] |_/ ___| | \___\__/
Re: Bug#198158: architecture i386 isn't i386 anymore
Aaron Lehmann <[EMAIL PROTECTED]> wrote: > On Sat, Jun 21, 2003 at 03:06:17AM +0200, Sam Hocevar wrote: >>> Really? Seems wrong to me. >>Indeed. MMX and PPro are orthogonal features. > Wasn't there "Pentium MMX" in between? I have at least one computer > with one of those processors. They are orthogonal, there are both *586 and *686 with and without MMX. Iirc the development tree looks like this: -- time ---> Pentium PProPentiumII (PPro+MMX) | +--Pentium MMX cu andreas
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sat, Jun 21, 2003 at 03:06:17AM +0200, Sam Hocevar wrote: > > Really? Seems wrong to me. > >Indeed. MMX and PPro are orthogonal features. Wasn't there "Pentium MMX" in between? I have at least one computer with one of those processors.
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote: > Package: general > Severity: serious > Tags: sarge, sid > > [please don't reassign to any gcc/libstdc++ package] > > Nathanel's summary: > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02112.html > > A list of proposals what to do: > http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00360.html > > Some questions on this topic: > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html > > > The solution I would favour would be: > > - drop the i386 support > > - keep the i386 architecture name > > - let dpkg-architecture output the new configuration string > (i.e. i486-linux) > > - if anybody wants to start the mini-i386 architecture, we have to > find an architecture name for it. > > changing the dpkg-architecture's ARCH string to i.e. i486 would break > a lot of build scripts ... So, why not fix this buginess of the build script withs going for a new i486 or i686 or whatever arch, and keeping the old i386 around for now. A new autobuilder would be needed, and today, diskspace is not really an unsolvable problem for the archive, which would grow by less than 10% anyway. Later we can either drop i386 entirely, or make a mini-i386 out of it. Other solutions might be to keep i386 around for safety, and implement beside it a newer subarch-aware ix86 archive or something such, and once that does work satisfactoryly move i386 to mini-i386. Come on, we already support 11 or so arches officially, and a bunch of other unofficially, surelly this would not be so expensive for us. Friendly, Sven Luther
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003, Sebastian Kapfer wrote: > > Also P MMX seems meaningless to me. MMX was, I think, introduced in > > Pentium Pro (which is still a i586 according to uname) > > Really? Seems wrong to me. Indeed. MMX and PPro are orthogonal features. -- Sam.
Bug#198158: architecture i386 isn't i386 anymore
Le ven 20/06/2003 à 15:39, Mathieu Roy a écrit : > Skipping 386 for 486 seems acceptable because nowadays, a distro > requires more HD space and RAM than it's possible to add with usual > 386 motherboards, but dropping all Pentiums until Pentium II > generation seems completely foolish. I hope I misunderstood your > message. A 486 is still pretty usable for a server or an X terminal nowadays, so dropping it would be much more harmful than dropping. Furthermore, the difference in performance between 486 and 586 is ridiculous, while the 386->486 move gives appreciable gains. There is absolutely no reason to drop i486, this is nonsense. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, 20 Jun 2003 23:40:13 +0200, Cyrille Chepelov wrote: >> I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote >> would count... > > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard > support for 386 and 486, One of them is enough to be a showstopper. > I'd love if I could keep my home edgge router running the way it is > thank you very much (and I'm happy with the great job the Security Team > is doing). Not that the flea market value of a Pentium Classic is that > high nowadays, but why fix what works? I thought Free Software was above > planned obsolescence... Sure it's nice when you can use old hardware until it breaks, not until company XYZ wants to charge for new licenses. > (note that if there is a compelling technical reason for forking i386 > into i386-proper and i686, I'm happy with it. Have you seen it? I > haven't so far.) IANAIAP (I am not an i386 assembler programmer), but if the illegal instruction workaround which was proposed in this thread _does_ work, it would probably turn out to be the best solution. Makes your old box run Quake 3 ;-) and the guys running a 486+ kernel won't need to pay for it. Would it hurt the i386's performance too hard? A general solution to the problem would be nice. I don't know about other arch's, but Intel and AMD are inventing new instructions faster than new processor designs. Makes me wonder how a multi-architecture distro like Debian is supposed to handle that. Is there something like automatic detection of the "best" codepath given the limitations of the current CPU? Not sure what effect something like that would have on binary sizes and build times though... (And no, I'm not demanding P4-optimized word processors here! Optimization has to be restricted to packages where it really speeds up things.) -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread!
Re: Bug#198158: architecture i386 isn't i386 anymore
We run lot of P100 and P233 with hostap to provide internet access to our customers with 2.4Ghz wi-fi. And some customers have P200,233MMX as firewalls/mail servers/proxy. I think 386 boxes are really slow ... and the admins of that boxes have faster boxes to build specific packages.. but maybe not ability to rebuild all base packages and apt/dpkg/libs itself. But 486's DX (DX-50/DX2-66/DX4-100) and 586's are faster boxes to do something with them .. and inexpensives to put in a roof of building .. and being hit by storms =) and don't have another boxes to rebuild all packages. Just my 2 cents []'s On Fri, 2003-06-20 at 10:45, Stephen Stafford wrote: > On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > > On Fri, 20 Jun 2003, Stephen Stafford wrote: > > > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > > > > What about perusing the INT 6 idea, and going all the way up to i686? > > > While I support the removal of 386 support, I absolutely and strenuously > > > object to going to 686. 686 isn't all that old at all (1997 IIRC), and I > > > use a nunber of 4/586 machines still (I have one 486 which I use for > > > embedded development and 3 P100 boxen which are used for various things > > > like > > > CVS server, gateway/firewall, testing various things). > > Note that my idea was about patching the kernel that so the newer opcodes > > would be emulated in software. Everything would still work even on a 386, > > just slower -- and the speed decrease can be removed by running apt-build. > > I'm still not convinced. Your argument works just as well in reverse. If > people running >=686 want to they are perfectly capable of building the > packages to take advantage of it themselves, and FAR more able to afford the > computrons to do so (recompiling most of a system on a 486 will never be my > idea of fun...on (say) a 1GHz machine, it's far easier to do) > > I'm also still not convinced of the usefulness of these optinisations per > architecture at non-high loads. I submit that a 486 is FAR more likely to > be running at high load than a 1GHz machine. The 486 can far less afford > the performance hit from emulating instructions in software than a 1GHz > machine can by not having the small optimisations built by default. > > This basically comes down to "will a significant portion of our userbase > suffer if we do this?" Personally I think the answer is "yes". You > obviously have a different viewpoint here :) > > Cheers, > > Stephen >
Re: Bug#198158: architecture i386 isn't i386 anymore
Cyrille Chepelov <[EMAIL PROTECTED]> a tapoté : > Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit: > > > > but dropping all Pentiums until Pentium II generation > > > seems completely foolish. I hope I misunderstood your message. > > > > I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote > > would count... > > Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support > for 386 and 486, I'd love if I could keep my home edgge router running the > way it is thank you very much (and I'm happy with the great job the Security > Team is doing). Not that the flea market value of a Pentium Classic is that > high nowadays, but why fix what works? I thought Free Software was above > planned obsolescence... RedHat provide glibc for i386, i586 and i686. Why doesn't Debian provide several packages for i*86 when the package can be optimized a lot depending on the CPU type? Hard disk space on the pool? Someone mentionned gstreamer, telling it uses optimization included in i586. Why not, for this package, at the option of the maintainer, provide gstreamer*.i386 and gstreamer*.i586 in the pool? A user that try "apt-get/aptitude install gstreamer" with a computer =< i586 will get the optimized package, the others will get the legacy package. It may creates extra works but this way Debian can keep a wide support of i386 (asked by some people on that thread) while providing optimized binaries for people that run recent hardware (asked by some on people on that thread too). -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Bug#198158: architecture i386 isn't i386 anymore
Le Fri, Jun 20, 2003, à 07:15:45PM +0200, Sebastian Kapfer a écrit: > > but dropping all Pentiums until Pentium II generation > > seems completely foolish. I hope I misunderstood your message. > > I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote > would count... Hmmm. Until all of glibc, the kernel and gcc deprecate and discard support for 386 and 486, I'd love if I could keep my home edgge router running the way it is thank you very much (and I'm happy with the great job the Security Team is doing). Not that the flea market value of a Pentium Classic is that high nowadays, but why fix what works? I thought Free Software was above planned obsolescence... (note that if there is a compelling technical reason for forking i386 into i386-proper and i686, I'm happy with it. Have you seen it? I haven't so far.) -- Cyrille --
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, 2003-06-20 at 13:15, Sebastian Kapfer wrote: > I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote > would count... Making the cut at the Pentium as opposed to i486 would have some benefits; the Pentium introduced some new instructions such as cmpxchg8b that are actually used by some software, e.g. gstreamer.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 01:58:08PM -0500, Adam Heath wrote: > On Fri, 20 Jun 2003, Matt Zimmerman wrote: > > They will if they want security updates for their firewall. > > You mean debian provided security updates. Users can always upgrade and > compile software themselves. Judging by the volume of whining about potato, I estimate there are very few users willing to do this work themselves. -- - mdz
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, 20 Jun 2003, Matt Zimmerman wrote: > On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote: > > > >1918space and are masqueraded to the outside internet by a firewall/gateway > > >running Debian on a 486 or low end pentium. I believe this to be a fairly > > >significant proportion of our userbase and I'd oppose any move to > > >marginalise them like this. > > > > You will upgrade these router to sarge o newer distributions? > > They will if they want security updates for their firewall. You mean debian provided security updates. Users can always upgrade and compile software themselves.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, 20 Jun 2003 17:20:13 +0200, Mathieu Roy wrote: > If so, are you kidding? The Pentium classic (i586) was still available > in 1997. It is still available even today. Not sure where to get a mainboard for this beast, but just a week ago I saw it on a price list. > I know a lot of person who use a Pentium classic as mini-server, with is > really enough to run a local network. > > Also P MMX seems meaningless to me. MMX was, I think, introduced in > Pentium Pro (which is still a i586 according to uname) Really? Seems wrong to me. > and nowadays computers still got MMX (so what is the meaning of P MMX? > PPro? PII? PIII? PIV?). MMX was introduced with the Pentium/MMX (P55C) processor. That's a Pentium (i586) with MMX bolted on. PPro (P6, i686) doesn't have MMX (being introduced before the Pentium MMX). PII united the two designs. It features a PPro core _and_ MMX. So I guess the meaning of P MMX is pretty clear. It refers to the classic Pentium with MMX. > Skipping 386 for 486 seems acceptable because nowadays, a distro > requires more HD space and RAM than it's possible to add with usual 386 > motherboards, You could always burn a CD-ROM for /usr :-) > but dropping all Pentiums until Pentium II generation > seems completely foolish. I hope I misunderstood your message. I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote would count... -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread!
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote: > >1918space and are masqueraded to the outside internet by a firewall/gateway > >running Debian on a 486 or low end pentium. I believe this to be a fairly > >significant proportion of our userbase and I'd oppose any move to > >marginalise them like this. > > You will upgrade these router to sarge o newer distributions? They will if they want security updates for their firewall. -- - mdz
Bug#198158: architecture i386 isn't i386 anymore
* Stephen Stafford ([EMAIL PROTECTED]) [030620 15:35]: > Judging from my random contacts with users, it's a fairly usual setup to see > a network of higher (500Mhz+) end hardware machines which sit on a LAN in > 1918space and are masqueraded to the outside internet by a firewall/gateway > running Debian on a 486 or low end pentium. I believe this to be a fairly > significant proportion of our userbase and I'd oppose any move to > marginalise them like this. Well, the key problem is: debian doesn't properly support the way i386+ is constructed. That does also make problems for amd64. It would be really nice to be able to just put (additional) i686- (or 64bit-)optimized binaries in place where they are usefull, but only there and without doubling every binary. An possible way is: split i386 into subarchitectures i386-[subtype] and a plain i386, where subtype is one of i486, i586, i686, For every subtype there is a list what subtypes are acceptable in addition to plain i386 to install (so a i386-i686 would also install i386-i486 and i386-i586 packages). At creating the debian packages, normally (also with Architecture: any) only the plain i386 packages are created. If it is usefull to generate also packages for one or more subtypes they must be specified explizitly at the Architecture line. This way would also have the advantage that the existing mmx, 3dnow, ... packages (that are really just making the package list larger without adding content) can be removed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#198158: architecture i386 isn't i386 anymore
Stephen Stafford <[EMAIL PROTECTED]> writes: > I'm not fully convinced that moving up to full 686 optimisation has that > many benefits under all but the highest loads anyway (in userspace at least, > we already have processor specific kernels). Do you have a link to > a URL with studies/analysis of this? > I just want to mention that also have /lib/iX86 for libraries where optimization matters (e.g. libssl). Andy -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Packages should build-depend on what they should build-depend.
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > As i686 is already like ten(?) years old, I was intrigued by this statement and went to look it up. CPU:Released: - 80386 1985 80486 1989 Pentium 1993 Pentium Pro 1995 > I would say 99.9% [1] machines that run sarge are 686 and higher > > [1] 90% of statistics are made up on the spot. Right. I can't say I have many
Bug#198158: architecture i386 isn't i386 anymore
Adam Borowski <[EMAIL PROTECTED]> a tapoté : > > In any case we need to make clear if we allow 486 optimisation that > > are not i386 compatible or not. > What about perusing the INT 6 idea, and going all the way up to i686? > As i686 is already like ten(?) years old, I would say 99.9% [1] machines > that run sarge are 686 and higher -- thus, moving to i686-specific > optimizations would be good for the vast majority of users (this comes > from someone who set up two servers on P MMX two weeks ago :p) > > If speed on archaic machines is an issue, you can always use the > wonderful piece of software called apt-build. You said that "if speed on archaic machines is an issue, you can always use the wonderful piece of software called apt-build.". You replied to a message that asked "if we allow 486 optimisation that are not i386 are not i386 compatible or not". It's not a matter of harmless optimisation (nobody will object about that) but of incompatible optimisation. Are you proposing to make Debian for i*86 a distribution incompatible with < i686? If so, are you kidding? The Pentium classic (i586) was still available in 1997. I know a lot of person who use a Pentium classic as mini-server, with is really enough to run a local network. Also P MMX seems meaningless to me. MMX was, I think, introduced in Pentium Pro (which is still a i586 according to uname) and nowadays computers still got MMX (so what is the meaning of P MMX? PPro? PII? PIII? PIV?). And, what do you mean by higher than i686? i64? Skipping 386 for 486 seems acceptable because nowadays, a distro requires more HD space and RAM than it's possible to add with usual 386 motherboards, but dropping all Pentiums until Pentium II generation seems completely foolish. I hope I misunderstood your message. > [1] 90% of statistics are made up on the spot. 90% of meaningless statistics, you mean? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 03:28:02PM +0200, Adam Borowski wrote: > On Fri, 20 Jun 2003, Stephen Stafford wrote: > > On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > > > What about perusing the INT 6 idea, and going all the way up to i686? > > While I support the removal of 386 support, I absolutely and strenuously > > object to going to 686. 686 isn't all that old at all (1997 IIRC), and I > > use a nunber of 4/586 machines still (I have one 486 which I use for > > embedded development and 3 P100 boxen which are used for various things like > > CVS server, gateway/firewall, testing various things). > Note that my idea was about patching the kernel that so the newer opcodes > would be emulated in software. Everything would still work even on a 386, > just slower -- and the speed decrease can be removed by running apt-build. I'm still not convinced. Your argument works just as well in reverse. If people running >=686 want to they are perfectly capable of building the packages to take advantage of it themselves, and FAR more able to afford the computrons to do so (recompiling most of a system on a 486 will never be my idea of fun...on (say) a 1GHz machine, it's far easier to do) I'm also still not convinced of the usefulness of these optinisations per architecture at non-high loads. I submit that a 486 is FAR more likely to be running at high load than a 1GHz machine. The 486 can far less afford the performance hit from emulating instructions in software than a 1GHz machine can by not having the small optimisations built by default. This basically comes down to "will a significant portion of our userbase suffer if we do this?" Personally I think the answer is "yes". You obviously have a different viewpoint here :) Cheers, Stephen
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: > I would say 99.9% [1] machines that run sarge are 686 and higher -- Please provide real data that backs this assertion up. > moving to i686-specific optimizations would be good for the vast > majority of users Please provide real data that backs this assertion up. Thank you in advance, Marcelo
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 03:26:08PM +0200, Giacomo A. Catenazzi wrote: > > Stephen Stafford wrote: > > >While I support the removal of 386 support, I absolutely and strenuously > >object to going to 686. 686 isn't all that old at all (1997 IIRC), and I > >use a nunber of 4/586 machines still (I have one 486 which I use for > >embedded development and 3 P100 boxen which are used for various things > >like > >CVS server, gateway/firewall, testing various things). > > > >Judging from my random contacts with users, it's a fairly usual setup to > >see > >a network of higher (500Mhz+) end hardware machines which sit on a LAN in > >1918space and are masqueraded to the outside internet by a firewall/gateway > >running Debian on a 486 or low end pentium. I believe this to be a fairly > >significant proportion of our userbase and I'd oppose any move to > >marginalise them like this. > > You will upgrade these router to sarge o newer distributions? > i think removal of some 486sx will have some advantages (removal of > software floating point support in kernels/disks.. I fail to see the gain in this. If you don't need software floating point, then it isn't used AFAIK. Although, yes...in principle, I'm happy enough to drop 486sx support if it's shown to have any real benefits. I believe we should retain 486dx support though. Cheers, Stephen
