
- Regarding FORTRAN array transposition:  the implementation works fine
  at present, but could perform fewer transposes.  For example, at present
  all ND args are transposed when BOTH entering AND leaving the routine.
  However, args known to be only input do not need to be re-transposed
  at routine exit ... this would be accomplished by NOT storing the
  transposed_array->data pointer into the original_array->data, and
  instead just allowing transpose() to return transposed_array proper.
  Also, transposable array args are not yet vectorizable, because
  transpose(3D) != [transpose(2D), ... , transpose(2D)] ... the former
  is how SLIRP currently transposes, but the latter (harder approach)
  would be needed.

- Regarding the slirptypes.c array

	static Reserved_Opaque_Type Reserved_Opaque_Types[]

  /* In principle this list could be sorted by SLtype value, in order */
  /* to speed traversals with bsearch.  However, since SLtype values  */
  /* may change in new releases of S-Lang that would be fragile.  So, */
  /* instead we ordered by expected frequency of use for each SLtype. */

  Also, it must be kept in sync with the _define_reserved_opaque block()
  of definitions w/in slirpmaps.sl.

- slang_abi_mismatch():  since slirp requires 1.4.9 or greater, and slang1
  is nearly finished, it is sufficient to merely check slang1 vs. slang2.
  when slang2 abi incompatible releases emerge i will try to convince JED
  to include something like slang_abi_version for users to distinguish.

- S-Lang is statically linked into slirpsh, historically to avoid multiple
  defines (mainly on Mac OS/X) which result from its inclusion of slprepr.c;
  this file was bundled so as to add the necessary 2-3 lines of code which 
  enable callbacks, but since the switch to a custom file loader this
  approach is no longer necessary.

- See opengl folder for comments on why simply vectorizing funcs like

		glVertex3f()

   is probably not enough for OpenGL, since additional state may be
   interspersed, by other calls, such as glColor3f(), while iterating
   through the "vertex loop"

- Look at Doug's comments on how PDL vectorizes funcs for Perl
  UPDATE:

	  Have reviewed the document, but not finished yet.  It was useful
	  to remind me that I should think about how to handle collapsing
	  over multi-dimensional arrays.  For example, given

		a = Double_Type[3,5]
		a[0,*] = [1,2,3,4,5]
		a[1,*] = 2*[1,2,3,4,5]
		a[2,*] = 3*[1,2,3,4,5]

	  then
		sum(a)	= 90
		sum(a,0) = [6, 12, 18, 24, 30]
		sum(a,1) = [15, 30, 45]

- slirp_map_synonym() was removed in v1.9; it was never documented, is
  unused within SLIRP proper, and almost certainly not used elsewhere.

- OpenMP:

  Tested with Intel 9.1 & GCC 4.2 (Linux), Sun Studio 9 (Solaris),
  & GCC 4.3 (MacIntel OS X)

  In gcc 4.2 prerelease, had to disable the

	#XLDFLAGS="${XLDFLAGS} -Wl,-z,nodlopen"
                                                                                
  setting in libgomp/configure.tgt because modules need libgomp to be
  dlopen-able, separate from the parent application.  This issue has
  been reported to GCC developers, but apparently remains unaddressed
  in GCC 4.3.

  Per the Solaris documentation: the parent application into which OpenMP-
  aware dynamic libraries will be loaded ALSO must be linked with -xopenmp
  flag.  Also, OMP_NUM_THREADS must be set in environment, and at least
  -xO3 optimization must be used at compile time.  Finally, in order to
  get the Fortran name-mangling detection (autoconf feature) working I
  had to set LIBS="-xopenmp" so that the proper libs would be brought in
  at link time WHILE NOT changing the desired CFLAGS and FCFLAGS value.

  Useful Solaris utilities for investigation CPUs, speeds, etc:

  	hwinfo
  	sysinfo
	/usr/sbin/psrinfo -v

  FORTRAN issues:

	different indexing strategy needed, since parameters are
	passed by reference, not copy.  i.e.

		for (i = ...
		    func( varg[i], ...)

	cannot be used, but rather

		for (i = ...
		    func( &varg[i], ...)

	however, in general how do we tell from a C prototype
	whether, say, a double* parameter passed to an underlying
	Fortran call represents a pointer to a scalar or an
	actual array?  this info is available in the fortran source
	code, and is inspected/recorded by slirpf2c in each arguments
	symbol.dim field, but is not being inspected by top-level
	generator code slirp;  although it breaks encapsulation of
	the fortran-ness, i can't see how else to do this other than
	checking the symbol.dim field for each arg/symbol in the
	slirpf2c entryp.args[] array

- outline of ideas for vectorized s-lang "vectorize" package, which
  would contain vectorized versions of intrinsics such as 

	strlen		vstring subpackage?
	strcat

	atoi		vdata   subpackage?
	atof
	atol
	atoll
	isdigit
	tolower
	toupper

	getenv		conditionally?
	putenv		conditionally?

   as well as a function which makes it easier to define vectorized
   versions of other intrinsics:

   	defined vectorize(func, ...)
	{
	   eval("define vfunc ()  {  array_map(, func, ...); }"
	}

   the intrinsics w/in vectorize module will replace the s-lang intrisinc
   function of the same name, allow the scripts which employ it to be used
   sans modification in either vectorized or non-vectorized contexts

   Related to this is the notion of creating an module of OpenMP-parallel
   intrinsics, like

	sin
	cos
	tan
	hypot
	...

	isnan		these might/would? require our own versions of
	isinf		the underlying C routines, but that seems dubious
	min		b/c the slang interpreter already has highly
	max		optimized versions and
	typecast
	...		BUT, it might be possible to reuse slarrfun.inc
			and parts of slarrfun.c (which don't rely on
			private code) to make our own parallelized versions

    actually, funcs like

    	where
    	wherefirst
    	wherelast

   might be very easy to parallelize
