I have come to question the wisdom of the i486 optimisation in Slackware. That's frankly a bit too compatible for my liking. Let's briefly first review the various generations of cpu we are actually talking about
/begin optional history lesson.
80386: Intel's first (and worst) 32 bit cpu.
80486: Didn't make all the mistakes they made in the '386, only half of them. More stuff inside, although they still halved it and tried to sell you it twice by removing a coprocessor and selling one separately in some models. Licensed to amd also, which gave the latter ideas.486 optimizations made sense because the 386 was such a vision less piece of hardware. I bought the fastest of them, a 486/DX100(Mhz) in 1994, as the Pentium was just becoming available.
These days we would politely advise anyone running on 0.1 Ghz and < 100 Megs of ram to upgrade his box! Why is Slackware stuck here? The 486 was a very forgettable cpu.

i586 optimizations were a significant improvement over i486. Also, all mathematical software had workarounds for boxes with no maths coprocessor (Like the kernel _still_ has). And after Intel pulled it's MMX stunt in 1997, you got mmx instructions (Block move, block copy, etc). All through 1997 from January to June they sold Pentiums at up to IR£500 (~$800) each here. Then in July, they made them all obsolete by releasing the Pentium MMX, which everyone bought from then on. In December, Fifa '98, required an MMX processor. Unfortunately many parents playing Santa did not know about MMX and got caught badly. I wasn't one of them, but I would never buy an Intel chip by choice from then on.

i686 optimizations (Pentium II, K6 & friends)didn't help much as the chips couldn't turn a hardware superiority into a speed advantage.

From then on it's much more processor specific, and grand generalizations like those above just make an idiot out of anyone who attempts them.
/end optional history lesson.

Now there is a fairly general x86_64 optimization, and for 32 bit the 1686 stuff now makes sense, although I wouldn't argue with i586 as a standard in view of the number of budget variants (Via, Cyrix, etc.) that exist, and the limited benefit to i686 chips anyhow of i686 optimizations.

This has been discussed before:
http://www.linuxquestions.org/questi...upport-808221/

Most likely no 486 could run the newest slackware (actually I posted this in that thread too, and someone has still yet to prove me wrong). I also mention that I use 64-bit, and most new processors support this, so you should use it too, and you should compile your own kernel if you really care about performance.

Also, slackware is compiled for i486 with optimizations for i686.

I guess he didnt get enough input, i mean who the hell is still using twitter these days?

I don't use twitter, and I'm not going to.

I'm ok for an upgrade to i686, unless people still need i586 support...

Maybe there should be a a survey to see if anyone runs Slackware in a processor inferior to a Pentium Pro or Pentium II, because this is the first i686 processors.

I aim to revive my first PC some fine day. It's a 386 40MHz 8MB. Not for production use, but for "recreation", or sport perhaps. DOS, FreeDOS or Linux, we'll see.

Yes, that could work, maybe a poll should be started here and see what architectures slackware is being used on. I'll start one tomorrow if no-one else does.

Not a bad idea.

I hazard a guess that there would be more potential repliers around here than on twitter.

Alright then, I'll make one right now ...

Here:
http://www.linuxquestions.org/questi...o-i686-834806/

I hope it is adequate ... these are all the architectures official Slackware can be run on.

IMO going to 686 would be a sensible move at this point in time, and is probably long overdue.
Anyone with a 486 will still have the option of running an older slackware version, and will probably want to do so anyway as the older versions tend to be a little kinder towards old hardware.

The oldest box I currently have is a P3-800 and that isn't in active use.

One interesting thing it's compare the speed of Slackware 13.1 in different flavors, like i486, i686 and x86_64.
If anyone can make this test and post some results will prove, or not, the advantages of using another optimizations.

OK fine. I will try to see if slackware 13.1 will run on my 486 laptop. Unfortunately, it is 900 miles away, so it will have to wait a few months. It was running slackware 11, I think. It will be quite a test of course, having only, 33mhz? clock, 12mb of ram and 200mb hard drive. I did have X running on there, but it wasn't pretty. Of course if it doesn't work anymore, this test may not occur.

Of course the applications that you use on something this old might be in question. What do you consider, if can run, the current slackware is usable?

Also note, that I installed this slackware system with ZipSlack. So either the test would only be an upgrade or an install with cooperation with something older like that. I don't think the huge kernel will boot that thing. Is this cheating? I could still boot a kernel upgraded from the custom one that it was running.

If it can run on my old laptop, higher end 486's should have much less trouble. People forget that there were a long run of 486/compatibles that rivaled much of the low end pentiums. I had one that was pretty sweet-- I should have kept it for this test Could someone with a 32mb ram, 100 MHz 486, 1gb hd, with cdrom possibly boot and run just fine? Maybe.

Put kde4 on it and see how it goes :-).

This is actually very difficult to pin down, because
1. Users opinions are subjective and dependent on things like dns queries.
2. The load running on various boxes varies, as does the efficiency with which they are set up.
3. The standard cpu had 4 clock cycles per instruction (for instructions with no operand like a no-op): address program; Fetch instruction; decode instruction; execute. Now we have so much guessing ahead, caching, etc. that is next to impossible to say whet the cpu is doing at any point.

What most of the stuff people call optimising actually does is allow more elegant, efficient and economical ways of getting the same job done, and it is generally agreed that these make for greater cpu efficiency over time. The perfect example is the mmx instructions - block moves and copies. One instruction tells the cpu to transfer several hundred bytes, so you change from
instruiction cycle
write cycle
instruiction cycle
write cycle
instruiction cycle
write cycle etc

to

instruction cycle
write cycle
write cycle
write cycle
write cycle
write cycle etc

It's just a shame to buy an AthlonXP because it's so much better than a Pentium, and then shackle yourself to the limits of the pentium's forerunner. Worth changing distribution for? Well, I'm thinking about it. Particularly as the AthlonXP begins to show it's age, it's nice to liberate it a little more.

As a test, I installed Slackware 13.1 in a Virtual machine with the virtual CPU set to emulate an i486 (qemu-system-x86_64 -cpu 486 -vga std -m 512 ....).

And indeed, Slackware installs without a glitch (using the huge.s non-SMP kernel which is compiled to be compatible with i486, as opposed to the SMP kernel which will not run on a i486).
And XFCE starts and runs fine in that virtual machine. I tried compiling one of my packages in the VM (because I remembered someone commented once on our current gcc package not being fit for i486) and the compilation finished without errors or issues.
Even the binary 32-bit firefox package (Slackware does not compile firefox for the 32-bit platform and instead uses the pre-compiled Mozilla binaries) runs without issues.

Eric

1 members found this post helpful.