[M3devel] onoing hardware clearance.

[Daniel Alejandro Benavides D.]

Hi all:
I heard from a U. Delaware Professor that they were working in Open64 research compiler, the exact details I don't know, but they did have a machine super (symmetric) multiprocessor and he told they were trying with Microthreads (in his brief conference he said that Win nor Linux were amenable for that, that is, inefficient), when I asked his opinion about Pascal, he told preferred speed than anything else, sadly, but I myself prefer good compromise between speed (execution) and safety (and they are related truly, precisely, this was evident in the ARX project when the compiled code was double size for ARM compared to 32016 back in Acorn days before Olivetti, I think they compiled code for they SUN NeWS for it too which was as far as I know C plus classes or at least something like that). 
If I may say so, there are other attempt to make safe C, CCured is one, they inserted RT calls to detect RT otherwise failures, very much like SPIN did. 

Thanks in advance

--- El sáb, 4/6/11, Mika Nystrom <mika at async.caltech.edu> escribió:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] onoing hardware clearance.
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: m3devel at elegosoft.com
> Fecha: sábado, 4 de junio, 2011 21:48
> ...
> >Use of pthreads was a major step toward gaining
> portability=2C besides perf=
> >ormance on multiprocessor systems (i.e. all systems).
> >Short of that=2C we did switch to
> get/set/make/swapcontext for user threads=
> >.
> >And sigaltstack on some platforms.
> >OpenBSD is the only outlier I think -- pthreads=2C but
> for userthreads we s=
> >till hack on the jmpbuf.
> ...
> 
> Too bad the pthreads implementation is broken...
> 
> But I hope we keep the user threads implementation working
> for other
> reasons.  It's far easier to add new concurrency
> mechanisms, and to
> control the overhead of threading, in the user threads
> implementation
> than in the pthreads one.
> 
> I'm specifically thinking of stuff like programs with many
> threads (I mean
> millions of threads) or things like "goroutines". 
> Handling either is not
> particularly difficult with user threads.  Same with
> the stack overlapping
> tricks I was investigating a while back.  Not sure if
> it's even possible
> with pthreads.  Also consider CSP-like
> constructs.  CSP channels can be
> emulated under pthreads (indeed one would probably do it
> with the plain
> Modula-3 threading constructs) but become very
> inefficient.
> 
> Maybe M-on-N threading (or whatever it's called) would be
> necessary
> to make all this work best.  User threads within
> pthreads.  Is that
> difficult?
> 
>     Mika
> 
>