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
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? snip * 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: [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
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
Bug#198158: architecture i386 isn't i386 anymore
* what opcodes need to be emulated? snip * 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 neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
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.
[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[+-]subarchitecture, 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, 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: [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 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: [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
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
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, 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
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 ~{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
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
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;i20;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:50.0 +0200
@@ -388,7 +388,6 @@
DO_VM86_ERROR( 3, SIGTRAP, int3, int3)
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/
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 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.
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
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.
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: 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
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
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 ~{PmVHI~} [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 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 ~{PmVHI~} [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
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 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 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]
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.
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
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
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
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 (/
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.
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 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 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 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] |_/ ___| | \___\__/
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 i686 machines, but I can certainly think of 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 i686 than you think. The AMD K6 processors doesnt support all the i686 instructions. I still have a K6-2 300 based 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. `Allan
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
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.
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
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.
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
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.
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] 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 ... What we have not yet decided is whether we drop i386 support for C++ packages or for all packages. If we choose the former, the mini-i386 will just need to contain the important C++ packages. If we choose the later, developers can start to activate i486 optimisation in random packages. In any case we need to make clear if we allow 486 optimisation that are not i386 compatible or not. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#198158: architecture i386 isn't i386 anymore
Le ven 20/06/2003 à 10:58, Bill Allombert a écrit : What we have not yet decided is whether we drop i386 support for C++ packages or for all packages. If we choose the former, the mini-i386 will just need to contain the important C++ packages. If we choose the later, developers can start to activate i486 optimisation in random packages. In any case we need to make clear if we allow 486 optimisation that are not i386 compatible or not. As C++ packages include APT, and even if it is not required, I think it could be time to declare ourselves completely i386-incompatible. -- .''`. 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?=
Bug#198158: architecture i386 isn't i386 anymore
On Fri, 20 Jun 2003, Bill Allombert wrote: On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote: - drop the i386 support What we have not yet decided is whether we drop i386 support for C++ packages or for all packages. If we choose the former, the mini-i386 will just need to contain the important C++ packages. If we choose the later, developers can start to activate i486 optimisation in random packages. 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. 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. Regards, 1KB [1] 90% of statistics are made up on the spot. /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003 at 02:25:52PM +0200, Adam Borowski wrote: 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. 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. 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? Cheers, Stephen
Bug#198158: architecture i386 isn't i386 anymore
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.. ciao giacomo
Bug#198158: architecture i386 isn't i386 anymore
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. 1KB /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Bug#198158: architecture i386 isn't i386 anymore
On Friday 20 June 2003 13:25, Adam Borowski wrote: On Fri, 20 Jun 2003, Bill Allombert wrote: On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote: - drop the i386 support What we have not yet decided is whether we drop i386 support for C++ packages or for all packages. If we choose the former, the mini-i386 will just need to contain the important C++ packages. If we choose the later, developers can start to activate i486 optimisation in random packages. 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. 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) You are forgetting embedded processors, many of which - in current product - are 486, 586 or at best 686 (some are Via C3 which is sort of 686). So while conventional PCs may have moved on, there are a lot of potential users out there who have not - this way thay do not need fans, do not need lots of power, and are extreemly reliable. There are even some 386 processors still be sold out there in the embedded market. David If speed on archaic machines is an issue, you can always use the wonderful piece of software called apt-build. Regards, 1KB [1] 90% of statistics are made up on the spot. /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
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
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: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
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 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 i686 machines, but I can certainly think of at least one i586 and one i486 that I'd like to be able upgrade to 3.1 when it comes out. -- 2. That which causes joy or happiness.
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
* 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
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
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.
