Re: Dropping/splitting (proper) i386 support

2003-05-17 Thread Jakob Bohm
On Tue, May 06, 2003 at 03:05:21PM +0200, Guillem Jover wrote: > Hi, > > On Mon, May 05, 2003 at 06:27:05PM -0400, Nathanael Nerode wrote: > > After the 486, Intel always provided a method to determine the CPU type and > > features available. As far as I can tell, there's no easy programmatic wa

Re: Dropping/splitting (proper) i386 support

2003-04-30 Thread Matthias Klose
Neil Roeth writes: > Nice summary. > > * Drop i386 support mostly. 'i386' architecture becomes 'i486'. > > Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture, > > but don't require that any packages build on it in order to go into > > testing or to release Debian; it would be

Re: Dropping/splitting (proper) i386 support

2003-04-30 Thread Matthias Klose
Hamish Moffatt writes: > On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote: > > This is an attempt to summarize some points. > > > > 1. Why do we have a problem, other than performance issues? > > > > * To maintain binary compatibility with other distributions for C++ > > packages, D

Dropping/splitting (proper) i386 support

2003-04-29 Thread Neil Roeth
Nice summary. Comments below. On Apr 27, Nathanael Nerode ([EMAIL PROTECTED]) wrote: > This is an attempt to summarize some points. [snip] > 3. How much impact will this have on users? > * Two people have reported live 386 systems (not clear if they're using > Debian): > 4. Conclusion. > T

Re: Dropping/splitting (proper) i386 support

2003-04-29 Thread Adrian 'Dagurashibanipal' von Bidder
On Tuesday 29 April 2003 16:40, Hamish Moffatt wrote: > On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote: > > * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.). > > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.ht > >ml Not sure if ther

Re: Dropping/splitting (proper) i386 support

2003-04-29 Thread Hamish Moffatt
On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote: > This is an attempt to summarize some points. > > 1. Why do we have a problem, other than performance issues? > > * To maintain binary compatibility with other distributions for C++ > packages, Debian needs to use the i486+ version

Re: Dropping/splitting (proper) i386 support

2003-04-28 Thread Richard Braakman
On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote: > This is an attempt to summarize some points. > > 1. Why do we have a problem, other than performance issues? > > * To maintain binary compatibility with other distributions for C++ > packages, Debian needs to use the i486+ versi

Re: Dropping/splitting (proper) i386 support

2003-04-27 Thread Dagfinn Ilmari Mannsåker
Bas Zoetekouw <[EMAIL PROTECTED]> writes: > BTW: do you have any quantative numbers on the i386/i486 performance > issues (e.g. for openssl)? I hacked up a quick script () that compares two 'openssl speed' outputs and gives you the ratio, here's the output for i386 vs i4

Re: Dropping/splitting (proper) i386 support

2003-04-27 Thread Bas Zoetekouw
Hi Nathanael! You wrote: > * Drop i386 support mostly. 'i386' architecture becomes 'i486'. > Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture, > but don't require that any packages build on it in order to go into > testing or to release Debian; it would be a bonus architec

Re: Dropping/splitting (proper) i386 support

2003-04-27 Thread Falk Hueffner
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Oddly, it looks like GCC doesn't currently ever generate > 486-specific instructions; they are only (currently) of benefit to > assembly programmers. (Hmm... maybe I should see if there's an > enhancement opportunity to GCC there.) I have a patch fl

Dropping/splitting (proper) i386 support

2003-04-27 Thread Nathanael Nerode
This is an attempt to summarize some points. 1. Why do we have a problem, other than performance issues? * To maintain binary compatibility with other distributions for C++ packages, Debian needs to use the i486+ version of atomicity.h supplied by GCC. * This version is significantly faster tha