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,
| kilobyte@mimuw.edu.pl | I'm hunting wuntime ewwows!
\-----------------------/
Segmentation fault (core dumped)
Reply to: