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.
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%  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.
 90% of statistics are made up on the spot.
/-----------------------\ Shh, be vewy, vewy quiet,
| firstname.lastname@example.org | I'm hunting wuntime ewwows!
Segmentation fault (core dumped)