A chip too far? Where is your solution Mr Larkin? - sci.electronics.design

Message from discussion A chip too far? Where is your solution Mr Larkin?

Martin Brown

View profile

More options Aug 19 2008, 5:23 pm

Newsgroups: sci.electronics.design

From: Martin Brown <|||newspam...@nezumi.demon.co.uk>

Date: Tue, 19 Aug 2008 17:23:58 +0100

Local: Tues, Aug 19 2008 5:23 pm

Subject: Re: A chip too far? Where is your solution Mr Larkin?

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

John Larkin wrote:
> On Tue, 19 Aug 2008 15:07:51 GMT, Jan Panteltje
> <pNaonStpealm...@yahoo.com> wrote:

>> A chip too far? Where is your solution Mr Larkin?
>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortun...

>> Blowing in the wind, all blowing in the wind.

> 1. A new programming language, accompanied with a new way of teaching
> programming.

That might help a bit. But there are a lot of very important legacy
applications already out there. Like it or not we are tied into the
existing applications codebase.

> 2. A new OS, which uses a nanokernel approach and wastes processors in
> the name of reliability.

Can't fault the idea of keeping the Ring0 protected kernel as small as
possible, or giving users the least privileges needed to do their job.
But wasting performance for reliablity though is never going to fly -
not least because most times it would not have the desired effect.

Hardware enforced memory protection for threads on a timesliced CPU can
be made every bit as reliable as giving each one a physical CPU just a SMOP.

> 3. Ultimately, a new multicore cpu architecture that exerts much more
> hardware control over the things that programmers tend to screw up.

You mean like enforcing bounds checking on array and pointer access? I
am all in favour of that, current CPUs have some of the right
instructions but most production code has these safety nets optimised
out in final build. Performance, whizzy graphics and even mythical
faster benchmark figures sell kit - sadly reliablity doesn't(*).

(*) except for certain high availability mission or saftey critical kit.

> The current generations of languages, programmers, methods, and OSs
> are relics, and they don't scale.

If you don't remember your history you are doomed to repeat the same
mistakes. Do you not remember the Transputer and its lovely little
parallel processing language Occam. Scaled really well but they went
bust - probably because they were manufacturing in the UK.

http://en.wikipedia.org/wiki/Transputer

I might even be tempted to agree with you that the time is now right for
someone to try this route again. I predict lots of fun and games for
desktops with Vista and N>4 x86 compatible CPU cores.

> It will take a long time to fix things, because the current computer
> culture - academics, programmers, cpu makers, Microsoft - will fight
> for its survival.

Academics are a lot more sanguine about things than you seem to think.
Most that I know believe the market gets what the market deserves. If
people will buy vacuous buggy software with a cute interface that
crashes when the wind changes direction then manufacturers will oblige.

Regards,
Martin Brown
** Posted from http://www.teranews.com **

Reply to author Forward