[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: i386 compatibility & libstdc++

Hash: SHA1

On Saturday 26 April 2003 04:21, Chris Cheney wrote:
> On Sat, Apr 26, 2003 at 03:41:31AM +0200, Josselin Mouette wrote:

> > This would be a good border, but we would need to provide a much larger
> > subset of packages (if not all the distro) for 386/486/586, while we
> > would only need to provide what can run on a 386 if we set the limit
> > between 386 and 486.

The alternative is to keep providing the whole distro as i386 as well
as a subset for newer CPUs. This subset then should include all C++
applications as well as those programs that do cpu-intensive tasks
or are used a lot (e.g. all essential packages). Some of them
can even be provided for more than two CPUs (e.g. kernel or libssl).

> The last true i586 based cpu I know of was the Mobile Pentium MMX 300
> which was released around Jan 1998. If we are going to make a break at
> all it should be at the arch that makes the best speed increase for
> modern systems (Athlon/P4) imho, whichever that happens to be. Of course
> to use i686 we would need to convince GCC to fix that cmov bug which
> would keep AMD K6(?) and Via C3 from working properly on i686.

No, if you disable cmov on i686, that won't make Athlons and P4s faster
than simply using -march=i586. If all packages are available for i386,
the C3 and K6 users just won't be able to use the fast packages but can
still work. If we cripple Debian on i386 by leaving out some of the
packages, the border needs to be lower than i686, e.g. i486 or i586-mmx.

The options we currently have are:

1. drop i386 support completely: simple but painful
2. create a crippled distro for really old systems (e.g. i386 and i486)
3. keep everything the i386 way: slow and incompatible
4. like 3, but provide alternatives for new systems (i686+):
   needs a lot of work and ftp space.

	Arnd <><
Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: