Multi-processor chips.

S

Symon

Guest
Dear Group,
I read this today about the challenges facing programmers of "Newer chips
with multiple processors".
http://www.nytimes.com/2007/12/17/technology/17chip.html
It made me wonder if the people advocating using 'C'-like languages to
describe hardware might have it arse about face. Maybe we should think about
programming software with languages more like an HDL? I guess some folks
already are.
http://en.wikipedia.org/wiki/Concurrent_computing
If only I had time to think this through properly...
Cheers, Syms.
 
On Dec 18, 6:08 am, "Symon" <symon_bre...@hotmail.com> wrote:
Dear Group,
I read this today about the challenges facing programmers of "Newer chips
with multiple processors".http://www.nytimes.com/2007/12/17/technology/17chip.html
It made me wonder if the people advocating using 'C'-like languages to
describe hardware might have it arse about face. Maybe we should think about
programming software with languages more like an HDL? I guess some folks
already are.http://en.wikipedia.org/wiki/Concurrent_computing
If only I had time to think this through properly...
Cheers, Syms.
I've often thought about this myself... I've noticed that completely
synchronous descriptions (clocked processes) are fairly analogous to a
shared memory communication approach with rigid scheduling, but
concurrent assignments (and combinatorial processes) are more of a
message passing approach. So in one language we have the equivalent of
both major styles of communication available.

Andy
 
On Dec 18, 6:08 am, "Symon" <symon_bre...@hotmail.com> wrote:
Dear Group,
I read this today about the challenges facing programmers of "Newer chips
with multiple processors".http://www.nytimes.com/2007/12/17/technology/17chip.html
It made me wonder if the people advocating using 'C'-like languages to
describe hardware might have it arse about face. Maybe we should think about
programming software with languages more like an HDL?
It depends on the designer's preferred abstraction
and what is possible in software compilers, and in
the hardware itself.

Certainly HDLs can cover all the bases with communicating
sequential processes, but not everyone will want to design
that way, and some smart compiler just might provide a cleaner slate.

I remember writing 8048 assembly code where the
programmer had to sort out the memory page
and decide between on-page vs off-page jumps.
Clearly some things are better off left
in abstraction that is fixed up by system software.

Another challenge facing programmers, is how
to best design applications targeted to
a worldwide cloud of servers as google does.

I've often thought about this myself... I've noticed that completely
synchronous descriptions (clocked processes) are fairly analogous to a
shared memory communication approach with rigid scheduling, but
concurrent assignments (and combinatorial processes) are more of a
message passing approach. So in one language we have the equivalent of
both major styles of communication available.

Andy
Yes, but most hardware designs require port maps
to wire up multiple entities.
At this level, procedural code is thrown out the window.

-- Mike Treseler
 

Welcome to EDABoard.com

Sponsor

Back
Top