🚀 go-pugleaf

In article <8906021359.AA18991@adam.byu.edu> csa@ADAM.BYU.EDU (Lyle Bingham) writes:
>In responding to your request for debugging help with 3L Parallel FORTRAN
>I would suggest you could explore Parasoft's EXPRESS and NDB debugger.
>It is available now from various distributors.  I would suggest you
>contact Parasoft at 714-380-9739 (Larry Lessor).  If you send a private
>message with your address I can send literature.  Larry can provide the
>same as well as a list of U.K. distributors.
> 
>Rumor has it that 3L and everyone else is coming out with debuggers this
>fall.  I believe 3L has shown one in your area (prototype) this last month.
>For more information in the U.K. call Neil Heywood at 3L 0506-415959.
>
>Best Regards,
> 
>Lyle Bingham
>Computer System Architects, 950 N. University Avenue, Provo, UT  84604
>(801) 374-2300 -- (801) 374-2306 FAX -- Network access courtesy of BYU
>CSA is not associated with BYU in any manner.  Opinions are my own ...

Rumor, rumor, rumor.  That's all I hear is rumors.  I'm here to tell ya',
that breakpoint debugging is only effective for purely synchronous (aka
SIMD style) execution contexts.  My opinion has it that this class of
problems is somewhat narrow, but still significant.  It is a function
of your system requirements.  However, just chuck in a little tiny bit
of asynchonous execution, and then see what a breakpoint debugger does
for you.

Real-time multicomputers are a linear combination of both sync and async
processes.  Debugging the asynchronous thread is the nasty question to
answer.  Its kinda' equivalent to a Schaum's outline in Fourier Series:
Here's the example anamalytic set, now try it on the industrial scale
where there's real-world nonlinearity. How do you do it?  I'm not gonna
try to answer this question.

Rather, I suggest a shared memory emulation of the process structure
using Pi, from T.A. Cargill and AT&T.  I think its ludicrous to pretend
that one can preserve asynchronous process fidelity with an intrinsically
sequential debugger.  A debugger is tool, much like a crutch is to a cripple,
for examining the logical process flow, an activity that can be conducted
on a simple piece of paper.  I will state that I also use symbolic debuggers,
so I'm not immune to the "what the hell's going on syndrome."

Yet, the transputer was built with logical concurrency in mind.  That's the
ticket to linear scalable software, the thing that's gonna' save everyone.
What's important to recognize is that not everyone's needs can be resolved
by a single solution, much like pencillin can kill only the non-resistant form
of you know what.  So, I suggest that the debug builders keep in mind a
more global set of requirements.  This would be a great help to the "other
side" of engineering.  The side that must face that industrial world of 
intrinsically asynchronous execution, like a pilot reacting to a propulsion
unit failure in the middle of a dogfight.  How do you handle it?

*****
***** Disclaimer: These opinions are solely those of the author and do
***** not represent, nor should they be construed as the opinions of the
***** Ohio Supercomputer Center, The Ohio State University, or its 
***** affiliates.
*****
-=-
Richard M. Stein (aka Rick 'Transputer' Stein)
Concurrent Software Specialist @ The Ohio Supercomputer Center
Ghettoblaster vacuum cleaner architect and Trollius semi-guru
Internet: stein@pixelpump.osc.edu