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 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 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
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: 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
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
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: 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
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, 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.
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
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 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
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
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: 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
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
* 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
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
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.
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, 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
* 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
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
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.
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
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.
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: 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 distribution X to optimized toy and now foo is much faster! - I run distribution X on one PC, and optimized toy 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 foo (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
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
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
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
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
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
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
-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 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
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 ~{PmVHI~} [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
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.
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
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
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
* 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
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
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
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 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 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 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.
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 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
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.
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!
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, 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, 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
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
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
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 again I THINK 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 I'm subscribed to this list .. but with another address ;o) 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
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
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.
