> This long thread about the evils of winmodems has made me wonder about
> two things.
>
> 1) Why shouldn't hardware engineers make cheap peripherals which
> require significant CPU assist and then just have an extra CPU around
> to ensure that the user experience is responsive while one CPU is
> doing things like the modem or sound processing. It seems to me that a
> cheap SMP box would be much more useful than a computer with a whole
> bunch of seldom used specialized chips in it. I'd love to have my
> kernel compiles double in speed just by shutting down my modem or
> sound card.
>
It makes some sense. The problem is that soundcard chip costs about $10
and even cheap cpu's from AMD are about $40. You'll see the difference
when you compare the die size. However the advantage of software
implementation is that you can change your hardware on the fly.
I think most manufacturers like the idea that they can cure a hardware bug
by simply issuing a patch.
> This brings me to my second question about SMP:
>
> 2) Why don't CPU designers revisit the RISC revolution and make much
> simpler processors with shallower (simpler) pipelines and then pack
> two or four processors on one die creating one chip that would appear
> to the kernel as a four processors. Then let you kernel developers
> play with locking and the application software developers multithread
> their code to take advantage of it. It seems to me like it moves the
> problem of speed optimzation into software where it is much easier to
> profile and tweak. It could be that many of the fancy tweaks built
> into microprocessors today might not be getting used all that often
> because of lagging compiler technology or because the designer thought
> something was important when in fact it is rarely used in modern
> code. How do we know that the Pentium II or III is not just chocked
> full of bloat etched into silicon?
>
VLIW - Very long instruction word.
Of chips I can remember are Merced, some HP processor, and that Elbrus
stuff (from Russia). Also probably Transmeta is doing this.
You can get more info at http://infopad.eecs.berkeley.edu/CIC/
Vladimir Dergachev
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/