Re: [oc] think different (was: Beyond Transmeta...)

[Jecel Assumpcao Jr <jecel@merlintec.com>]

Marko Mlinar wrote:
> I noticed you have quite a overwiew in this field, but I somehow
> disagree with you. I think that code should be written in C/C++
> or Java, but then somehow converted to parallel languages.
> I know this cannot be done by any currently used algorithms,
> but I am working on it :) I've already found some formal decisions
> you can make in certain cases to achieve parallity in (relatively) non-
> parallel programs.

At least with Java you have a standard thread system which encourages
you to include large grain parallelism in your programs.

The problem with C/C++ (or X86 binaries) is that they are too low
level. You have transformed the programmer's high level specifications
(where most of the parallelism is) into low level pointer manipulations
and scalar data transfers. To get more than a small amount of fine
grain parallelism (instruction level parallelism: ILP) you will have to
extract some higher level data flow representation from the code. I
feel you can get better results if you don't throw away the high level
information in the first place.

> Functional languages would be perfect for such computers, but
> problem is that nobody uses them...

It is still a good idea to study them. A programmer who knows APL, for
example, can usually do a better job when programming in C than another
programmer who knows nothing but C.

> or2000 is almost completly build on dataflow idea :)

Which is why I am keeping this thread in the list instead of replying
via private email. And I would like to thank Jonathan Bradbury for the
very interesting link on reconfigurable computing.

My interest is basically this: will the Open Core cpus be able to
decompress MPEG-2 and MPEG-4 video? One way to do this would be to have
a decoder core which is simply added to a design when needed. It would
fit this group's current organization very well and is how nearly all
video capable products now in the market were designed. The problem is
that the core can't adapt as standards evolve and it doesn't help other
applications at all (it just sits there wasting silicon when you are
simulating a spaceship, for example).

So a core that can parallelize and accelerate math intensive code in
general *and* decode MPEG as well would be a very valuable thing to
have.

-- Jecel