gomp-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gomp-discuss] Organization of libgomp source code


From: Steven Bosscher
Subject: Re: [Gomp-discuss] Organization of libgomp source code
Date: 18 Feb 2003 11:40:10 +0100

Op ma 17-02-2003, om 16:40 schreef Biagio Lucini:
> On Mon, 17 Feb 2003, Lars Segerlund wrote:
> 
> > 
> >   Let's have one file for each function ?
> > 
> >   If for no other reason than that it ! might ! ( IMHO ) be easier for 
> > us with our FSF licenses ( or whatever ) to start moving part's into gcc 
> > this way.
> > 
> 
> That's fine for me, I was just putting forward my presonal taste for those
> things. But if we have to jump on the bandwagon, we'd better take the
> appropriate steps :-)
> 
> > 
> >   So I suggets we put related code in separate subdirs, .h files for the 
> > subdirs in the topdir , and make a testing directory.
> > 
> >   Shouldn't that cover most things ?
> > 
> 
> I think so. So what about a tree like
> 
>             runtime
> libgomp ->  openmp
>             test
> 
> ?
> 
> Libgomp will be our top dir, with the include and the build scripts (or
> shall we have an "include" dir?), runtime will be the location of our
> implementation of Openmp and openmp will be the location of the functions
> defined in the specs.
> 
> >   Also are we not rushing a bit on thee implementation side ? I thought 
> > we should try to find a minimal subset ? Or shall we implement straight 
> > off against the threading lib ? ( POSIX ).
> > 
> 
> I think for the openmp libraries that's the best thing to do (I mean the
> straight implementation). I guess the set of the primitives is an
> important issue for our implementation of openmp, and will concern more
> the directives. Steven, is your get_enviro file working? We'll need it
> (or better we will need the names of the variables you define there) for
> the openmp routines.
> 

It doesn't work right now because you need to set library properties
that we had not defined yet (e.g. these is no omp_num_threads variable
yet).  Also the schedule environment variable isn't implemented yet. 
Also, reading the environment should somehow just be part of the library
initialization.

So, it was just an example of how it *could* be done.  It's quite easy
to actually make it work, though.

Greetz
Steven






reply via email to

[Prev in Thread] Current Thread [Next in Thread]