Re: What architecture are we?
> > > Gcc does not currently use any non-i386 instructions when compiling
> > > for i86 targets. It does, however, apply different optimizations
> > > depending on which specific cpu is being targeted.
> > The word "currently" worries me a bit. They could suddenly start supporting
> > those instructions and newly built/rebuilt packages could start dying on
> > older architectures, possible only in rare cases. This could be immensely
> > frustrating and difficult to track down.
> I understand your concern, but I would hope the gcc maintaniner would
> notice any changes and give us a heads up. The question I think we
> need to answer is are we willing to sacrifice performance on the
> standard machines of today just to keep full compatibility with 10
> year old machines? When the time comes that packages will no longer
> run at all on older machines, we may have to provide separate packages
> for them.
I'm sure he would. But that does not mean that the 800 other packages
would be checked to make sure that they all say "-m386" and not something
else. The GCC man page lists the following options relavent to the i386:
-m486 -mno-486 -msoft-float -mno-fp-ret-in-387
I would say that "no, we shouldn't sacrifice performance on the standard
machines of today at the sake of performance on 10 year old machines",
but that is not the issue I'm asking about.
Providing different packages just so one can run on the i386 will never
happen. Sure, it's possible in theory, but in practice... see my ".sig".
A better alternative, I think, would be to have the GCC maintainer tweak
GCC just a bit so its default behavior conforms to the specifications
laid down by our illustrious leader (hi, Bruce!). I would suggest:
- optimize for i486 (maybe Pentium)
- use no instructions not available on the i386.
This shifts the requirements from every package maintainer to one person.
If Debian ever shifts to "i486 and above", then we just have to re-tweak
GCC to "use no instructions not available on the i486" and let nature take
This solution could actually happen and solves both our concerns.
( email@example.com )
In theory, theory and practice are the same. In practice, they're not.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com