From jules at codesourcery.com  Thu Jun  1 01:27:13 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Wed, 31 May 2006 21:27:13 -0400
Subject: [vsipl++] ATLAS undefines
In-Reply-To: <447DFE3F.4030508@codesourcery.com>
References: <447DE91D.6030903@codesourcery.com> <447DFE3F.4030508@codesourcery.com>
Message-ID: <447E4271.9000807@codesourcery.com>

Assem,

To follow up on our IRC discussion, I was mistaken in my earlier email 
below.

The BLAS provided in clapack/BLAS/SRC is a C implementation of the 
Fortran BLAS API.

I.e. the cdotu it provides looks like this from C/C++

	void cdotu(complex<float>* return_value,
                    int* n,
                    complex<float>* cx, int* incx,
                    complex<float>* cy, int* incy);

versus cblas_cdotu_sub, which would look like:

	void cblas_cdotu_sub(
		int n,
		complex<float>* cx, int incx,
		complex<float>* cy, int incy,
		complex<float>* return_value);

(or more accurately, void* instead of complex<float>* because C doesn't 
have complex<float> or complex when the API was created).


What we want to do is add a new way to configure VSIPL++ so that it uses 
the Fortran BLAS provided in clapack/BLAS/SRC and the Lapack provided in 
clapack/SRC.

The easiest way to do this is to have configure define 
VSIP_IMPL_USE_CBLAS to 0 when using CLAPACK's BLAS.

We don't want to break the way VSIPL++ works when it gets configured to 
use ATLAS (or MKL or ACML for that matter).  I.e. when using ATLAS, we 
should continue to have configure define VSIP_IMPL_USE_CBLAS to 1. 
Moreover, we don't want to try to use clapack/BLAS/SRC's blaswrap.h to 
abstract the difference between the Fortran and C BLAS APIs.

				-- Jules


Jules Bergmann wrote:
> Assem,
> 
> Thanks for posting this.
> 
> It looks like we're trying to use the CBLAS bindings for 
> CLAPACK/SRC/BLAS.  Unfortunately, looking at the source, it is a Fortran 
> API, with a few variances (the complex dot-product Fortran functions 
> have been converted to C "subroutines" that return the result by 
> reference).  I suspect if you tried to build other tests you would see 
> linker errors for functions like cblas_trsm, etc.
> 
> For this, we should take an approach similar to how we handled ACML:
> 
>  - Have configure define VSIP_IMPL_USE_CBLAS = 4 when using
>    CLAPACK/SRC/BLAS
> 
>  - In lapack.hpp, when VSIP_IMPL_USE_CBLAS == 4,
>     - wrap the dot-product functions to have a CBLAS interface and
>       define VSIP_IMPL_USE_CBLAS_DOT = 1.
> 
>       This should be done in a separate header file, similar to
>       acml_cblas.hpp.
> 
>     - Use Fotran API for other BLAS functions
>       (VSIP_IMPL_USE_CBLAS_OTHER = 0).
> 
> Does that sound OK?
> 
>                 -- Jules
> 
> Assem Salama wrote:
>> Everyone,
>>  As per Jule's request, this is the output of make when trying to 
>> compile convolution.cpp in the tests dir. The BLAS that I got with 
>> CLAPACK has functions similar to these but without the cblas prepended 
>> and without _sub.
>>
>> Thanks,
>> Assem Salama
>>
>>
>> ------------------------------------------------------------------------
>>
>> g++ -g -O2 -I../src -I/drive2/assem/work/checkout/vpp/tests/../src 
>> -I/include/atlas -I/include/fftw3  
>> -I/drive2/assem/work/checkout/vpp/vendor/atlas/include 
>> -I/drive2/assem/work/build/vpp_temp2/vendor/fftw/include  -o 
>> convolution.exe convolution.o -L/lib/atlas -L/lib/fftw3  
>> -L/drive2/assem/work/build/vpp_temp2/vendor/atlas/lib 
>> -L/drive2/assem/work/build/vpp_temp2/vendor/fftw/lib 
>> -L/drive2/assem/work/build/vpp_temp2/vendor/clapack 
>> -L/drive2/assem/work/build/vpp_temp2/lib -L../src/vsip -lvsip -llapack 
>> -lF77 -lcblas  -lfftw3f -lfftw3 -lfftw3l   || rm -f convolution.exe
>> convolution.o: In function `dot':
>> /drive2/assem/work/checkout/vpp/tests/../src/vsip/impl/lapack.hpp:180: 
>> undefined reference to `cblas_ddot'
>> /drive2/assem/work/checkout/vpp/tests/../src/vsip/impl/lapack.hpp:217: 
>> undefined reference to `cblas_zdotu_sub'
>> /drive2/assem/work/checkout/vpp/tests/../src/vsip/impl/lapack.hpp:179: 
>> undefined reference to `cblas_sdot'
>> /drive2/assem/work/checkout/vpp/tests/../src/vsip/impl/lapack.hpp:216: 
>> undefined reference to `cblas_cdotu_sub'
>> collect2: ld returned 1 exit status
> 
> 


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From stefan at codesourcery.com  Thu Jun  1 23:35:33 2006
From: stefan at codesourcery.com (Stefan Seefeld)
Date: Thu, 01 Jun 2006 19:35:33 -0400
Subject: patch: Fix tests/fft.cpp for long double
Message-ID: <447F79C5.1080703@codesourcery.com>

The attached patch fixes compilation errors I get for tests/fft.cpp when
configuring with --enable-fft=sal,ipp,builtin.
It simply adds some missing evaluators that explicitely disable long double
versions. The patch is checked in.

Regards,
		Stefan
-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060601/3b43bf48/attachment.ksh>

From assem at codesourcery.com  Sat Jun  3 12:25:20 2006
From: assem at codesourcery.com (Assem Salama)
Date: Sat, 03 Jun 2006 08:25:20 -0400
Subject: ATLAS Patch
Message-ID: <44817FB0.10207@codesourcery.com>

Everyone,
  This patch use the BLAS that comes with LAPACK. This allows us to not 
have to deal with ATLAS at all.

Thanks,
Assem Salama
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ChangeLog.06032006
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060603/b394a45f/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06032006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060603/b394a45f/attachment-0001.ksh>

From jules at codesourcery.com  Mon Jun  5 16:18:48 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Mon, 05 Jun 2006 12:18:48 -0400
Subject: [vsipl++] ATLAS Patch
In-Reply-To: <44817FB0.10207@codesourcery.com>
References: <44817FB0.10207@codesourcery.com>
Message-ID: <44845968.10103@codesourcery.com>

Assem Salama wrote:
> Everyone,
>  This patch use the BLAS that comes with LAPACK. This allows us to not 
> have to deal with ATLAS at all.

Assem,

I'm reviewing this patch, but I had several high-level questions:

  - have you tested it through installation?

	configure
	make install
	... set your PKG_CONFIG_PATH appropriately
	cd tests
	make -f make.standalone

  - have you tested that it doesn't break the existing configurations
    using ATLAS?

				-- Jules

> 
> 
> ------------------------------------------------------------------------
> 
> 2006-06-03  Assem Salama <assem at codesourcery.com>
> 	
> 	* configure.ac: Added a new lapack option. The user can now say
> 	  --with-lapack=simple. This will build VSIPL++ with the BLAS that
> 	  comes with CLAPACK.
> 	* vendor/GNUmakefile.inc.in: Added an option to compile the BLAS
> 	  library that comes with CLAPACK.
> 	* vendor/clapack/SRC/make.inc.in: Changed library names to liblapack.a
> 	  and libcblas.a. That way, the user can use -llapack and -lcblas.
> 	* vendor/clapack/blas/SRC/GNUmakefile.in: New file. This file used to
> 	  be Makefile. This file uses configure variable srcdir.
> 	* vendor/clapack/blas/blaswrap.h: Added a define at the top to not
> 	  redefine blas functions to f2c functions.
> 	* examples/GNUmakefile.inc.in: Changed typo that prevented VSIPL++
> 	  from finishing a complete build.
> 
> 
> ------------------------------------------------------------------------
> 
> Index: configure.ac
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/configure.ac,v
> retrieving revision 1.105
> diff -u -r1.105 configure.ac
> --- configure.ac	14 May 2006 20:57:05 -0000	1.105
> +++ configure.ac	3 Jun 2006 10:40:47 -0000
> @@ -175,8 +175,9 @@
>  		  Library), acml (AMD Core Math Library), atlas (system
>  		  ATLAS/LAPACK installation), generic (system generic
>  		  LAPACK installation), builtin (Sourcery VSIPL++'s
> -		  builtin ATLAS/C-LAPACK), and fortran-builtin (Sourcery
> -		  VSIPL++'s builtin ATLAS/Fortran-LAPACK). 
> +		  builtin ATLAS/C-LAPACK), fortran-builtin (Sourcery
> +		  VSIPL++'s builtin ATLAS/Fortran-LAPACK, and a simple (Lapack
> +                  that doesn't require atlas).). 
>  		  Specifying 'no' disables search for a LAPACK library.]),,
>    [with_lapack=probe])
>  
> @@ -492,6 +493,9 @@
>  #endif])
>  vsip_impl_avoid_posix_memalign=
>  
> +AC_CHECK_HEADERS([png.h], 
> +                 [AC_SUBST(HAVE_PNG_H, 1)], 
> +                 [], [// no prerequisites])
>  
>  #
>  # Find the FFT backends.
> @@ -1275,6 +1279,8 @@
>      lapack_packages="atlas generic1 generic2 builtin"
>    elif test "$with_lapack" == "generic"; then
>      lapack_packages="generic1 generic2"
> +  elif test "$with_lapack" == "simple"; then
> +    lapack_packages="simple";
>    else
>      lapack_packages="$with_lapack"
>    fi
> @@ -1515,6 +1521,19 @@
>          AC_MSG_RESULT([not present])
>  	continue
>        fi
> +    elif test "$trypkg" == "simple"; then
> +
> +      curdir=`pwd`
> +      CPPFLAGS="$keep_CPPFLAGS -I$srcdir/vendor/clapack/SRC"
> +      LDFLAGS="$keep_LDFLAGS -L$curdir/vendor/clapack"
> +      LIBS="$keep_LIBS -llapack -lcblas"
> +
> +      AC_SUBST(USE_SIMPLE_LAPACK, 1)
> +      
> +      lapack_use_ilaenv=0
> +      lapack_found="simple"
> +      break
>      fi
>  
> Index: vendor/GNUmakefile.inc.in
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/vendor/GNUmakefile.inc.in,v
> retrieving revision 1.15
> diff -u -r1.15 GNUmakefile.inc.in
> --- vendor/GNUmakefile.inc.in	11 May 2006 11:29:04 -0000	1.15
> +++ vendor/GNUmakefile.inc.in	3 Jun 2006 10:41:15 -0000
> @@ -12,6 +12,7 @@
>  # Variables
>  ########################################################################
>  
> +USE_SIMPLE_LAPACK  := @USE_SIMPLE_LAPACK@
>  USE_BUILTIN_ATLAS  := @USE_BUILTIN_ATLAS@
>  USE_FORTRAN_LAPACK := @USE_FORTRAN_LAPACK@
>  USE_BUILTIN_LIBF77 := @USE_BUILTIN_LIBF77@
> @@ -20,7 +21,7 @@
>  USE_BUILTIN_FFTW_DOUBLE := @USE_BUILTIN_FFTW_DOUBLE@
>  USE_BUILTIN_FFTW_LONG_DOUBLE := @USE_BUILTIN_FFTW_LONG_DOUBLE@
>  
> -vendor_CLAPACK    = vendor/clapack/lapack.a
> +vendor_CLAPACK    = vendor/clapack/liblapack.a
>  vendor_FLAPACK    = vendor/lapack/lapack.a
>  vendor_PRE_LAPACK = vendor/atlas/lib/libprelapack.a
>  vendor_USE_LAPACK = vendor/atlas/lib/liblapack.a
> @@ -33,6 +34,7 @@
>  endif
>  
>  vendor_LIBF77      = vendor/clapack/F2CLIBS/libF77/libF77.a
> +vendor_SIMPLE_BLAS = vendor/clapack/libcblas.a
>  
>  
>  vendor_ATLAS_LIBS :=				\
> @@ -104,7 +106,6 @@
>  	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > libF77.clean.log 2>&1
>  endif
>  
> -
>  clean::
>  	@echo "Cleaning ATLAS (see atlas.clean.log)"
>  	@$(MAKE) -C vendor/atlas clean > atlas.clean.log 2>&1
> @@ -123,6 +124,53 @@
>  endif # USE_FORTRAN_LAPACK
>  
>  endif # USE_BUILTIN_ATLAS
> +################################################################################
> +
> +ifdef USE_SIMPLE_LAPACK
> +all:: $(vendor_SIMPLE_BLAS) $(vendor_REF_LAPACK)
> +
> +libs += $(vendor_F77BLAS) $(vendor_REF_LAPACK)
> +
> +$(vendor_SIMPLE_BLAS):
> +	@echo "Building simple BLAS (see simpleBLAS.build.log)"
> +	@$(MAKE) -C vendor/clapack/blas/SRC all > simpleBLAS.build.log 2>&1
> +
> +ifdef USE_FORTRAN_LAPACK
> +$(vendor_FLAPACK):
> +	@echo "Building LAPACK (see lapack.build.log)"
> +	@$(MAKE) -C vendor/lapack/SRC all > lapack.build.log 2>&1
> +
> +clean::
> +	@echo "Cleaning LAPACK (see lapack.clean.log)"
> +	@$(MAKE) -C vendor/lapack/SRC clean > lapack.clean.log 2>&1
> +else
> +$(vendor_CLAPACK):
> +	@echo "Building CLAPACK (see clapack.build.log)"
> +	@$(MAKE) -C vendor/clapack/SRC all > clapack.build.log 2>&1
> +
> +clean::
> +	@echo "Cleaning CLAPACK (see clapack.clean.log)"
> +	@$(MAKE) -C vendor/clapack/SRC clean > clapack.clean.log 2>&1
> +endif # USE_FORTRAN_LAPACK
> +
> +ifdef USE_BUILTIN_LIBF77
> +all:: $(vendor_LIBF77)
> +
> +libs += $(vendor_LIBF77)
> +
> +$(vendor_LIBF77):
> +	@echo "Building libF77 (see libF77.build.log)"
> +	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 all > libF77.build.log 2>&1
> +
> +install:: $(vendor_LIBF77)
> +	$(INSTALL_DATA) $(vendor_LIBF77) $(DESTDIR)$(libdir)
> +
> +clean::
> +	@echo "Cleaning libF77 (see libF77.clean.log)"
> +	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > libF77.clean.log 2>&1
> +endif # USE_BUILTIN_LIBF77
> +
> +endif # USE_SIMPLE_LAPACK
>  
>  
>  
> Index: vendor/clapack/blas/SRC/GNUmakefile.in
> ===================================================================
> RCS file: vendor/clapack/blas/SRC/GNUmakefile.in
> diff -N vendor/clapack/blas/SRC/GNUmakefile.in
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ vendor/clapack/blas/SRC/GNUmakefile.in	3 Jun 2006 10:41:20 -0000
> @@ -0,0 +1,164 @@
> +include ../../SRC/make.inc
> +
> +srcdir = @srcdir@
> +OBJEXT = @OBJEXT@
> +
> +VPATH = $(srcdir)
> +
> +
> +#######################################################################
> +#  This is the makefile to create a library for the BLAS.
> +#  The files are grouped as follows:
> +#
> +#       SBLAS1 -- Single precision real BLAS routines
> +#       CBLAS1 -- Single precision complex BLAS routines
> +#       DBLAS1 -- Double precision real BLAS routines
> +#       ZBLAS1 -- Double precision complex BLAS routines
> +#
> +#       CB1AUX -- Real BLAS routines called by complex routines
> +#       ZB1AUX -- D.P. real BLAS routines called by d.p. complex
> +#                 routines
> +#
> +#      ALLBLAS -- Auxiliary routines for Level 2 and 3 BLAS
> +#
> +#       SBLAS2 -- Single precision real BLAS2 routines
> +#       CBLAS2 -- Single precision complex BLAS2 routines
> +#       DBLAS2 -- Double precision real BLAS2 routines
> +#       ZBLAS2 -- Double precision complex BLAS2 routines
> +#
> +#       SBLAS3 -- Single precision real BLAS3 routines
> +#       CBLAS3 -- Single precision complex BLAS3 routines
> +#       DBLAS3 -- Double precision real BLAS3 routines
> +#       ZBLAS3 -- Double precision complex BLAS3 routines
> +#
> +#  The library can be set up to include routines for any combination
> +#  of the four precisions.  To create or add to the library, enter make
> +#  followed by one or more of the precisions desired.  Some examples:
> +#       make single
> +#       make single complex
> +#       make single double complex complex16
> +#  Alternatively, the command
> +#       make
> +#  without any arguments creates a library of all four precisions.
> +#  The library is called
> +#       blas.a
> +#
> +#  To remove the object files after the library is created, enter
> +#       make clean
> +#  To force the source files to be recompiled, enter, for example,
> +#       make single FRC=FRC
> +#
> +#---------------------------------------------------------------------
> +#
> +#  Edward Anderson, University of Tennessee
> +#  March 26, 1990
> +#  Susan Ostrouchov, Last updated September 30, 1994
> +#
> +#######################################################################
> +
> +all: single double complex complex16
> + 
> +#---------------------------------------------------------
> +#  Comment out the next 6 definitions if you already have
> +#  the Level 1 BLAS.
> +#---------------------------------------------------------
> +SBLAS1 = isamax.o sasum.o saxpy.o scopy.o sdot.o snrm2.o \
> +	srot.o srotg.o sscal.o sswap.o
> +$(SBLAS1): $(FRC)
> +
> +CBLAS1 = scasum.o scnrm2.o icamax.o caxpy.o ccopy.o \
> +	cdotc.o cdotu.o csscal.o crotg.o cscal.o cswap.o
> +$(CBLAS1): $(FRC)
> +
> +DBLAS1 = idamax.o dasum.o daxpy.o dcopy.o ddot.o dnrm2.o \
> +	drot.o drotg.o dscal.o dswap.o
> +$(DBLAS1): $(FRC)
> +
> +ZBLAS1 = dcabs1.o dzasum.o dznrm2.o izamax.o zaxpy.o zcopy.o \
> +	zdotc.o zdotu.o zdscal.o zrotg.o zscal.o zswap.o
> +$(ZBLAS1): $(FRC)
> +
> +CB1AUX = isamax.o sasum.o saxpy.o scopy.o snrm2.o sscal.o
> +$(CB1AUX): $(FRC)
> +
> +ZB1AUX = idamax.o dasum.o daxpy.o dcopy.o dnrm2.o dscal.o
> +$(ZB1AUX): $(FRC)
> +
> +#---------------------------------------------------------------------
> +#  The following line defines auxiliary routines needed by both the
> +#  Level 2 and Level 3 BLAS.  Comment it out only if you already have
> +#  both the Level 2 and 3 BLAS.
> +#---------------------------------------------------------------------
> +ALLBLAS  = lsame.o xerbla.o
> +$(ALLBLAS) : $(FRC)
> +
> +#---------------------------------------------------------
> +#  Comment out the next 4 definitions if you already have
> +#  the Level 2 BLAS.
> +#---------------------------------------------------------
> +SBLAS2 = sgemv.o sgbmv.o ssymv.o ssbmv.o sspmv.o \
> +	strmv.o stbmv.o stpmv.o strsv.o stbsv.o stpsv.o \
> +	sger.o ssyr.o sspr.o ssyr2.o sspr2.o
> +$(SBLAS2): $(FRC)
> +
> +CBLAS2 = cgemv.o cgbmv.o chemv.o chbmv.o chpmv.o \
> +	ctrmv.o ctbmv.o ctpmv.o ctrsv.o ctbsv.o ctpsv.o \
> +	cgerc.o cgeru.o cher.o chpr.o cher2.o chpr2.o
> +$(CBLAS2): $(FRC)
> +
> +DBLAS2 = dgemv.o dgbmv.o dsymv.o dsbmv.o dspmv.o \
> +	dtrmv.o dtbmv.o dtpmv.o dtrsv.o dtbsv.o dtpsv.o \
> +	dger.o dsyr.o dspr.o dsyr2.o dspr2.o
> +$(DBLAS2): $(FRC)
> +
> +ZBLAS2 = zgemv.o zgbmv.o zhemv.o zhbmv.o zhpmv.o \
> +	ztrmv.o ztbmv.o ztpmv.o ztrsv.o ztbsv.o ztpsv.o \
> +	zgerc.o zgeru.o zher.o zhpr.o zher2.o zhpr2.o
> +$(ZBLAS2): $(FRC)
> +
> +#---------------------------------------------------------
> +#  Comment out the next 4 definitions if you already have
> +#  the Level 3 BLAS.
> +#---------------------------------------------------------
> +SBLAS3 = sgemm.o ssymm.o ssyrk.o ssyr2k.o strmm.o strsm.o 
> +$(SBLAS3): $(FRC)
> +
> +CBLAS3 = cgemm.o csymm.o csyrk.o csyr2k.o ctrmm.o ctrsm.o \
> +	chemm.o cherk.o cher2k.o
> +$(CBLAS3): $(FRC)
> +
> +DBLAS3 = dgemm.o dsymm.o dsyrk.o dsyr2k.o dtrmm.o dtrsm.o
> +$(DBLAS3): $(FRC)
> +
> +ZBLAS3 = zgemm.o zsymm.o zsyrk.o zsyr2k.o ztrmm.o ztrsm.o \
> +	zhemm.o zherk.o zher2k.o
> +$(ZBLAS3): $(FRC)
> +
> +
> +single: $(SBLAS1) $(ALLBLAS) $(SBLAS2) $(SBLAS3)
> +	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(SBLAS1) $(ALLBLAS) \
> +	$(SBLAS2) $(SBLAS3)
> +	$(RANLIB) $(BLASLIB)
> +
> +double: $(DBLAS1) $(ALLBLAS) $(DBLAS2) $(DBLAS3)
> +	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(DBLAS1) $(ALLBLAS) \
> +	$(DBLAS2) $(DBLAS3)
> +	$(RANLIB) $(BLASLIB)
> +
> +complex: $(CBLAS1) $(CB1AUX) $(ALLBLAS) $(CBLAS2) $(CBLAS3)
> +	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(CBLAS1) $(CB1AUX) \
> +	$(ALLBLAS) $(CBLAS2) $(CBLAS3)
> +	$(RANLIB) $(BLASLIB)
> +
> +complex16: $(ZBLAS1) $(ZB1AUX) $(ALLBLAS) $(ZBLAS2) $(ZBLAS3)
> +	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(ZBLAS1) $(ZB1AUX) \
> +	$(ALLBLAS) $(ZBLAS2) $(ZBLAS3)
> +	$(RANLIB) $(BLASLIB)
> +
> +FRC:
> +	@FRC=$(FRC)
> +
> +clean:
> +	rm -f *.o
> +
> +
> Index: vendor/clapack/blas/SRC/Makefile
> ===================================================================
> RCS file: vendor/clapack/blas/SRC/Makefile
> diff -N vendor/clapack/blas/SRC/Makefile
> --- vendor/clapack/blas/SRC/Makefile	16 Mar 2006 23:11:40 -0000	1.1.1.1
> +++ /dev/null	1 Jan 1970 00:00:00 -0000
> @@ -1,160 +0,0 @@
> -include ../../make.inc
> -
> -#######################################################################
> -#  This is the makefile to create a library for the BLAS.
> -#  The files are grouped as follows:
> -#
> -#       SBLAS1 -- Single precision real BLAS routines
> -#       CBLAS1 -- Single precision complex BLAS routines
> -#       DBLAS1 -- Double precision real BLAS routines
> -#       ZBLAS1 -- Double precision complex BLAS routines
> -#
> -#       CB1AUX -- Real BLAS routines called by complex routines
> -#       ZB1AUX -- D.P. real BLAS routines called by d.p. complex
> -#                 routines
> -#
> -#      ALLBLAS -- Auxiliary routines for Level 2 and 3 BLAS
> -#
> -#       SBLAS2 -- Single precision real BLAS2 routines
> -#       CBLAS2 -- Single precision complex BLAS2 routines
> -#       DBLAS2 -- Double precision real BLAS2 routines
> -#       ZBLAS2 -- Double precision complex BLAS2 routines
> -#
> -#       SBLAS3 -- Single precision real BLAS3 routines
> -#       CBLAS3 -- Single precision complex BLAS3 routines
> -#       DBLAS3 -- Double precision real BLAS3 routines
> -#       ZBLAS3 -- Double precision complex BLAS3 routines
> -#
> -#  The library can be set up to include routines for any combination
> -#  of the four precisions.  To create or add to the library, enter make
> -#  followed by one or more of the precisions desired.  Some examples:
> -#       make single
> -#       make single complex
> -#       make single double complex complex16
> -#  Alternatively, the command
> -#       make
> -#  without any arguments creates a library of all four precisions.
> -#  The library is called
> -#       blas.a
> -#
> -#  To remove the object files after the library is created, enter
> -#       make clean
> -#  To force the source files to be recompiled, enter, for example,
> -#       make single FRC=FRC
> -#
> -#---------------------------------------------------------------------
> -#
> -#  Edward Anderson, University of Tennessee
> -#  March 26, 1990
> -#  Susan Ostrouchov, Last updated September 30, 1994
> -#
> -#######################################################################
> -
> -all: single double complex complex16
> - 
> -#---------------------------------------------------------
> -#  Comment out the next 6 definitions if you already have
> -#  the Level 1 BLAS.
> -#---------------------------------------------------------
> -SBLAS1 = isamax.o sasum.o saxpy.o scopy.o sdot.o snrm2.o \
> -	srot.o srotg.o sscal.o sswap.o
> -$(SBLAS1): $(FRC)
> -
> -CBLAS1 = scasum.o scnrm2.o icamax.o caxpy.o ccopy.o \
> -	cdotc.o cdotu.o csscal.o crotg.o cscal.o cswap.o
> -$(CBLAS1): $(FRC)
> -
> -DBLAS1 = idamax.o dasum.o daxpy.o dcopy.o ddot.o dnrm2.o \
> -	drot.o drotg.o dscal.o dswap.o
> -$(DBLAS1): $(FRC)
> -
> -ZBLAS1 = dcabs1.o dzasum.o dznrm2.o izamax.o zaxpy.o zcopy.o \
> -	zdotc.o zdotu.o zdscal.o zrotg.o zscal.o zswap.o
> -$(ZBLAS1): $(FRC)
> -
> -CB1AUX = isamax.o sasum.o saxpy.o scopy.o snrm2.o sscal.o
> -$(CB1AUX): $(FRC)
> -
> -ZB1AUX = idamax.o dasum.o daxpy.o dcopy.o dnrm2.o dscal.o
> -$(ZB1AUX): $(FRC)
> -
> -#---------------------------------------------------------------------
> -#  The following line defines auxiliary routines needed by both the
> -#  Level 2 and Level 3 BLAS.  Comment it out only if you already have
> -#  both the Level 2 and 3 BLAS.
> -#---------------------------------------------------------------------
> -ALLBLAS  = lsame.o xerbla.o
> -$(ALLBLAS) : $(FRC)
> -
> -#---------------------------------------------------------
> -#  Comment out the next 4 definitions if you already have
> -#  the Level 2 BLAS.
> -#---------------------------------------------------------
> -SBLAS2 = sgemv.o sgbmv.o ssymv.o ssbmv.o sspmv.o \
> -	strmv.o stbmv.o stpmv.o strsv.o stbsv.o stpsv.o \
> -	sger.o ssyr.o sspr.o ssyr2.o sspr2.o
> -$(SBLAS2): $(FRC)
> -
> -CBLAS2 = cgemv.o cgbmv.o chemv.o chbmv.o chpmv.o \
> -	ctrmv.o ctbmv.o ctpmv.o ctrsv.o ctbsv.o ctpsv.o \
> -	cgerc.o cgeru.o cher.o chpr.o cher2.o chpr2.o
> -$(CBLAS2): $(FRC)
> -
> -DBLAS2 = dgemv.o dgbmv.o dsymv.o dsbmv.o dspmv.o \
> -	dtrmv.o dtbmv.o dtpmv.o dtrsv.o dtbsv.o dtpsv.o \
> -	dger.o dsyr.o dspr.o dsyr2.o dspr2.o
> -$(DBLAS2): $(FRC)
> -
> -ZBLAS2 = zgemv.o zgbmv.o zhemv.o zhbmv.o zhpmv.o \
> -	ztrmv.o ztbmv.o ztpmv.o ztrsv.o ztbsv.o ztpsv.o \
> -	zgerc.o zgeru.o zher.o zhpr.o zher2.o zhpr2.o
> -$(ZBLAS2): $(FRC)
> -
> -#---------------------------------------------------------
> -#  Comment out the next 4 definitions if you already have
> -#  the Level 3 BLAS.
> -#---------------------------------------------------------
> -SBLAS3 = sgemm.o ssymm.o ssyrk.o ssyr2k.o strmm.o strsm.o 
> -$(SBLAS3): $(FRC)
> -
> -CBLAS3 = cgemm.o csymm.o csyrk.o csyr2k.o ctrmm.o ctrsm.o \
> -	chemm.o cherk.o cher2k.o
> -$(CBLAS3): $(FRC)
> -
> -DBLAS3 = dgemm.o dsymm.o dsyrk.o dsyr2k.o dtrmm.o dtrsm.o
> -$(DBLAS3): $(FRC)
> -
> -ZBLAS3 = zgemm.o zsymm.o zsyrk.o zsyr2k.o ztrmm.o ztrsm.o \
> -	zhemm.o zherk.o zher2k.o
> -$(ZBLAS3): $(FRC)
> -
> -
> -single: $(SBLAS1) $(ALLBLAS) $(SBLAS2) $(SBLAS3)
> -	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(SBLAS1) $(ALLBLAS) \
> -	$(SBLAS2) $(SBLAS3)
> -	$(RANLIB) $(BLASLIB)
> -
> -double: $(DBLAS1) $(ALLBLAS) $(DBLAS2) $(DBLAS3)
> -	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(DBLAS1) $(ALLBLAS) \
> -	$(DBLAS2) $(DBLAS3)
> -	$(RANLIB) $(BLASLIB)
> -
> -complex: $(CBLAS1) $(CB1AUX) $(ALLBLAS) $(CBLAS2) $(CBLAS3)
> -	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(CBLAS1) $(CB1AUX) \
> -	$(ALLBLAS) $(CBLAS2) $(CBLAS3)
> -	$(RANLIB) $(BLASLIB)
> -
> -complex16: $(ZBLAS1) $(ZB1AUX) $(ALLBLAS) $(ZBLAS2) $(ZBLAS3)
> -	$(ARCH) $(ARCHFLAGS) $(BLASLIB) $(ZBLAS1) $(ZB1AUX) \
> -	$(ALLBLAS) $(ZBLAS2) $(ZBLAS3)
> -	$(RANLIB) $(BLASLIB)
> -
> -FRC:
> -	@FRC=$(FRC)
> -
> -clean:
> -	rm -f *.o
> -
> -.c.o: 
> -	$(CC) $(CFLAGS) -c $*.c
> -
> Index: vendor/clapack/blas/SRC/blaswrap.h
> ===================================================================
> RCS file: /home/cvs/Repository/clapack/BLAS/SRC/blaswrap.h,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 blaswrap.h
> --- vendor/clapack/blas/SRC/blaswrap.h	16 Mar 2006 23:11:40 -0000	1.1.1.1
> +++ vendor/clapack/blas/SRC/blaswrap.h	3 Jun 2006 10:41:20 -0000
> @@ -5,6 +5,8 @@
>  #ifndef __BLASWRAP_H
>  #define __BLASWRAP_H
>  
> +#define NO_BLAS_WRAP
> +
>  #ifndef NO_BLAS_WRAP
>   
>  /* BLAS1 routines */
> ? examples/png.cpp
> Index: examples/GNUmakefile.inc.in
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/examples/GNUmakefile.inc.in,v
> retrieving revision 1.9
> diff -u -r1.9 GNUmakefile.inc.in
> --- examples/GNUmakefile.inc.in	1 May 2006 19:36:25 -0000	1.9
> +++ examples/GNUmakefile.inc.in	3 Jun 2006 12:13:25 -0000
> @@ -20,17 +20,22 @@
>  	$(patsubst $(srcdir)/%.cpp, %.$(OBJEXT), $(examples_cxx_sources))
>  cxx_sources += $(examples_cxx_sources)
>  
> +examples_targets     := examples/example1 examples/png
> +
>  ########################################################################
>  # Rules
>  ########################################################################
>  
>  all:: examples/example1$(EXEEXT)
>  
> -examples/example1$(EXEEXT): examples/example1.$(OBJEXT) $(libs)
> -	$(CXX) $(LDFLAGS) -o $@ $< -Llib -lvsip $(LIBS)
> +examples/png: override LIBS += -lvsip_csl -lpng
>  
>  install::
>  	$(INSTALL) -d $(DESTDIR)$(pkgdatadir)
>  	$(INSTALL_DATA) $(examples_cxx_sources) $(DESTDIR)$(pkgdatadir)
>  	$(INSTALL_DATA) examples/makefile.standalone \
>  	  $(DESTDIR)$(pkgdatadir)/Makefile
> +
> +$(examples_targets): %$(EXEEXT): %.$(OBJEXT) $(libs)
> +	$(CXX) $(LDFLAGS) -o $@ $< -Llib -lvsip $(LIBS)
> +
> Index: vendor/clapack/SRC/make.inc.in
> ===================================================================
> RCS file: /home/cvs/Repository/clapack/SRC/make.inc.in,v
> retrieving revision 1.4
> diff -u -r1.4 make.inc.in
> --- vendor/clapack/SRC/make.inc.in	29 Mar 2006 16:07:54 -0000	1.4
> +++ vendor/clapack/SRC/make.inc.in	3 Jun 2006 12:23:42 -0000
> @@ -45,8 +45,8 @@
>  #  machine-specific, optimized BLAS library should be used whenever
>  #  possible.)
>  #
> -BLASLIB      = ../../blas$(PLAT).a
> -LAPACKLIB    = lapack$(PLAT).a
> +BLASLIB      = ../../libcblas$(PLAT).a
> +LAPACKLIB    = liblapack$(PLAT).a
>  F2CLIB       = ../../F2CLIBS/libF77.a ../../F2CLIBS/libI77.a
>  TMGLIB       = tmglib$(PLAT).a
>  EIGSRCLIB    = eigsrc$(PLAT).a


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From jules at codesourcery.com  Mon Jun  5 17:08:31 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Mon, 05 Jun 2006 13:08:31 -0400
Subject: [vsipl++] ATLAS Patch
In-Reply-To: <44817FB0.10207@codesourcery.com>
References: <44817FB0.10207@codesourcery.com>
Message-ID: <4484650F.7050101@codesourcery.com>

Assem Salama wrote:
> Everyone,
>  This patch use the BLAS that comes with LAPACK. This allows us to not 
> have to deal with ATLAS at all.
> 
> Thanks,
> Assem Salama
> 
-------------------------------------------------------------------
> 
> Index: configure.ac
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/configure.ac,v
> retrieving revision 1.105
> diff -u -r1.105 configure.ac
> --- configure.ac	14 May 2006 20:57:05 -0000	1.105
> +++ configure.ac	3 Jun 2006 10:40:47 -0000
> @@ -175,8 +175,9 @@
>  		  Library), acml (AMD Core Math Library), atlas (system
>  		  ATLAS/LAPACK installation), generic (system generic
>  		  LAPACK installation), builtin (Sourcery VSIPL++'s
> -		  builtin ATLAS/C-LAPACK), and fortran-builtin (Sourcery
> -		  VSIPL++'s builtin ATLAS/Fortran-LAPACK). 
> +		  builtin ATLAS/C-LAPACK), fortran-builtin (Sourcery
> +		  VSIPL++'s builtin ATLAS/Fortran-LAPACK, and a simple (Lapack
> +                  that doesn't require atlas).). 
>  		  Specifying 'no' disables search for a LAPACK library.]),,
>    [with_lapack=probe])

Instead of "simple", let's call this "simple-builtin" to be consistent 
with the other builtin options.

>  
> @@ -492,6 +493,9 @@
>  #endif])
>  vsip_impl_avoid_posix_memalign=
>  
> +AC_CHECK_HEADERS([png.h], 
> +                 [AC_SUBST(HAVE_PNG_H, 1)], 
> +                 [], [// no prerequisites])

What is this doing here?

>  
>  #
>  # Find the FFT backends.
> @@ -1275,6 +1279,8 @@
>      lapack_packages="atlas generic1 generic2 builtin"
>    elif test "$with_lapack" == "generic"; then
>      lapack_packages="generic1 generic2"
> +  elif test "$with_lapack" == "simple"; then
> +    lapack_packages="simple";
>    else
>      lapack_packages="$with_lapack"
>    fi
> @@ -1515,6 +1521,19 @@
>          AC_MSG_RESULT([not present])
>  	continue
>        fi
> +    elif test "$trypkg" == "simple"; then
> +
> +      curdir=`pwd`

Because this library is builtin, we need to handle CPPFLAGS and LDFLAGS 
differently than normal.

For a normal library, such a math library that is already installed on 
the system, for example MKL, we would add -I and -L options to CPPFLAGS 
and LDFLAGS.  The CPPFLAGS/LDFLAGS would get used both for building 
VSIPL++ and they would get put into the .pc file so that applications 
built with VSIPL++ would know where to find MKL.

For a builtin library, such as LAPACK and BLAS in this case, the library 
is not already installed on the system (we are doing that as part of 
making VSIPL++).  This creates a problem.  When building the VSIPL++ 
library proper (i.e. doing a 'make' or 'make check'), we need to refer 
to the builtin library in its source tree location (it won't be 
installed in its final location until 'make install').  However, the -I 
and -L options that go into the .pc file should reflect its installed 
location, not its source tree location.

To handle this, we do the following for builtin libraries:
  - -I and -L options that are to be used while building VSIPL++ go into
    INT_CPPFLAGS and INT_LDFLAGS.
  - -I and -L options that are to be used by applications once VSIPL++
    has been installed should go into CPPFLAGS and LDFLAGS.
  - libraries that will be built go into LATE_LIBS.  Putting them
    into LIBS will break subsequent AC_LINK_IFELSE's in the
    configure file.

So you should do:

	INT_CPPFLAGS="$INT_CPPFLAGS -I$srcdir/vendor/clapack/SRC"
	INT_LDFLAGS="$INT_LDFLAGS -L$curdir/vendor/clapack"
	LATE_LIBS="$LATE_LIBS -llapack -lcblas"
	CPPFLAGS="$keep_CPPFLAGS -I$includedir/lapack"
	LDFLAGS="$keep_LDFLAGS -L$libdir/lapack"


> +      CPPFLAGS="$keep_CPPFLAGS -I$srcdir/vendor/clapack/SRC"

Are there include files in clapack/SRC that are necessary for building 
other files in the library?

> +      LDFLAGS="$keep_LDFLAGS -L$curdir/vendor/clapack"
> +      LIBS="$keep_LIBS -llapack -lcblas"
> +
> +      AC_SUBST(USE_SIMPLE_LAPACK, 1)
> +      
> +      lapack_use_ilaenv=0
> +      lapack_found="simple"
> +      break
>      fi
>  
> Index: vendor/GNUmakefile.inc.in
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/vendor/GNUmakefile.inc.in,v
> retrieving revision 1.15
> diff -u -r1.15 GNUmakefile.inc.in
> --- vendor/GNUmakefile.inc.in	11 May 2006 11:29:04 -0000	1.15
> +++ vendor/GNUmakefile.inc.in	3 Jun 2006 10:41:15 -0000
> @@ -12,6 +12,7 @@
>  # Variables
>  ########################################################################
>  
> +USE_SIMPLE_LAPACK  := @USE_SIMPLE_LAPACK@
>  USE_BUILTIN_ATLAS  := @USE_BUILTIN_ATLAS@
>  USE_FORTRAN_LAPACK := @USE_FORTRAN_LAPACK@
>  USE_BUILTIN_LIBF77 := @USE_BUILTIN_LIBF77@
> @@ -20,7 +21,7 @@
>  USE_BUILTIN_FFTW_DOUBLE := @USE_BUILTIN_FFTW_DOUBLE@
>  USE_BUILTIN_FFTW_LONG_DOUBLE := @USE_BUILTIN_FFTW_LONG_DOUBLE@
>  
> -vendor_CLAPACK    = vendor/clapack/lapack.a
> +vendor_CLAPACK    = vendor/clapack/liblapack.a

Let's keep the name as lapack.a, so that it is consitent with the 
Fortran lapack.a.

>  vendor_FLAPACK    = vendor/lapack/lapack.a
>  vendor_PRE_LAPACK = vendor/atlas/lib/libprelapack.a
>  vendor_USE_LAPACK = vendor/atlas/lib/liblapack.a
> @@ -33,6 +34,7 @@
>  endif
>  
>  vendor_LIBF77      = vendor/clapack/F2CLIBS/libF77/libF77.a
> +vendor_SIMPLE_BLAS = vendor/clapack/libcblas.a
>  
>  
>  vendor_ATLAS_LIBS :=				\
> @@ -104,7 +106,6 @@
>  	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > libF77.clean.log 2>&1
>  endif
>  
> -
>  clean::
>  	@echo "Cleaning ATLAS (see atlas.clean.log)"
>  	@$(MAKE) -C vendor/atlas clean > atlas.clean.log 2>&1
> @@ -123,6 +124,53 @@
>  endif # USE_FORTRAN_LAPACK
>  
>  endif # USE_BUILTIN_ATLAS
> +################################################################################
> +
> +ifdef USE_SIMPLE_LAPACK
> +all:: $(vendor_SIMPLE_BLAS) $(vendor_REF_LAPACK)
> +
> +libs += $(vendor_F77BLAS) $(vendor_REF_LAPACK)
> +
> +$(vendor_SIMPLE_BLAS):
> +	@echo "Building simple BLAS (see simpleBLAS.build.log)"
> +	@$(MAKE) -C vendor/clapack/blas/SRC all > simpleBLAS.build.log 2>&1
> +
> +ifdef USE_FORTRAN_LAPACK
> +$(vendor_FLAPACK):
> +	@echo "Building LAPACK (see lapack.build.log)"
> +	@$(MAKE) -C vendor/lapack/SRC all > lapack.build.log 2>&1
> +
> +clean::
> +	@echo "Cleaning LAPACK (see lapack.clean.log)"
> +	@$(MAKE) -C vendor/lapack/SRC clean > lapack.clean.log 2>&1
> +else
> +$(vendor_CLAPACK):
> +	@echo "Building CLAPACK (see clapack.build.log)"
> +	@$(MAKE) -C vendor/clapack/SRC all > clapack.build.log 2>&1
> +
> +clean::
> +	@echo "Cleaning CLAPACK (see clapack.clean.log)"
> +	@$(MAKE) -C vendor/clapack/SRC clean > clapack.clean.log 2>&1
> +endif # USE_FORTRAN_LAPACK
> +
> +ifdef USE_BUILTIN_LIBF77
> +all:: $(vendor_LIBF77)
> +
> +libs += $(vendor_LIBF77)
> +
> +$(vendor_LIBF77):
> +	@echo "Building libF77 (see libF77.build.log)"
> +	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 all > libF77.build.log 2>&1
> +
> +install:: $(vendor_LIBF77)
> +	$(INSTALL_DATA) $(vendor_LIBF77) $(DESTDIR)$(libdir)
> +
> +clean::
> +	@echo "Cleaning libF77 (see libF77.clean.log)"
> +	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > libF77.clean.log 2>&1
> +endif # USE_BUILTIN_LIBF77
> +
> +endif # USE_SIMPLE_LAPACK

We should be able to reorganize USE_BUILTIN_ATLAS and USE_SIMPL_LAPACK 
so that they share common rules (such as the rules for building LAPACK, 
LIBF77, etc).  However, let's get this working and checked in first, 
then we can fix this later.
>  
>  
>  
> Index: vendor/clapack/blas/SRC/GNUmakefile.in
> ===================================================================

Looks OK.

> Index: vendor/clapack/blas/SRC/Makefile
> ===================================================================

Looks OK.

> Index: vendor/clapack/SRC/make.inc.in
> ===================================================================
> RCS file: /home/cvs/Repository/clapack/SRC/make.inc.in,v
> retrieving revision 1.4
> diff -u -r1.4 make.inc.in
> --- vendor/clapack/SRC/make.inc.in	29 Mar 2006 16:07:54 -0000	1.4
> +++ vendor/clapack/SRC/make.inc.in	3 Jun 2006 12:23:42 -0000
> @@ -45,8 +45,8 @@
>  #  machine-specific, optimized BLAS library should be used whenever
>  #  possible.)
>  #
> -BLASLIB      = ../../blas$(PLAT).a
> -LAPACKLIB    = lapack$(PLAT).a
> +BLASLIB      = ../../libcblas$(PLAT).a

Let's call this libblas because it is a Fortran BLAS API, not a CBLAS API.

> +LAPACKLIB    = liblapack$(PLAT).a

Let's leave this name unchanged so that it stays consistent with Fortran 
Lapack.

>  F2CLIB       = ../../F2CLIBS/libF77.a ../../F2CLIBS/libI77.a
>  TMGLIB       = tmglib$(PLAT).a
>  EIGSRCLIB    = eigsrc$(PLAT).a


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From assem at codesourcery.com  Mon Jun  5 17:31:20 2006
From: assem at codesourcery.com (Assem Salama)
Date: Mon, 05 Jun 2006 13:31:20 -0400
Subject: [vsipl++] ATLAS Patch
In-Reply-To: <4484650F.7050101@codesourcery.com>
References: <44817FB0.10207@codesourcery.com> <4484650F.7050101@codesourcery.com>
Message-ID: <44846A68.3010005@codesourcery.com>


Jules,
  The reason that I had to change the lib names to lib... is because 
when I do a make check and try link with -llapack and -lcblas, it can't 
find them because they are called lapack.a and cblas.a instead of 
liblapack.a and libcblas.a.

Assem

Jules Bergmann wrote:
> Assem Salama wrote:
>> Everyone,
>>  This patch use the BLAS that comes with LAPACK. This allows us to 
>> not have to deal with ATLAS at all.
>>
>> Thanks,
>> Assem Salama
>>
> -------------------------------------------------------------------
>>
>> Index: configure.ac
>> ===================================================================
>> RCS file: /home/cvs/Repository/vpp/configure.ac,v
>> retrieving revision 1.105
>> diff -u -r1.105 configure.ac
>> --- configure.ac    14 May 2006 20:57:05 -0000    1.105
>> +++ configure.ac    3 Jun 2006 10:40:47 -0000
>> @@ -175,8 +175,9 @@
>>            Library), acml (AMD Core Math Library), atlas (system
>>            ATLAS/LAPACK installation), generic (system generic
>>            LAPACK installation), builtin (Sourcery VSIPL++'s
>> -          builtin ATLAS/C-LAPACK), and fortran-builtin (Sourcery
>> -          VSIPL++'s builtin ATLAS/Fortran-LAPACK). +          
>> builtin ATLAS/C-LAPACK), fortran-builtin (Sourcery
>> +          VSIPL++'s builtin ATLAS/Fortran-LAPACK, and a simple (Lapack
>> +                  that doesn't require atlas).).            
>> Specifying 'no' disables search for a LAPACK library.]),,
>>    [with_lapack=probe])
>
> Instead of "simple", let's call this "simple-builtin" to be consistent 
> with the other builtin options.
>
>>  
>> @@ -492,6 +493,9 @@
>>  #endif])
>>  vsip_impl_avoid_posix_memalign=
>>  
>> +AC_CHECK_HEADERS([png.h], +                 [AC_SUBST(HAVE_PNG_H, 
>> 1)], +                 [], [// no prerequisites])
>
> What is this doing here?
>
>>  
>>  #
>>  # Find the FFT backends.
>> @@ -1275,6 +1279,8 @@
>>      lapack_packages="atlas generic1 generic2 builtin"
>>    elif test "$with_lapack" == "generic"; then
>>      lapack_packages="generic1 generic2"
>> +  elif test "$with_lapack" == "simple"; then
>> +    lapack_packages="simple";
>>    else
>>      lapack_packages="$with_lapack"
>>    fi
>> @@ -1515,6 +1521,19 @@
>>          AC_MSG_RESULT([not present])
>>      continue
>>        fi
>> +    elif test "$trypkg" == "simple"; then
>> +
>> +      curdir=`pwd`
>
> Because this library is builtin, we need to handle CPPFLAGS and 
> LDFLAGS differently than normal.
>
> For a normal library, such a math library that is already installed on 
> the system, for example MKL, we would add -I and -L options to 
> CPPFLAGS and LDFLAGS.  The CPPFLAGS/LDFLAGS would get used both for 
> building VSIPL++ and they would get put into the .pc file so that 
> applications built with VSIPL++ would know where to find MKL.
>
> For a builtin library, such as LAPACK and BLAS in this case, the 
> library is not already installed on the system (we are doing that as 
> part of making VSIPL++).  This creates a problem.  When building the 
> VSIPL++ library proper (i.e. doing a 'make' or 'make check'), we need 
> to refer to the builtin library in its source tree location (it won't 
> be installed in its final location until 'make install').  However, 
> the -I and -L options that go into the .pc file should reflect its 
> installed location, not its source tree location.
>
> To handle this, we do the following for builtin libraries:
>  - -I and -L options that are to be used while building VSIPL++ go into
>    INT_CPPFLAGS and INT_LDFLAGS.
>  - -I and -L options that are to be used by applications once VSIPL++
>    has been installed should go into CPPFLAGS and LDFLAGS.
>  - libraries that will be built go into LATE_LIBS.  Putting them
>    into LIBS will break subsequent AC_LINK_IFELSE's in the
>    configure file.
>
> So you should do:
>
>     INT_CPPFLAGS="$INT_CPPFLAGS -I$srcdir/vendor/clapack/SRC"
>     INT_LDFLAGS="$INT_LDFLAGS -L$curdir/vendor/clapack"
>     LATE_LIBS="$LATE_LIBS -llapack -lcblas"
>     CPPFLAGS="$keep_CPPFLAGS -I$includedir/lapack"
>     LDFLAGS="$keep_LDFLAGS -L$libdir/lapack"
>
>
>> +      CPPFLAGS="$keep_CPPFLAGS -I$srcdir/vendor/clapack/SRC"
>
> Are there include files in clapack/SRC that are necessary for building 
> other files in the library?
>
>> +      LDFLAGS="$keep_LDFLAGS -L$curdir/vendor/clapack"
>> +      LIBS="$keep_LIBS -llapack -lcblas"
>> +
>> +      AC_SUBST(USE_SIMPLE_LAPACK, 1)
>> +      +      lapack_use_ilaenv=0
>> +      lapack_found="simple"
>> +      break
>>      fi
>>  
>> Index: vendor/GNUmakefile.inc.in
>> ===================================================================
>> RCS file: /home/cvs/Repository/vpp/vendor/GNUmakefile.inc.in,v
>> retrieving revision 1.15
>> diff -u -r1.15 GNUmakefile.inc.in
>> --- vendor/GNUmakefile.inc.in    11 May 2006 11:29:04 -0000    1.15
>> +++ vendor/GNUmakefile.inc.in    3 Jun 2006 10:41:15 -0000
>> @@ -12,6 +12,7 @@
>>  # Variables
>>  ######################################################################## 
>>
>>  
>> +USE_SIMPLE_LAPACK  := @USE_SIMPLE_LAPACK@
>>  USE_BUILTIN_ATLAS  := @USE_BUILTIN_ATLAS@
>>  USE_FORTRAN_LAPACK := @USE_FORTRAN_LAPACK@
>>  USE_BUILTIN_LIBF77 := @USE_BUILTIN_LIBF77@
>> @@ -20,7 +21,7 @@
>>  USE_BUILTIN_FFTW_DOUBLE := @USE_BUILTIN_FFTW_DOUBLE@
>>  USE_BUILTIN_FFTW_LONG_DOUBLE := @USE_BUILTIN_FFTW_LONG_DOUBLE@
>>  
>> -vendor_CLAPACK    = vendor/clapack/lapack.a
>> +vendor_CLAPACK    = vendor/clapack/liblapack.a
>
> Let's keep the name as lapack.a, so that it is consitent with the 
> Fortran lapack.a.
>
>>  vendor_FLAPACK    = vendor/lapack/lapack.a
>>  vendor_PRE_LAPACK = vendor/atlas/lib/libprelapack.a
>>  vendor_USE_LAPACK = vendor/atlas/lib/liblapack.a
>> @@ -33,6 +34,7 @@
>>  endif
>>  
>>  vendor_LIBF77      = vendor/clapack/F2CLIBS/libF77/libF77.a
>> +vendor_SIMPLE_BLAS = vendor/clapack/libcblas.a
>>  
>>  
>>  vendor_ATLAS_LIBS :=                \
>> @@ -104,7 +106,6 @@
>>      @$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > 
>> libF77.clean.log 2>&1
>>  endif
>>  
>> -
>>  clean::
>>      @echo "Cleaning ATLAS (see atlas.clean.log)"
>>      @$(MAKE) -C vendor/atlas clean > atlas.clean.log 2>&1
>> @@ -123,6 +124,53 @@
>>  endif # USE_FORTRAN_LAPACK
>>  
>>  endif # USE_BUILTIN_ATLAS
>> +################################################################################ 
>>
>> +
>> +ifdef USE_SIMPLE_LAPACK
>> +all:: $(vendor_SIMPLE_BLAS) $(vendor_REF_LAPACK)
>> +
>> +libs += $(vendor_F77BLAS) $(vendor_REF_LAPACK)
>> +
>> +$(vendor_SIMPLE_BLAS):
>> +    @echo "Building simple BLAS (see simpleBLAS.build.log)"
>> +    @$(MAKE) -C vendor/clapack/blas/SRC all > simpleBLAS.build.log 2>&1
>> +
>> +ifdef USE_FORTRAN_LAPACK
>> +$(vendor_FLAPACK):
>> +    @echo "Building LAPACK (see lapack.build.log)"
>> +    @$(MAKE) -C vendor/lapack/SRC all > lapack.build.log 2>&1
>> +
>> +clean::
>> +    @echo "Cleaning LAPACK (see lapack.clean.log)"
>> +    @$(MAKE) -C vendor/lapack/SRC clean > lapack.clean.log 2>&1
>> +else
>> +$(vendor_CLAPACK):
>> +    @echo "Building CLAPACK (see clapack.build.log)"
>> +    @$(MAKE) -C vendor/clapack/SRC all > clapack.build.log 2>&1
>> +
>> +clean::
>> +    @echo "Cleaning CLAPACK (see clapack.clean.log)"
>> +    @$(MAKE) -C vendor/clapack/SRC clean > clapack.clean.log 2>&1
>> +endif # USE_FORTRAN_LAPACK
>> +
>> +ifdef USE_BUILTIN_LIBF77
>> +all:: $(vendor_LIBF77)
>> +
>> +libs += $(vendor_LIBF77)
>> +
>> +$(vendor_LIBF77):
>> +    @echo "Building libF77 (see libF77.build.log)"
>> +    @$(MAKE) -C vendor/clapack/F2CLIBS/libF77 all > libF77.build.log 
>> 2>&1
>> +
>> +install:: $(vendor_LIBF77)
>> +    $(INSTALL_DATA) $(vendor_LIBF77) $(DESTDIR)$(libdir)
>> +
>> +clean::
>> +    @echo "Cleaning libF77 (see libF77.clean.log)"
>> +    @$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > 
>> libF77.clean.log 2>&1
>> +endif # USE_BUILTIN_LIBF77
>> +
>> +endif # USE_SIMPLE_LAPACK
>
> We should be able to reorganize USE_BUILTIN_ATLAS and USE_SIMPL_LAPACK 
> so that they share common rules (such as the rules for building 
> LAPACK, LIBF77, etc).  However, let's get this working and checked in 
> first, then we can fix this later.
>>  
>>  
>>  
>> Index: vendor/clapack/blas/SRC/GNUmakefile.in
>> ===================================================================
>
> Looks OK.
>
>> Index: vendor/clapack/blas/SRC/Makefile
>> ===================================================================
>
> Looks OK.
>
>> Index: vendor/clapack/SRC/make.inc.in
>> ===================================================================
>> RCS file: /home/cvs/Repository/clapack/SRC/make.inc.in,v
>> retrieving revision 1.4
>> diff -u -r1.4 make.inc.in
>> --- vendor/clapack/SRC/make.inc.in    29 Mar 2006 16:07:54 -0000    1.4
>> +++ vendor/clapack/SRC/make.inc.in    3 Jun 2006 12:23:42 -0000
>> @@ -45,8 +45,8 @@
>>  #  machine-specific, optimized BLAS library should be used whenever
>>  #  possible.)
>>  #
>> -BLASLIB      = ../../blas$(PLAT).a
>> -LAPACKLIB    = lapack$(PLAT).a
>> +BLASLIB      = ../../libcblas$(PLAT).a
>
> Let's call this libblas because it is a Fortran BLAS API, not a CBLAS 
> API.
>
>> +LAPACKLIB    = liblapack$(PLAT).a
>
> Let's leave this name unchanged so that it stays consistent with 
> Fortran Lapack.
>
>>  F2CLIB       = ../../F2CLIBS/libF77.a ../../F2CLIBS/libI77.a
>>  TMGLIB       = tmglib$(PLAT).a
>>  EIGSRCLIB    = eigsrc$(PLAT).a
>
>



From assem at codesourcery.com  Mon Jun  5 18:10:08 2006
From: assem at codesourcery.com (Assem Salama)
Date: Mon, 05 Jun 2006 14:10:08 -0400
Subject: Matlab IO Patch
Message-ID: <44847380.5020401@codesourcery.com>

Everyone,
  New Matlab IO patch with Jule's suggestions.

Thanks,
Assem Salama
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06052006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060605/067b23f3/attachment.ksh>

From jules at codesourcery.com  Mon Jun  5 18:22:20 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Mon, 05 Jun 2006 14:22:20 -0400
Subject: [vsipl++] ATLAS Patch
In-Reply-To: <44846A68.3010005@codesourcery.com>
References: <44817FB0.10207@codesourcery.com> <4484650F.7050101@codesourcery.com> <44846A68.3010005@codesourcery.com>
Message-ID: <4484765C.1050205@codesourcery.com>

Assem Salama wrote:
> 
> Jules,
>  The reason that I had to change the lib names to lib... is because when 
> I do a make check and try link with -llapack and -lcblas, it can't find 
> them because they are called lapack.a and cblas.a instead of liblapack.a 
> and libcblas.a.
> 

Assem,

That sounds fine.

I had some idea about renaming it when copying it, but we don't do that 
copy right now.  Even if we did, it makes sense to name it 'liblapack' 
from the start anyway.

			-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From mark at codesourcery.com  Mon Jun  5 18:26:19 2006
From: mark at codesourcery.com (Mark Mitchell)
Date: Mon, 05 Jun 2006 11:26:19 -0700
Subject: [vsipl++] Matlab IO Patch
In-Reply-To: <44847380.5020401@codesourcery.com>
References: <44847380.5020401@codesourcery.com>
Message-ID: <4484774B.6050604@codesourcery.com>

Assem Salama wrote:

> +  // is this the same class?
> +  if(!(m_view.array_flags[0] == 
> +            (matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type)))
> +    VSIP_IMPL_THROW(vsip::impl::unimplemented(
> +      "Trying to read a matrix of a different class"));

> +  // do dimensions agree?
> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for vectors
> +  if(v_dim != (m_view.dim_header.size/4))
> +    VSIP_IMPL_THROW(vsip::impl::unimplemented(
> +      "Trying to read a matrix of different dimensions"));

"unimplemented" should only be use for things that we plan to implement,
but haven't.  Do we really ever expect to read a matrix of the wrong
size?  I think most of these things should just be errors, not
unimplemented.

> +    /*
> +    strncpy(mbf.view_name.data(),
> +            reinterpret_cast<char*>(&m_view.array_name_header.size),
> +	    length);
> +    mbf.view_name[length] = 0;
> +    */

No commented-out code.  Assem, I know this has been pointed out before;
please check your patches for this before submission.


> +    // Because we don't know how the data was stored, we need to instantiate
> +    // generic_reader which can read a type and cast into a different one
> +    if(temp_data_element.type == matlab::miINT8) 
> +    {
> +      if(i==0)matlab::read<int8_t,T,r_v>(is,subview::real(mbf.v));
> +      else    matlab::read<int8_t,T,i_v>(is,subview::imag(mbf.v));
> +    }
> +    else if(temp_data_element.type == matlab::miUINT8) 
> +    {
> +      if(i==0)matlab::read<uint8_t,T,r_v>(is,subview::real(mbf.v));
> +      else    matlab::read<uint8_t,T,i_v>(is,subview::imag(mbf.v));
> +    }

This cascase of if's could be a case statement, something like this:

  istream (*fn)(istream&, subview::subview_type);
  switch (temp_data_element.type) {
    case matlab::miINT8:
      fn = matlab::read<int8_t,T,r,v>;
      break;
    case matlab::miUINT8:
      fn = matlab::read<uint8_t,T,r,v>;
      break;
    ...
  }
  if (i == 0)
    fn(is,subview::real(mbf.v));
  else
    fn(is,subview::imag(mbf.v));

I don't know if that's better; just suggesting it as possibly tidier.

> +  /// This struct is just used as a wrapper so that we can overload the
> +  /// << operator
> +  template <typename ViewT>
> +  struct Matlab_text_formatter
> +  {
> +    Matlab_text_formatter(ViewT v) : v_(v), view_name_("a")  {}
> +    Matlab_text_formatter(ViewT v,std::string name) :
> +      v_(v), view_name_(name)  {}
> +
> +    ViewT v_;
> +    std::string view_name_;
> +  };

Another approach, is to add a "write" function to Matlab_text_formatter:

  void
  Matlab_text_formatter::write(ostream& os) {
    // Whatever is currently in operator<<
  }

  inline void
  std::ostream& operator<<(std::ostream& os, Matlab_text_formater mf) {
    mf.write(os);
    return os;
  }

This is somewhat more "object-oriented".  One advantage is that you then
have a useful comment for Matlab_text_formatter:

  // A Matlab_text_formatter writes the contents of a view to a stream,
  // using the Matlab file format.

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From assem at codesourcery.com  Mon Jun  5 18:59:27 2006
From: assem at codesourcery.com (Assem Salama)
Date: Mon, 05 Jun 2006 14:59:27 -0400
Subject: [vsipl++] Matlab IO Patch
In-Reply-To: <4484774B.6050604@codesourcery.com>
References: <44847380.5020401@codesourcery.com> <4484774B.6050604@codesourcery.com>
Message-ID: <44847F0F.40800@codesourcery.com>

The reason that I have the comment is because I was planning on reading 
the array name into view_name_. I didn't know how to do that at the time 
so I just read it into a temporary array and commented out the part that 
didn't work. By leaving the comment in there for now, I will not forget 
that I was planning on fixing that part.

Thanks,
Assem Salama

Mark Mitchell wrote:
> Assem Salama wrote:
>
>   
>> +  // is this the same class?
>> +  if(!(m_view.array_flags[0] == 
>> +            (matlab::Matlab_header_traits<sizeof(scalar_type),
>> +                  std::numeric_limits<scalar_type>::is_signed,
>> +                  std::numeric_limits<scalar_type>::is_integer>::class_type)))
>> +    VSIP_IMPL_THROW(vsip::impl::unimplemented(
>> +      "Trying to read a matrix of a different class"));
>>     
>
>   
>> +  // do dimensions agree?
>> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for vectors
>> +  if(v_dim != (m_view.dim_header.size/4))
>> +    VSIP_IMPL_THROW(vsip::impl::unimplemented(
>> +      "Trying to read a matrix of different dimensions"));
>>     
>
> "unimplemented" should only be use for things that we plan to implement,
> but haven't.  Do we really ever expect to read a matrix of the wrong
> size?  I think most of these things should just be errors, not
> unimplemented.
>
>   
>> +    /*
>> +    strncpy(mbf.view_name.data(),
>> +            reinterpret_cast<char*>(&m_view.array_name_header.size),
>> +	    length);
>> +    mbf.view_name[length] = 0;
>> +    */
>>     
>
> No commented-out code.  Assem, I know this has been pointed out before;
> please check your patches for this before submission.
>
>
>   
>> +    // Because we don't know how the data was stored, we need to instantiate
>> +    // generic_reader which can read a type and cast into a different one
>> +    if(temp_data_element.type == matlab::miINT8) 
>> +    {
>> +      if(i==0)matlab::read<int8_t,T,r_v>(is,subview::real(mbf.v));
>> +      else    matlab::read<int8_t,T,i_v>(is,subview::imag(mbf.v));
>> +    }
>> +    else if(temp_data_element.type == matlab::miUINT8) 
>> +    {
>> +      if(i==0)matlab::read<uint8_t,T,r_v>(is,subview::real(mbf.v));
>> +      else    matlab::read<uint8_t,T,i_v>(is,subview::imag(mbf.v));
>> +    }
>>     
>
> This cascase of if's could be a case statement, something like this:
>
>   istream (*fn)(istream&, subview::subview_type);
>   switch (temp_data_element.type) {
>     case matlab::miINT8:
>       fn = matlab::read<int8_t,T,r,v>;
>       break;
>     case matlab::miUINT8:
>       fn = matlab::read<uint8_t,T,r,v>;
>       break;
>     ...
>   }
>   if (i == 0)
>     fn(is,subview::real(mbf.v));
>   else
>     fn(is,subview::imag(mbf.v));
>
> I don't know if that's better; just suggesting it as possibly tidier.
>
>   
>> +  /// This struct is just used as a wrapper so that we can overload the
>> +  /// << operator
>> +  template <typename ViewT>
>> +  struct Matlab_text_formatter
>> +  {
>> +    Matlab_text_formatter(ViewT v) : v_(v), view_name_("a")  {}
>> +    Matlab_text_formatter(ViewT v,std::string name) :
>> +      v_(v), view_name_(name)  {}
>> +
>> +    ViewT v_;
>> +    std::string view_name_;
>> +  };
>>     
>
> Another approach, is to add a "write" function to Matlab_text_formatter:
>
>   void
>   Matlab_text_formatter::write(ostream& os) {
>     // Whatever is currently in operator<<
>   }
>
>   inline void
>   std::ostream& operator<<(std::ostream& os, Matlab_text_formater mf) {
>     mf.write(os);
>     return os;
>   }
>
> This is somewhat more "object-oriented".  One advantage is that you then
> have a useful comment for Matlab_text_formatter:
>
>   // A Matlab_text_formatter writes the contents of a view to a stream,
>   // using the Matlab file format.
>
>   



From mark at codesourcery.com  Mon Jun  5 19:22:29 2006
From: mark at codesourcery.com (Mark Mitchell)
Date: Mon, 05 Jun 2006 12:22:29 -0700
Subject: [vsipl++] Matlab IO Patch
In-Reply-To: <44847F0F.40800@codesourcery.com>
References: <44847380.5020401@codesourcery.com> <4484774B.6050604@codesourcery.com> <44847F0F.40800@codesourcery.com>
Message-ID: <44848475.7060000@codesourcery.com>

Assem Salama wrote:
> The reason that I have the comment is because I was planning on reading
> the array name into view_name_. I didn't know how to do that at the time
> so I just read it into a temporary array and commented out the part that
> didn't work. By leaving the comment in there for now, I will not forget
> that I was planning on fixing that part.

We have an issue-tracker for that. :-)

It's bad if code gets shipped to a customer with FIXMEs or commented-out
code; that makes it look like we gave them code we didn't find
satisfactory.  If you don't have a VSIPL++ tracker account, Stefan will
be happy to help you get set up with that.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From jules at codesourcery.com  Mon Jun  5 21:50:28 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Mon, 05 Jun 2006 17:50:28 -0400
Subject: [patch] Fix for issue #117
Message-ID: <4484A724.8010207@codesourcery.com>

This patch fixes issue #117, C += a*X not being dispatched to SAL.

It also fixes a broken ifdef in coverage.hpp, and adds complex 
scalar-vector multiply benchmarks to vmul_sal.  (Neither change is 
related to issue #117).

Patch applied.

				-- Jules
-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix117.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060605/23731917/attachment.ksh>

From jules at codesourcery.com  Wed Jun  7 15:45:55 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Wed, 07 Jun 2006 11:45:55 -0400
Subject: [patch] Evaluate dense matrix/tensor expressions as vector expressions
Message-ID: <4486F4B3.6000006@codesourcery.com>

This patch evaluates expressions of dense matrices and tensors as if 
they were expressions of vectors.  This allows our existing dispatch 
machinary for SAL, IPP, etc (which primarily apply to vectors) to be 
used were applicable.

This patch has a positive performance impact on the CFAR u-benchmarks 
(email yesterday).  However, this patch does not include additional IPP 
dispatch (I need to clean that up further) that went into those graphs.

All tests pass for gcc-3.4, using IPP/MKL on cugel.  I'm very impressed 
with the coverage our test suite provides.  I've spent a half day fixing 
incomplete/broken bits in my patch that were identified by the suite.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: eval_dense_expr.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060607/63d178f5/attachment.ksh>

From don at codesourcery.com  Wed Jun  7 18:22:45 2006
From: don at codesourcery.com (Don McCoy)
Date: Wed, 07 Jun 2006 12:22:45 -0600
Subject: [patch] CFAR benchmark update
Message-ID: <44871975.4080307@codesourcery.com>

The attached patch enhances the CFAR benchmark by providing a second 
algorithm that processes the data by range vector instead of computing 
the values for a single range cell over all vectors.  Some other minor 
changes help increase the stability of the algorithm with respect to 
avoiding false hits and outright misses in terms of finding targets.

As the rework was extensive by the looks of the changes, the original 
algorithm did not change substantially (although the dimension ordering 
did change in the explicit declaration of the data cube, it can be 
adjusted easily in order to take advantage of recent dispatch 
additions).  For ease of review, I'm including a patched copy of the 
benchmark as well.

Regards,

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cf3.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060607/34f3aaf7/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cf3.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060607/34f3aaf7/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfar.cpp
Type: text/x-c++src
Size: 20983 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060607/34f3aaf7/attachment.cpp>

From assem at codesourcery.com  Wed Jun  7 21:07:43 2006
From: assem at codesourcery.com (Assem Salama)
Date: Wed, 07 Jun 2006 17:07:43 -0400
Subject: Matlab IO
Message-ID: <4487401F.1020406@codesourcery.com>

Everyone,
  This patch changes the names of mbf.v to mbf.view and mbf.view_name to 
mbf.name. Also changed unimplemented throws to errors.

Thanks,
Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06072006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060607/3366f851/attachment.ksh>

From don at codesourcery.com  Thu Jun  8 08:33:47 2006
From: don at codesourcery.com (Don McCoy)
Date: Thu, 08 Jun 2006 02:33:47 -0600
Subject: [patch] Firbank memory allocation
Message-ID: <4487E0EB.20802@codesourcery.com>

The attached patch corrects a memory allocation bug in the HPEC FIR 
Filter Bank benchmark.

Regards,

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fb3.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/b0d2d0f1/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fb3.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/b0d2d0f1/attachment-0001.ksh>

From jules at codesourcery.com  Thu Jun  8 17:50:58 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 08 Jun 2006 13:50:58 -0400
Subject: [vsipl++] [patch] CFAR benchmark update
In-Reply-To: <44871975.4080307@codesourcery.com>
References: <44871975.4080307@codesourcery.com>
Message-ID: <44886382.9070603@codesourcery.com>

Don McCoy wrote:
> The attached patch enhances the CFAR benchmark by providing a second 
> algorithm that processes the data by range vector instead of computing 
> the values for a single range cell over all vectors.  Some other minor 
> changes help increase the stability of the algorithm with respect to 
> avoiding false hits and outright misses in terms of finding targets.
> 
> As the rework was extensive by the looks of the changes, the original 
> algorithm did not change substantially (although the dimension ordering 
> did change in the explicit declaration of the data cube, it can be 
> adjusted easily in order to take advantage of recent dispatch 
> additions).  For ease of review, I'm including a patched copy of the 
> benchmark as well.
> 
> Regards,
> 
> 

Don,

This looks good.  Can you please check it in ASAP?  That will make it 
easier to merge in the SIMD changes.

				thanks,
				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From jules at codesourcery.com  Thu Jun  8 18:55:54 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 08 Jun 2006 14:55:54 -0400
Subject: [patch] Fix bug in how dimension-ordering is determined for Sliced_block.
Message-ID: <448872BA.3050507@codesourcery.com>

Patch applied.
-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: subblock.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/8ef611c5/attachment.ksh>

From jules at codesourcery.com  Thu Jun  8 21:47:28 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 08 Jun 2006 17:47:28 -0400
Subject: [patch] Minor CFAR changes
Message-ID: <44889AF0.2020201@codesourcery.com>

This patch makes some minor changes to CFAR.  For the slice version, it 
changes expressions to be more amenable to math library dispatch and 
changes the dimension-ordering to make subviews dense.  For the vector 
version, it fixes a bug with sum (should be reset to 0 for each vector), 
reduces the temporary footprint used, and uses get() instead of ().

Attached graphs show original (cfar-orig) and new (cfar) performance, 
for GCC 3.4 and GCC 4.1 on Pastec.  The changes for the slice version 
have a larger impact.  Using 4.1 is a win!

I am cleaning up the C, C-simd and VSIPL++ SIMD versions.  I'm planning 
to put the C and C-simd versions in a separate source file (cfar_c.cpp) 
and the VSIPL++ SIMD version in cfar.cpp (as t_cfar_hybrid).

I "fixed" gnuplot to avoid using both red and green, although the color 
choices still don't seem ideal.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfar-1.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/f58f6383/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfar-all-23.png
Type: image/png
Size: 4404 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/f58f6383/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfar-all-3.png
Type: image/png
Size: 4515 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/f58f6383/attachment-0001.png>

From don at codesourcery.com  Thu Jun  8 22:20:59 2006
From: don at codesourcery.com (Don McCoy)
Date: Thu, 08 Jun 2006 16:20:59 -0600
Subject: [vsipl++] [patch] Minor CFAR changes
In-Reply-To: <44889AF0.2020201@codesourcery.com>
References: <44889AF0.2020201@codesourcery.com>
Message-ID: <4488A2CB.4030609@codesourcery.com>

Jules Bergmann wrote:
> Attached graphs show original (cfar-orig) and new (cfar) performance, 
> for GCC 3.4 and GCC 4.1 on Pastec.  The changes for the slice version 
> have a larger impact.  Using 4.1 is a win!

Wow!  Those are some nice results.  Thanks for finding these issues and 
in general for helping me to better understand what was going on.  I 
think this was a very instructive example.

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712


From mark at codesourcery.com  Thu Jun  8 22:26:32 2006
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 08 Jun 2006 15:26:32 -0700
Subject: [vsipl++] [patch] Minor CFAR changes
In-Reply-To: <4488A2CB.4030609@codesourcery.com>
References: <44889AF0.2020201@codesourcery.com> <4488A2CB.4030609@codesourcery.com>
Message-ID: <4488A418.5010406@codesourcery.com>

Don McCoy wrote:
> Jules Bergmann wrote:
>> Attached graphs show original (cfar-orig) and new (cfar) performance,
>> for GCC 3.4 and GCC 4.1 on Pastec.  The changes for the slice version
>> have a larger impact.  Using 4.1 is a win!

What's Pastec?

It's nice to know GCC 4.1 is good for something!  But, from what you
said this morning, don't those results still fall short, relative to the
C code?

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From jules at codesourcery.com  Thu Jun  8 22:49:21 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 08 Jun 2006 18:49:21 -0400
Subject: [vsipl++] [patch] Minor CFAR changes
In-Reply-To: <4488A418.5010406@codesourcery.com>
References: <44889AF0.2020201@codesourcery.com> <4488A2CB.4030609@codesourcery.com> <4488A418.5010406@codesourcery.com>
Message-ID: <4488A971.6050709@codesourcery.com>

Mark Mitchell wrote:
> Don McCoy wrote:
>> Jules Bergmann wrote:
>>> Attached graphs show original (cfar-orig) and new (cfar) performance,
>>> for GCC 3.4 and GCC 4.1 on Pastec.  The changes for the slice version
>>> have a larger impact.  Using 4.1 is a win!
> 
> What's Pastec?

Pastec is another name for the GTRI cluster, aka durip (some acronym or 
such).

> 
> It's nice to know GCC 4.1 is good for something!  

Good job!

> But, from what you
> said this morning, don't those results still fall short, relative to the
> C code?

Yes, that's right.  I'm producing results for those cases now.  However, 
it looks like 4.1 boosted our "slice" version, while at the same time 
pessimizing the plain C "vector" version.

For a particular dataset size (dataset #3 at 200 gates):

	Variation		MFLOPS
	3.4 VSIPL++ slice	136
	3.4 VSIPL++ vector	 60
	3.4 C vector		141
	3.4 C+SIMD vector	470

	4.1 VSIPL++ slice 	226
	4.1 VSIPL++ vector	100
	4.1 C vector		128
	4.1 C+SIMD vector	830

(I need to repackage/rerun the VSIPL++ + SIMD approach.)

Question on SIMD:  For the C+SIMD version, I used the intrinsics from 
xmmintrin.h (__m128, _mm_add_ps(), etc).  This works with both 3.4 and 
4.1.  For the VSIPL++ SIMD version, I used the GCC vector extensions 
(typedef float v4sf __attribute++ ((vector_size(16))), '+' operator). 
The typedefs work with 3.4 and 4.1, but the operators (+, *, etc) only 
work with 4.1.  Is there any difference in code generated from these two 
approaches?  In particular, would it be worthwhile at all to recode the 
C+SIMD version to use the vector extensions?

				thanks,
				-- Jules


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From jules at codesourcery.com  Fri Jun  9 00:56:23 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 08 Jun 2006 20:56:23 -0400
Subject: [patch] C impl of CFAR, VSIPL++ SIMD impl
Message-ID: <4488C737.1040407@codesourcery.com>


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfar-2.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060608/08503258/attachment.ksh>

From mark at codesourcery.com  Fri Jun  9 17:02:07 2006
From: mark at codesourcery.com (Mark Mitchell)
Date: Fri, 09 Jun 2006 10:02:07 -0700
Subject: [vsipl++] [patch] Minor CFAR changes
In-Reply-To: <4488A971.6050709@codesourcery.com>
References: <44889AF0.2020201@codesourcery.com> <4488A2CB.4030609@codesourcery.com> <4488A418.5010406@codesourcery.com> <4488A971.6050709@codesourcery.com>
Message-ID: <4489A98F.6000805@codesourcery.com>

Jules Bergmann wrote:

> Question on SIMD:  For the C+SIMD version, I used the intrinsics from
> xmmintrin.h (__m128, _mm_add_ps(), etc).  This works with both 3.4 and
> 4.1.  For the VSIPL++ SIMD version, I used the GCC vector extensions
> (typedef float v4sf __attribute++ ((vector_size(16))), '+' operator).
> The typedefs work with 3.4 and 4.1, but the operators (+, *, etc) only
> work with 4.1.  Is there any difference in code generated from these two
> approaches? 

I would not think so.  However, if there *is* a difference, I would
expect the xmmintrin.h to be better; that's mapping directly to the
underlying instructions, with no compiler cleverness.

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From jules at codesourcery.com  Fri Jun  9 21:31:06 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Fri, 09 Jun 2006 17:31:06 -0400
Subject: [patch] Fixes to run CFAR benchmark in parallel.
Message-ID: <4489E89A.7060904@codesourcery.com>

Patch applied.
-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfar-3.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060609/b51de7e1/attachment.ksh>

From jules at codesourcery.com  Tue Jun 13 02:15:49 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Mon, 12 Jun 2006 22:15:49 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <4487401F.1020406@codesourcery.com>
References: <4487401F.1020406@codesourcery.com>
Message-ID: <448E1FD5.8040801@codesourcery.com>

Assem Salama wrote:
> Everyone,
>  This patch changes the names of mbf.v to mbf.view and mbf.view_name to 
> mbf.name. Also changed unimplemented throws to errors.

Assem,

In general, there are a lot of comparisons being done between signed and 
unsigned values below.  Can you recompile with the '-W -Wall' options, 
that will help catch these.  It is a good practice to use '-W -Wall' 
when developing.

I have a few more comments below, please take a look.  I think this is 
starting to converge.

I also have an action item for myself after reviewing this patch:
  - define a column-major next()

I'll post something for this shortly.

It would also be nice to do the following, but it is not critical.
  - move get_real_ptr/get_image_ptr functionality into Allocated_storage
  - move Subview_helper functionality into view class

I'll capture these as issues.

				-- Jules


> 
> Thanks,
> Assem
> 
> 
> ------------------------------------------------------------------------
> 
> ? .matlab.hpp.swp
> ? generic_reader.hpp
> ? matlab_temp
> ? png.cpp
> ? png.hpp
> Index: GNUmakefile.inc.in
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/src/vsip_csl/GNUmakefile.inc.in,v
> retrieving revision 1.1
> diff -u -r1.1 GNUmakefile.inc.in
> --- GNUmakefile.inc.in	8 May 2006 03:49:44 -0000	1.1
> +++ GNUmakefile.inc.in	7 Jun 2006 21:06:53 -0000
> @@ -12,13 +12,36 @@
>  # Variables
>  ########################################################################
>  
> +VSIP_CSL_HAVE_PNG	:= @HAVE_PNG_H@
> +
> +src_vsip_csl_CXXINCLUDES := -I$(srcdir)/src
> +src_vsip_csl_CXXFLAGS := $(src_vsip_csl_CXXINCLUDES)
> +
> +ifdef VSIP_CSL_HAVE_PNG
> +src_vsip_csl_cxx_sources += $(srcdir)/src/vsip_csl/png.cpp
> +endif

If you're not including png.cpp as part of your patch, why are you 
adding it to the makefile?

> +src_vsip_csl_cxx_objects := $(patsubst $(srcdir)/%.cpp, %.$(OBJEXT),\
> +                              $(src_vsip_csl_cxx_sources))
> +cxx_sources += $(src_vsip_csl_cxx_sources)
> +
> +libs += lib/libvsip_csl.a
>  
>  ########################################################################
>  # Rules
>  ########################################################################
>  
> +all:: lib/libvsip_csl.a
> +
> +clean::
> +	rm -f lib/libvsip_csl.a
> +
> +lib/libvsip_csl.a: $(src_vsip_csl_cxx_objects)
> +	$(AR) rc $@ $^ || rm -f $@
> +
>  # Install the extensions library and its header files.
>  install:: 
> +	$(INSTALL) -d $(DESTDIR)$(libdir)
> +	$(INSTALL_DATA) lib/libvsip_csl.a $(DESTDIR)$(libdir)/libvsip_csl$(suffix).a
>  	$(INSTALL) -d $(DESTDIR)$(includedir)/vsip_csl
>  	for header in $(wildcard $(srcdir)/src/vsip_csl/*.hpp); do \
>            $(INSTALL_DATA) $$header $(DESTDIR)$(includedir)/vsip_csl; \
> Index: matlab.hpp
> ===================================================================
> RCS file: matlab.hpp
> diff -N matlab.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab.hpp	7 Jun 2006 21:06:54 -0000
> @@ -0,0 +1,277 @@
> +#ifndef VSIP_CSL_MATLAB_HPP
> +#define VSIP_CSL_MATLAB_HPP
> +

What header are the types in32_t, etc getting defined in?

> +#include <iostream>
> +#include <vsip/impl/metaprogramming.hpp>
> +#include <vsip/impl/fns_elementwise.hpp>
> +#include <vsip/impl/length.hpp>
> +#include <vsip/impl/domain-utils.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +namespace matlab
> +{
> +  struct data_element
> +  {
> +    int32_t type;
> +    int32_t size;
> +  };
> +
> +  template <int Dim>
> +  struct view_header
> +  {
> +    data_element header;
> +    data_element array_flags_header;
> +    char array_flags[8];
> +    data_element dim_header;
> +    int32_t dim[Dim + Dim%2]; //the dim has to be aligned to an 8 byte boundary
> +    data_element array_name_header;
> +  };
> +
> +  // helper struct to get the imaginary part of a view.
> +  template <typename ViewT,
> +            bool IsComplex =
> +	      vsip::impl::Is_complex<typename ViewT::value_type>::value>
> +  struct Subview_helper;
> +
> +  template <typename ViewT>
> +  struct Subview_helper<ViewT,true>
> +  {
> +    typedef typename ViewT::realview_type realview_type;
> +    typedef typename ViewT::imagview_type imagview_type;
> +
> +    static realview_type real(ViewT v) { return v.real(); }
> +    static imagview_type imag(ViewT v) { return v.imag(); }
> +  };
> +
> +  template <typename ViewT>
> +  struct Subview_helper<ViewT,false>
> +  {
> +    typedef ViewT realview_type;
> +    typedef ViewT imagview_type;
> +
> +    static realview_type real(ViewT v) { return v; }
> +    static imagview_type imag(ViewT v) { return v; }
> +  };
> +
> +
> +  // generic reader that allows us to read a generic type and cast to another
> +  
> +  // the read function for real or complex depending of the view that was
> +  // passed in
> +  template <typename T1,
> +            typename T2,
> +	    typename ViewT>
> +  void read(std::istream& is,ViewT v)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    typedef typename vsip::impl::Scalar_of<T2>::type scalar_type;
> +    T1 data;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // read all the points
> +    for(int i=0;i<num_points;i++) {

'i' should be an index_type.  If you compile this with '-W -Wall', which 
you should be doing ;), GCC will catch this.

> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));

Is 'sizeof(data)' the correct size to read here?  Moreover, should 
'data' really be of type 'T1'?  If this is reading in part of a complex 
array, 'v' will be either the real or imag subview, which would make the 
correct type for 'data' to be 'scalar_type'.  That is how write() below 
appears to work.

If 'data' should be scalar_type, then instead of changing it here, it 
would be more natural to have 'operator>>' call read() with 
'Scalar_type<T1>::type' as a parameter.

> +      put(v,my_index,scalar_type(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }
> +
> +  // a write function to output a view to a matlab file.
> +  template <typename T,
> +	    typename ViewT>
> +  void write(std::ostream& os,ViewT v)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    typedef typename vsip::impl::Scalar_of<T>::type scalar_type;

Passing T as a template parameter, but than only using Scalar_of<T> 
seems unintuitive.   Let's perform the Scalar_of<T> at the caller of 
write().

> +    scalar_type data;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // write all the points
> +    for(int i=0;i<num_points;i++) {
> +      data = get(v,my_index);
> +      os.write(reinterpret_cast<char*>(&data),sizeof(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }
> +
> +  struct header
> +  {
> +    char description[116];
> +    char subsyt_data[8];
> +    char version[2];
> +    char endian[2];
> +  };
> +
> +  // constants for matlab binary format
> +
> +  // data types
> +  static int const miINT8           = 1;
> +  static int const miUINT8          = 2;
> +  static int const miINT16          = 3;
> +  static int const miUINT16         = 4;
> +  static int const miINT32          = 5;
> +  static int const miUINT32         = 6;
> +  static int const miSINGLE         = 7;
> +  static int const miDOUBLE         = 9;
> +  static int const miINT64          = 12;
> +  static int const miUINT64         = 13;
> +  static int const miMATRIX         = 14;
> +  static int const miCOMPRESSED     = 15;
> +  static int const miUTF8           = 16;
> +  static int const miUTF16          = 17;
> +  static int const miUTF32          = 18;
> +  
> +  // class types
> +  static int const mxCELL_CLASS     = 1;
> +  static int const mxSTRUCT_CLASS   = 2;
> +  static int const mxOBJECT_CLASS   = 3;
> +  static int const mxCHAR_CLASS     = 4;
> +  static int const mxSPARSE_CLASS   = 5;
> +  static int const mxDOUBLE_CLASS   = 6;
> +  static int const mxSINGLE_CLASS   = 7;
> +  static int const mxINT8_CLASS     = 8;
> +  static int const mxUINT8_CLASS    = 9;
> +  static int const mxINT16_CLASS    = 10;
> +  static int const mxUINT16_CLASS   = 11;
> +  static int const mxINT32_CLASS    = 12;
> +  static int const mxUINT32_CLASS   = 13;
> +
> +  // matlab header traits
> +  template <int size,bool is_signed,bool is_int>
> +  struct Matlab_header_traits;
> +
> +  template <>
> +  struct Matlab_header_traits<1, true, true> // char
> +  { 
> +    static int const value_type = miINT8;
> +    static int const class_type = mxINT8_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<1, false, true> // unsigned char
> +  { 
> +    static int const value_type = miUINT8;
> +    static int const class_type = mxUINT8_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<2, true, true> // short
> +  { 
> +    static int const value_type = miINT16;
> +    static int const class_type = mxINT16_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<2, false, true> // unsigned short
> +  { 
> +    static int const value_type = miUINT16;
> +    static int const class_type = mxUINT16_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, true, true> // int
> +  { 
> +    static int const value_type= miINT32;
> +    static int const class_type= mxINT32_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, false, true> // unsigned int
> +  { 
> +    static int const value_type= miUINT32;
> +    static int const class_type= mxUINT32_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, true, false> // float
> +  { 
> +    static int const value_type= miSINGLE;
> +    static int const class_type= mxSINGLE_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<8, true, false> // double
> +  { 
> +    static int const value_type= miDOUBLE;
> +    static int const class_type= mxDOUBLE_CLASS;
> +  };
> +

VSIPL++ has a template classes View_of_dim<> and Col_major<> that can 
help us out here.  Let's define Matlab_desired_LP as:

> +  // matlab desired layouts
> +  template <template <typename,typename> class View>
> +  struct Matlab_desired_LP
{
   static vsip::dimension_type const dim = vsip::Dim_of_view<View>::dim;
   typedef vsip::impl::Layout<
		dim,
		typename vsip::Col_major<dim>::type,
		vsip::impl::Stride_unit_dense,
		vsip::impl::Cmplx_split_fmt> type;
};


Which lets us get rid of all these specializations.


> +
> +  template<> struct Matlab_desired_LP<vsip::const_Vector>
> +  { typedef vsip::impl::Layout<1,vsip::col1_type,
> +                     vsip::impl::Stride_unit_dense,vsip::impl::Cmplx_split_fmt>
> +      type; 
> +  };
> +
> +  template<> struct Matlab_desired_LP<vsip::const_Matrix>
> +  { typedef vsip::impl::Layout<2,vsip::col2_type,
> +                     vsip::impl::Stride_unit_dense,vsip::impl::Cmplx_split_fmt>
> +      type; 
> +  };
> +  
> +  template<> struct Matlab_desired_LP<vsip::const_Tensor>
> +  { typedef vsip::impl::Layout<3,vsip::col3_type,
> +                     vsip::impl::Stride_unit_dense,vsip::impl::Cmplx_split_fmt>
> +      type; 
> +  };
> +
> +  template<> struct Matlab_desired_LP<vsip::Vector>
> +  { typedef vsip::impl::Layout<1,vsip::col1_type,
> +                     vsip::impl::Stride_unit_dense,vsip::impl::Cmplx_split_fmt>
> +      type; 
> +  };
> +
> +  template<> struct Matlab_desired_LP<vsip::Matrix>
> +  { typedef vsip::impl::Layout<2,vsip::col2_type,
> +                     vsip::impl::Stride_unit_dense,vsip::impl::Cmplx_split_fmt>
> +      type; 
> +  };
> +  
> +  template<> struct Matlab_desired_LP<vsip::Tensor>
> +  { typedef vsip::impl::Layout<3,vsip::col3_type,
> +                     vsip::impl::Stride_unit_dense,vsip::impl::Cmplx_split_fmt>
> +      type; 
> +  };
> +


> +  // helper function to return the real and imaginary part of a pointer

Let's put these function in 'Allocated_storage' instead, next to the 
definitions of std::pair<T*, T*>.  This will probably be useful in other 
contexts, and if we ever decide to change how we store split-complex, we 
don't explicit functions on std::pair<T*, T*> spread out in the library.

> +  
> +  template<typename T>
> +  inline T* get_real_ptr(std::pair<T*,T*> ptr)
> +    { return ptr.first; }
> +  template<typename T>
> +  inline T* get_real_ptr(T* ptr)
> +    { return ptr; }
> +
> +  template<typename T>
> +  inline T* get_imag_ptr(std::pair<T*,T*> ptr)
> +    { return ptr.second; }
> +  template<typename T>
> +  inline T* get_imag_ptr(T* ptr)
> +    { return ptr; }
> +
> +
> +
> +} // namesapce matlab
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_HPP
> Index: matlab_bin_formatter.hpp
> ===================================================================
> RCS file: matlab_bin_formatter.hpp
> diff -N matlab_bin_formatter.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab_bin_formatter.hpp	7 Jun 2006 21:06:54 -0000
> @@ -0,0 +1,366 @@
> +/* Copyright (c) 2005, 2006 by CodeSourcery.  All rights reserved. */
> +
> +/** @file    vsip_csl/matlab_bin_formatter.hpp
> +    @author  Assem Salama
> +    @date    2006-05-22
> +    @brief   VSIPL++ CodeSourcery Library: Matlab binary formatter
> +*/
> +
> +#ifndef VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> +#define VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> +
> +#include <stdint.h>
> +#include <string>
> +#include <limits>
> +#include <vsip_csl/matlab.hpp>
> +#include <vsip/impl/fns_scalar.hpp>
> +#include <vsip/impl/fns_elementwise.hpp>
> +#include <vsip/impl/metaprogramming.hpp>
> +#include <vsip/impl/view_traits.hpp>
> +#include <vsip/impl/extdata.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +  template <typename ViewT>
> +  struct Matlab_bin_formatter
> +  {
> +    Matlab_bin_formatter(ViewT v,std::string const& name) :
> +      view(v), name(name)  {}
> +
> +    ViewT view;
> +    std::string name;
> +
> +  };
> +
> +  struct Matlab_bin_hdr
> +  {
> +    Matlab_bin_hdr(std::string const& descr, std::string const& end) : 
> +      description(descr),version("MATLAB 5.0 : "),endian(end) {}
> +    Matlab_bin_hdr(std::string const& descr) : 
> +      description(descr),version("MATLAB 5.0 : "),endian("MI") {}
> +    Matlab_bin_hdr() : 
> +      description(" "),version("MATLAB 5.0 : "),endian("MI") {}
> +
> +    // description
> +    std::string version;
> +    std::string description;
> +    std::string endian;
> +
> +  };
> +} // namespace vsip_csl
> +
> +/****************************************************************************
> + * Definitions
> + ***************************************************************************/
> +
> +namespace vsip_csl
> +{
> +
> +// operator to write matlab header
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&           o,
> +  Matlab_bin_hdr const&   h)
> +{
> +  matlab::header m_hdr;
> +
> +  // set hdr to spaces
> +  memset(&(m_hdr),' ',sizeof(m_hdr));
> +  strncpy(m_hdr.description, h.version.data(), h.version.length());
> +  strncpy(m_hdr.description+h.version.length(), h.description.data(),
> +    h.description.length());
> +  m_hdr.version[1] = 0x01; m_hdr.version[0] = 0x00;
> +  m_hdr.endian[0]=h.endian[0];
> +  m_hdr.endian[1]=h.endian[1];
> +
> +  // write header
> +  o.write(reinterpret_cast<char*>(&m_hdr),sizeof(m_hdr));
> +
> +  return o;
> +}
> +// operator to write a view to a matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class const_View>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&                                       o,
> +  Matlab_bin_formatter<const_View<T,Block0> > const&  mbf)
> +{
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  matlab::data_element temp_data_element;
> +  int    sz;

The way 'sz' is being used below, it should be of type 'size_t'.  For 
example, sizeof() returns a size_t, and it is being used with other 
unsigned types.

> +  matlab::view_header<vsip::impl::Dim_of_view<const_View>::dim > m_view;
> +  int    num_points = 1;

should be length_type

> +  int    v_dims = vsip::impl::Dim_of_view<const_View>::dim;

should be dimension_type

> +
> +  memset(&m_view,0,sizeof(m_view));
> +
> +  // matrix data type
> +  m_view.header.type = matlab::miMATRIX;
> +  m_view.header.size = 1; // TEMP
> +
> +  // array flags
> +  m_view.array_flags_header.type = matlab::miUINT32;
> +  m_view.array_flags_header.size = 8;
> +  if(vsip::impl::Is_complex<T>::value) 
> +    m_view.array_flags[1] |= 0x8; // Complex
> +
> +  // fill in class
> +  m_view.array_flags[0] = 
> +    matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type;
> +
> +  // make sure we found a matching trait
> +  assert(m_view.array_flags[0] != 0);
> +  
> +  // dimension sizes
> +  m_view.dim_header.type = matlab::miINT32;
> +  m_view.dim_header.size = v_dims*4; // 4 bytes per dimension
> +  // fill in dimension
> +  for(int i =0;i<v_dims;i++)
> +  {
> +    m_view.dim[i] = mbf.view.size(i);
> +    num_points *= mbf.view.size(i);
> +  }
> +
> +  // if this view is a vector, we need to make second dimension a one
> +  if(v_dims == 1)
> +  {
> +    m_view.dim_header.size += 4;
> +    m_view.dim[1] = 1;
> +  }
> +
> +  // array name
> +  m_view.array_name_header.type = matlab::miINT8;
> +  m_view.array_name_header.size = mbf.name.length();
> +
> +
> +  // calculate size
> +  sz = sizeof(m_view)-8;
> +  sz += mbf.name.length();
> +  sz += (8-mbf.name.length())&0x7;
> +  sz += 8; // 8 bytes of header for real data
> +  if(vsip::impl::Is_complex<T>::value) sz += 8; // 8 more for complex data
> +  sz += num_points*sizeof(T);
> +  m_view.header.size = sz;

Since m_view.header.size is an 'int32_t', use a cast here:

m_view.header.size = static_cast<int32_t>(sz);

> +
> +  o.write(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // write array name
> +  o.write(mbf.name.c_str(),mbf.name.length());
> +  // pad
> +  { 
> +    char c=0;
> +    for(int i=0;i < ((8-mbf.name.length())&0x7);i++) o.write(&c,1);
> +  }
> +
> +  // write data
> +  {
> +  
> +    // make sure we don't need a copy if we use Ext data
> +    if(vsip::impl::Ext_data_cost<Block0,
> +      typename matlab::Matlab_desired_LP<const_View>::type >::value==0)
> +    {
> +      vsip::impl::Ext_data<Block0,
> +	                 typename matlab::Matlab_desired_LP<const_View>::type >
> +	     
> +	       m_ext(mbf.view.block());
> +
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) o.write(reinterpret_cast<char*>
> +             (matlab::get_real_ptr<scalar_type>(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +        else o.write(reinterpret_cast<char*>
> +             (matlab::get_imag_ptr<scalar_type>(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +      }
> +    }
> +    else
> +    {
> +      typedef matlab::Subview_helper<const_View<T,Block0> > subview;
> +      typedef typename subview::realview_type r_v;
> +      typedef typename subview::imagview_type i_v;
> +
> +      // conventional way
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) matlab::write<T,r_v>(o,subview::real(mbf.view));

Since subview::real(mbf.view) has value type Scalar_of<SomeType>::type, 
it would be cleaner to pass Scalar_of<T>::type instead of T.

> +        else     matlab::write<T,i_v>(o,subview::imag(mbf.view));
> +      }
> +    }
> +  }
> +
> +  return o;
> +}
> +
> +// operator to read matlab header
> +inline
> +std::istream&
> +operator>>(
> +  std::istream&           o,
> +  Matlab_bin_hdr          h)
> +{
> +  matlab::header m_hdr;
> +
> +  // read header
> +  o.read(reinterpret_cast<char*>(&m_hdr),sizeof(m_hdr));
> +
> +  h.version[1] = m_hdr.version[1];
> +  h.version[0] = m_hdr.version[0];
> +  h.endian[1] = m_hdr.endian[1];
> +  h.endian[0] = m_hdr.endian[0];
> +
> +  return o;
> +}
> +
> +// operator to read view from matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class View>
> +inline
> +std::istream&
> +operator>>(
> +  std::istream&                                       is,
> +  Matlab_bin_formatter<View<T,Block0> >               mbf)
> +{
> +  matlab::data_element temp_data_element;
> +  matlab::view_header<vsip::impl::Dim_of_view<View>::dim> m_view;
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  typedef matlab::Subview_helper<View<T,Block0> > subview;
> +  typedef typename subview::realview_type r_v;
> +  typedef typename subview::imagview_type i_v;
> +  int v_dim = vsip::impl::Dim_of_view<View>::dim;
> +
> +
> +  // read header
> +  is.read(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // is this complex?
> +  if(vsip::impl::Is_complex<T>::value && !(m_view.array_flags[1]&0x8))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read complex matrix into a real matrix"));
> +
> +
> +  // is this the same class?
> +  if(!(m_view.array_flags[0] == 
> +            (matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type)))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read a matrix of a different class"));
> +
> +  // do dimensions agree?
> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for vectors
> +  if(v_dim != (m_view.dim_header.size/4))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read a matrix of different dimensions"));
> +
> +  for(int i=0;i<v_dim;i++)
> +    if(mbf.view.size(i) != m_view.dim[i])
> +      VSIP_IMPL_THROW(std::runtime_error(
> +        "Matrix dimensions don't agree"));
> +
> +  // read array name
> +  if(m_view.array_name_header.type & 0xffff0000)
> +  {
> +    // array name is short
> +
> +    int length = m_view.array_name_header.type >> 16;
> +  }
> +  else
> +  {
> +    int length = m_view.array_name_header.size;
> +    char c;
> +    char c_array[128];
> +    // the name is longer than 4 bytes
> +    //
> +    if(length > 128)
> +      VSIP_IMPL_THROW(std::runtime_error(
> +        "Name of matrix is too large"));
> +
> +    is.read(c_array,length);
> +    c_array[length] = 0;
> +    // read padding
> +    for(int i=0;i<((8-length)&0x7);i++) is.read(&c,1);
> +  }
> +
> +  // read data, we will go in this loop twice if we have complex data
> +  for (int i=0;i <= vsip::impl::Is_complex<T>::value;i++)
> +  {
> +
> +    // read data header
> +    is.read(reinterpret_cast<char*>(&temp_data_element),
> +            sizeof(temp_data_element));
> +
> +    // Because we don't know how the data was stored, we need to instantiate
> +    // generic_reader which can read a type and cast into a different one
> +    if(temp_data_element.type == matlab::miINT8) 
> +    {
> +      if(i==0)matlab::read<int8_t,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<int8_t,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else if(temp_data_element.type == matlab::miUINT8) 
> +    {
> +      if(i==0)matlab::read<uint8_t,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<uint8_t,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else if(temp_data_element.type == matlab::miINT16) 
> +    {
> +      if(i==0)matlab::read<int16_t,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<int16_t,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else if(temp_data_element.type == matlab::miUINT16) 
> +    {
> +      if(i==0)matlab::read<uint16_t,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<uint16_t,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else if(temp_data_element.type == matlab::miINT32) 
> +    {
> +      if(i==0)matlab::read<int32_t,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<int32_t,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else if(temp_data_element.type == matlab::miUINT32) 
> +    {
> +      if(i==0)matlab::read<uint32_t,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<uint32_t,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else if(temp_data_element.type == matlab::miSINGLE) 
> +    {
> +      if(i==0)matlab::read<float,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<float,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +    else
> +    {
> +      if(i==0)matlab::read<double,T,r_v>(is,subview::real(mbf.view));
> +      else    matlab::read<double,T,i_v>(is,subview::imag(mbf.view));
> +    }
> +
> +  }
> +
> +}
> +
> +
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> Index: matlab_text_formatter.hpp
> ===================================================================
> RCS file: matlab_text_formatter.hpp

Text formatter looks good.

> Index: output.hpp
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/src/vsip_csl/output.hpp,v
> retrieving revision 1.1

The version of this file in CVS is 1.2, it looks like it has already 
been patched.




-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From jules at codesourcery.com  Tue Jun 13 03:23:05 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Mon, 12 Jun 2006 23:23:05 -0400
Subject: [patch] Update next() to take dimension-order
Message-ID: <448E2F99.6000000@codesourcery.com>

This patch adds a dimension-order template parameter to the next() index 
traversal functions.  It also adds an overload that defaults to 
row-major so that current users of the function will continue to work.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: next.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060612/77f66fb2/attachment.ksh>

From assem at codesourcery.com  Tue Jun 13 18:28:44 2006
From: assem at codesourcery.com (Assem Salama)
Date: Tue, 13 Jun 2006 14:28:44 -0400
Subject: Atlas patch
Message-ID: <448F03DC.7040407@codesourcery.com>

Everyone,
  This patch adds support for a simple blas that doesn't require ATLAS.

Thanks,
Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06132006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060613/af609f78/attachment.ksh>

From stefan at codesourcery.com  Tue Jun 13 18:44:09 2006
From: stefan at codesourcery.com (Stefan Seefeld)
Date: Tue, 13 Jun 2006 14:44:09 -0400
Subject: [vsipl++] Atlas patch
In-Reply-To: <448F03DC.7040407@codesourcery.com>
References: <448F03DC.7040407@codesourcery.com>
Message-ID: <448F0779.9080208@codesourcery.com>

Assem,


Assem Salama wrote:

>  $(vendor_LIBF77):
>  	@echo "Building libF77 (see libF77.build.log)"
>  	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 all > libF77.build.log 2>&1
> -	@ln -s `pwd`/vendor/clapack/F2CLIBS/libF77/libF77.a vendor/atlas/lib/libF77.a

I notice you have taken out this and a couple of other link generations. What's the rationale
for that ?


>  
>  
>  install:: $(vendor_LIBF77)
> @@ -106,7 +107,6 @@
>  	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > libF77.clean.log 2>&1
>  endif
>  
> -
>  clean::
>  	@echo "Cleaning ATLAS (see atlas.clean.log)"
>  	@$(MAKE) -C vendor/atlas clean > atlas.clean.log 2>&1
> @@ -125,6 +125,58 @@
>  endif # USE_FORTRAN_LAPACK
>  
>  endif # USE_BUILTIN_ATLAS
> +################################################################################
> +
> +ifdef USE_SIMPLE_LAPACK
> +all:: $(vendor_SIMPLE_BLAS) $(vendor_REF_LAPACK)
> +
> +libs += $(vendor_F77BLAS) $(vendor_REF_LAPACK)
> +
> +$(vendor_SIMPLE_BLAS):
> +	@echo "Building simple BLAS (see simpleBLAS.build.log)"
> +	@$(MAKE) -C vendor/clapack/blas/SRC all > simpleBLAS.build.log 2>&1
> +
> +ifdef USE_FORTRAN_LAPACK

Could you summarize / document the build logic a bit ? This last line
actually happens inside the 'ifdef USE_SIMPLE_LAPACK' conditional, so
the following targets are only defined if both variables (USE_SIMPLE_LAPACK as well
as USE_FORTRAN_LAPACK) are defined. Is that intended ?

> @@ -166,7 +218,7 @@
>  all:: $(vendor_FFTW_LIBS)
>  	@rm -rf vendor/fftw/include
>  	@mkdir -p vendor/fftw/include
> -	@ln -s $(abs_srcdir)/vendor/fftw/api/fftw3.h vendor/fftw/include/fftw3.h
> +	@ln -s $(srcdir)/vendor/fftw/api/fftw3.h vendor/fftw/include/fftw3.h

What's the rationale for this change ? I remember first using $(srcdir) which resulted in
incorrect links, as the target becomes a relative path, so the validity depends on the cwd when
dereferencing the link. Thus I replaced $(srcdir) by $(abs_srcdir) to make it work.

Thanks,
		Stefan


-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718


From assem at codesourcery.com  Tue Jun 13 18:49:23 2006
From: assem at codesourcery.com (Assem Salama)
Date: Tue, 13 Jun 2006 14:49:23 -0400
Subject: [vsipl++] Atlas patch
In-Reply-To: <448F0779.9080208@codesourcery.com>
References: <448F03DC.7040407@codesourcery.com> <448F0779.9080208@codesourcery.com>
Message-ID: <448F08B3.8040906@codesourcery.com>

Stefan Seefeld wrote:
> Assem,
>
>
> Assem Salama wrote:
>
>   
>>  $(vendor_LIBF77):
>>  	@echo "Building libF77 (see libF77.build.log)"
>>  	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 all > libF77.build.log 2>&1
>> -	@ln -s `pwd`/vendor/clapack/F2CLIBS/libF77/libF77.a vendor/atlas/lib/libF77.a
>>     
>
> I notice you have taken out this and a couple of other link generations. What's the rationale
> for that ?
>   
When I tried to do a make, this link produced an error because there 
already was a lib in vendor/clapack/F2CLIBS/libF77/libF77.a
>
>   
>>  
>>  
>>  install:: $(vendor_LIBF77)
>> @@ -106,7 +107,6 @@
>>  	@$(MAKE) -C vendor/clapack/F2CLIBS/libF77 clean > libF77.clean.log 2>&1
>>  endif
>>  
>> -
>>  clean::
>>  	@echo "Cleaning ATLAS (see atlas.clean.log)"
>>  	@$(MAKE) -C vendor/atlas clean > atlas.clean.log 2>&1
>> @@ -125,6 +125,58 @@
>>  endif # USE_FORTRAN_LAPACK
>>  
>>  endif # USE_BUILTIN_ATLAS
>> +################################################################################
>> +
>> +ifdef USE_SIMPLE_LAPACK
>> +all:: $(vendor_SIMPLE_BLAS) $(vendor_REF_LAPACK)
>> +
>> +libs += $(vendor_F77BLAS) $(vendor_REF_LAPACK)
>> +
>> +$(vendor_SIMPLE_BLAS):
>> +	@echo "Building simple BLAS (see simpleBLAS.build.log)"
>> +	@$(MAKE) -C vendor/clapack/blas/SRC all > simpleBLAS.build.log 2>&1
>> +
>> +ifdef USE_FORTRAN_LAPACK
>>     
>
> Could you summarize / document the build logic a bit ? This last line
> actually happens inside the 'ifdef USE_SIMPLE_LAPACK' conditional, so
> the following targets are only defined if both variables (USE_SIMPLE_LAPACK as well
> as USE_FORTRAN_LAPACK) are defined. Is that intended ?
>   
I think you are correct, this is redundant because FORTRAN_LAPACK should 
never be defined with SIMPLE_LAPACK.
>   
>> @@ -166,7 +218,7 @@
>>  all:: $(vendor_FFTW_LIBS)
>>  	@rm -rf vendor/fftw/include
>>  	@mkdir -p vendor/fftw/include
>> -	@ln -s $(abs_srcdir)/vendor/fftw/api/fftw3.h vendor/fftw/include/fftw3.h
>> +	@ln -s $(srcdir)/vendor/fftw/api/fftw3.h vendor/fftw/include/fftw3.h
>>     
>
> What's the rationale for this change ? I remember first using $(srcdir) which resulted in
> incorrect links, as the target becomes a relative path, so the validity depends on the cwd when
> dereferencing the link. Thus I replaced $(srcdir) by $(abs_srcdir) to make it work.
>
> Thanks,
> 		Stefan
>
>
>   
This is a mistake, I should change it back to abs_srcdir. My srcdir is 
absolute so it didn't give me problems but I will change this back to 
abs_srcdir.



From stefan at codesourcery.com  Tue Jun 13 18:58:16 2006
From: stefan at codesourcery.com (Stefan Seefeld)
Date: Tue, 13 Jun 2006 14:58:16 -0400
Subject: [vsipl++] Atlas patch
In-Reply-To: <448F08B3.8040906@codesourcery.com>
References: <448F03DC.7040407@codesourcery.com> <448F0779.9080208@codesourcery.com> <448F08B3.8040906@codesourcery.com>
Message-ID: <448F0AC8.6050602@codesourcery.com>

Assem Salama wrote:

>> I notice you have taken out this and a couple of other link
>> generations. What's the rationale
>> for that ?
>>   
> When I tried to do a make, this link produced an error because there
> already was a lib in vendor/clapack/F2CLIBS/libF77/libF77.a

Sounds like a bug. I should check whether that file already exists,
before creating it (or alternatively first removing it).
But just removing the link generation surely doesn't solve that bug. :-)

>> Could you summarize / document the build logic a bit ? This last line
>> actually happens inside the 'ifdef USE_SIMPLE_LAPACK' conditional, so
>> the following targets are only defined if both variables
>> (USE_SIMPLE_LAPACK as well
>> as USE_FORTRAN_LAPACK) are defined. Is that intended ?
>>   
> I think you are correct, this is redundant because FORTRAN_LAPACK should
> never be defined with SIMPLE_LAPACK.

But can it not be defined (used) without SIMPLE_LAPACK ?

Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718


From jules at codesourcery.com  Tue Jun 13 20:59:11 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Tue, 13 Jun 2006 16:59:11 -0400
Subject: [vsipl++] Atlas patch
In-Reply-To: <448F0AC8.6050602@codesourcery.com>
References: <448F03DC.7040407@codesourcery.com> <448F0779.9080208@codesourcery.com> <448F08B3.8040906@codesourcery.com> <448F0AC8.6050602@codesourcery.com>
Message-ID: <448F271F.20407@codesourcery.com>

Stefan Seefeld wrote:
> Assem Salama wrote:
> 
>>> I notice you have taken out this and a couple of other link
>>> generations. What's the rationale
>>> for that ?
>>>   
>> When I tried to do a make, this link produced an error because there
>> already was a lib in vendor/clapack/F2CLIBS/libF77/libF77.a
> 
> Sounds like a bug. I should check whether that file already exists,
> before creating it (or alternatively first removing it).
> But just removing the link generation surely doesn't solve that bug. :-)
> 
>>> Could you summarize / document the build logic a bit ? This last line
>>> actually happens inside the 'ifdef USE_SIMPLE_LAPACK' conditional, so
>>> the following targets are only defined if both variables
>>> (USE_SIMPLE_LAPACK as well
>>> as USE_FORTRAN_LAPACK) are defined. Is that intended ?
>>>   
>> I think you are correct, this is redundant because FORTRAN_LAPACK should
>> never be defined with SIMPLE_LAPACK.
> 
> But can it not be defined (used) without SIMPLE_LAPACK ?
> 
> Thanks,
> 		Stefan
> 

Roughly, we have three configurations for builtin lapack:

  --with-lapack=builtin
    => build ATLAS (provides full CBLAS, partial LAPACK)
    => build ref CLAPACK (provides remainder of LAPACK)
    => build libF77 (provides fortran bits for CLAPACK)

  --with-lapack=fortran-builtin
    => build ATLAS (provides full CBLAS, partial LAPACK)
    => build ref LAPACK (provides remainder of LAPACK)
    (libg2c is required for this approach)

  --with-lapack=simple-builtin
    => build ref CLAPACK/BLAS (provides full BLAS)
    => build ref CLAPACK (provides full LAPACK)
    => build libF77



To avoid duplicating rules in vendor/GNUmakefile.inc.in, let's change 
the logic to be more explicit:

ifdef BUILD_REF_LAPACK
    ... rules to build vendor/lapack/SRC
endif

ifdef BUILD_REF_CLAPACK
    ... rules to build vendor/clapack/SRC
endif

ifdef BUILD_REF_CLAPACK_BLAS
    ... rules to bild vendor/clapack/BLAS/SRC
endif

ifdef BUILD_ATLAS
    rules for vendor/atlas

    if BUILD_REF_LAPACK
       rule to install ATLAS libf77
    endif
endif


ifdef BUILD_LIBF77
    rules to build vendor/clapack/F2CLIBS/libF77
endif


ifdef USE_ATLAS_LAPACK
    rules to merge lapack (either Fortran or C) with atlas
          to generate final lapack
endif

ifdef USE_SIMPLE_LAPACK
    rules to install vendor/clapack/SRC and
                     vendor/clapack/BLAS/SRC
endif




Inside of configure, our options would map to Makefile variables as follows:

  --with-lapack=builtin
     BUILD_ATLAS            = 1
     BUILD_REF_LAPACK       = 0
     BUILD_REF_CLAPACK      = 1
     BUILD_REF_CLAPACK_BLAS = 0
     BUILD_LIBF77           = 1
     USE_ATLAS_LAPACK       = 1
     USE_SIMPLE_LAPACK      = 0

  --with-lapack=fortran-builtin
     BUILD_ATLAS            = 1
     BUILD_REF_LAPACK       = 1
     BUILD_REF_CLAPACK      = 0
     BUILD_REF_CLAPACK_BLAS = 0
     BUILD_LIBF77           = 0
     USE_ATLAS_LAPACK       = 1
     USE_SIMPLE_LAPACK      = 0

  --with-lapack=simple-builtin
     BUILD_ATLAS            = 0
     BUILD_REF_LAPACK       = 0
     BUILD_REF_CLAPACK      = 1
     BUILD_REF_CLAPACK_BLAS = 1
     BUILD_LIBF77           = 1
     USE_ATLAS_LAPACK       = 0
     USE_SIMPLE_LAPACK      = 1

How does this sound?

				-- Jules
-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From stefan at codesourcery.com  Tue Jun 13 21:08:36 2006
From: stefan at codesourcery.com (Stefan Seefeld)
Date: Tue, 13 Jun 2006 17:08:36 -0400
Subject: [vsipl++] Atlas patch
In-Reply-To: <448F271F.20407@codesourcery.com>
References: <448F03DC.7040407@codesourcery.com> <448F0779.9080208@codesourcery.com> <448F08B3.8040906@codesourcery.com> <448F0AC8.6050602@codesourcery.com> <448F271F.20407@codesourcery.com>
Message-ID: <448F2954.8030807@codesourcery.com>

Jules Bergmann wrote:

> Roughly, we have three configurations for builtin lapack:

[...]

> How does this sound?

Excellent !
Thanks for putting this together !

		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718


From stefan at codesourcery.com  Wed Jun 14 15:21:29 2006
From: stefan at codesourcery.com (Stefan Seefeld)
Date: Wed, 14 Jun 2006 11:21:29 -0400
Subject: patch: Fix function return type for functions returning string literals.
Message-ID: <44902979.60909@codesourcery.com>

The attached patch fixes the return type for some functions
returning string literals. The patch is checked in.

Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060614/0155feba/attachment.ksh>

From don at codesourcery.com  Thu Jun 15 09:17:03 2006
From: don at codesourcery.com (Don McCoy)
Date: Thu, 15 Jun 2006 03:17:03 -0600
Subject: CFAR Benchmark cleanup
Message-ID: <4491258F.3030502@codesourcery.com>

The attached patch reorganizes the CFAR benchmark.  It now resembles the 
FIR Bank benchmark in that it has more than one algorithm for processing 
the data sets.  They now both use a similar structure.

There are enough changes to make a fairly complex diff, so I'm also 
including the source file which should be somewhat easier to read and 
review.

Regards,

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cf4.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060615/507dc605/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cf4.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060615/507dc605/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfar.cpp
Type: text/x-c++src
Size: 26126 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060615/507dc605/attachment.cpp>

From jules at codesourcery.com  Fri Jun 16 02:39:43 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 15 Jun 2006 22:39:43 -0400
Subject: [patch] Fix SAL synthetic complex scalar-vector multiply
Message-ID: <449219EF.3030705@codesourcery.com>

Oops!  I must have been thinking Python :)

This bug was showing up as incorrect scalaring for 2D FFT in fft.cpp. 
To make regressions easier to spot in the future, I extended the 
coverage_binary test to catch this as well.

Patch applied.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060615/8a291edb/attachment.ksh>

From jules at codesourcery.com  Fri Jun 16 03:12:46 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Thu, 15 Jun 2006 23:12:46 -0400
Subject: [vsipl++] CFAR Benchmark cleanup
In-Reply-To: <4491258F.3030502@codesourcery.com>
References: <4491258F.3030502@codesourcery.com>
Message-ID: <449221AE.8090205@codesourcery.com>

Don McCoy wrote:
> The attached patch reorganizes the CFAR benchmark.  It now resembles the 
> FIR Bank benchmark in that it has more than one algorithm for processing 
> the data sets.  They now both use a similar structure.
> 
> There are enough changes to make a fairly complex diff, so I'm also 
> including the source file which should be somewhat easier to read and 
> review.
> 

Don,

This looks good.  I have one comment below, the temporary 'strip' in 
ImplHybrid should be created outside of cfar_detect.  Once that is 
fixed, please check it in.

				thanks,
				-- Jules

> 
> template <typename T>
> struct t_cfar_base<T, ImplHybrid>
> {
>   char* what() { return "t_cfar_sweep_range<T, ImplHybrid>"; }
> 
>   template <typename Block>
>   void
>   cfar_detect(
>     Tensor<T, Block>    cube,
>     Tensor<T, Block> /* cpow */,
>     Matrix<Index<2> >   located,
>     Vector<length_type> count)
>   {
>     length_type const c = cfar_gates_;
>     length_type const g = guard_cells_;
>     length_type const beams = cube.size(0);
>     length_type const dbins = cube.size(1);
>     length_type const gates = cube.size(2);
> 
>     // Clear counts for targets found per gate.
>     count = 0;
> 
>     Vector<v4sf> strip(gates);

Oops, I left a surprise for you here!

'strip' should be allocated outside of cfar_detect, similar to cpow.

Unfortunately, passing an additional parameter breaks the interface 
consistency with ImplSlice and ImplVector.


Here's an idea:

In t_cfar_base, create a typedef for the temporary view (cpow for 
ImplSlice and ImplVector, slice for ImplHybrid), and a function to 
initialize it.  operator() can use these to create the right temporary.

I.e. for t_cfar_base<T, ImplHybrid> you might have:

   typedef Vector<v4sf> temp_view;

   temp_view create_temp_view(length_type /*beams*/,
                              length_type /*dbins*/,
                              length_type gates)
   {
     return temp_view(gates);
   }





> 
>   void operator()(length_type size, length_type loop, float& time)
>   {
>     length_type beams = this->beams_;
>     length_type dbins = this->dbins_;
>     length_type gates = size;
> 
>     // The number of range gates must be sufficiently greater than the sum
>     // of CFAR gates and guard cells.  If not, the radar signal processing 
>     // parameters are flawed!
>     test_assert( 2 * (this->cfar_gates_ + this->guard_cells_) < gates );
>     
>     // Create a "root" view for initialization.  Only the first processor
>     // will access the data.
>     root_view_type root(beams, dbins, gates);
>     initialize_cube(root);
> 
>     // Create a (possibly distributed) view for computation.  Also create a 
>     // temporary cube with an identical map to hold squared values.
> #if PARALLEL_CFAR
>     typedef Map<Block_dist, Block_dist, Whole_dist>  map_type;
>     typedef Dense<3, T, OrderT, map_type>            block_type;
>     typedef Tensor<T, block_type>                    view_type;
>     typedef typename view_type::local_type           local_type;
> 
>     processor_type np = num_processors();
>     map_type map = map_type(Block_dist(np), Block_dist(1), Whole_dist());
> 
>     view_type dist_cube(beams, dbins, gates, map);
>     view_type dist_cpow(beams, dbins, gates, map);

'temp' replaces cpow:

	t_cfar_base<...>::temp_view temp(
	   t_cfar_base<...>::create_temp_view(beams, dbins, gates));
> 
>     dist_cube = root;
> 
>     local_type cube = dist_cube.local();
>     local_type cpow = dist_cpow.local();
> #else
>     typedef Dense<3, T, OrderT>     block_type;
>     typedef Tensor<T, block_type>   view_type;
>     typedef view_type local_type;
> 
>     view_type& cube = root;
>     view_type cpow(beams, dbins, gates);
> #endif
> 
> 
>     // Create a place to store the locations of targets that are found
>     Matrix<Index<2> > located(gates, this->ntargets_, Index<2>());
>     Vector<length_type> count(gates);
>     
>     // Process the data cube and time it
>     vsip::impl::profile::Timer t1;
>     t1.start();
>     for (index_type l=0; l<loop; ++l)
>     {
>       cfar_detect(cube, cpow, located, count);

	cfar_detect(cube, temp, located, count);

>     }
>     t1.stop();
>     time = t1.delta();
> 
>     // Verify targets detected
>     cfar_verify(cube, located, count);
>   }
> 
> 
>   t_cfar_sweep_range(length_type beams, length_type bins,
>                  length_type cfar_gates, length_type guard_cells)
>    : t_cfar_base<T, ImplTag>(beams, bins, cfar_gates, guard_cells)
>   {}
> };
> 
> 


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From assem at codesourcery.com  Fri Jun 16 09:38:47 2006
From: assem at codesourcery.com (Assem Salama)
Date: Fri, 16 Jun 2006 05:38:47 -0400
Subject: Matlab IO
Message-ID: <44927C27.5080109@codesourcery.com>

Everyone,
  This is the Matlab IO patch with Jule's suggestions. I will be working 
on the new iterator stuff as soon as I get an ok to check this patch in.

Thanks,
Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06162006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/e46cc474/attachment.ksh>

From assem at codesourcery.com  Fri Jun 16 10:21:41 2006
From: assem at codesourcery.com (Assem Salama)
Date: Fri, 16 Jun 2006 06:21:41 -0400
Subject: Matlab IO
Message-ID: <44928635.8080304@codesourcery.com>

Everyone,
  I apologize about last e-mail, I forgot to include layout.hpp in the 
patch.

Thanks,
Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06162006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/4b249690/attachment.ksh>

From jules at codesourcery.com  Fri Jun 16 12:36:39 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Fri, 16 Jun 2006 08:36:39 -0400
Subject: [patch] Dispatch fixes
Message-ID: <4492A5D7.2000309@codesourcery.com>

This patch fixes a couple of dispatch issues:

  - First, it updates the SAL and IPP dispatch to explicitly request
    1-dimensional Ext_data access.  This is necessary when dealing with
    multi-dimensional data that has been forwarded by the
    eval_dense_expr.
  - Second, it updates the SAL dispatch evaluators to use SFINAE to only
    enable themselves if their expected leaf blocks match those of the
    expression.  This prevents the (VV)V and V(VV) evaluators from being
    ambiguous for expressions like (VV)(VV) (Neither one is enabled.)
  - Finally fixes a bug when a Redim_block is applied to a 3-dimensional
    block that resulted in the wrong stride being reported.

With this patch in place, all tests pass (with the exception of 
ref-impl/solver-qr which requires a full QR) for the configuration 
Stefan posted Wednesday, including matvec.cpp.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dispatch-fixes.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/acc04130/attachment.ksh>

From stefan at codesourcery.com  Fri Jun 16 15:47:06 2006
From: stefan at codesourcery.com (Stefan Seefeld)
Date: Fri, 16 Jun 2006 11:47:06 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <44928635.8080304@codesourcery.com>
References: <44928635.8080304@codesourcery.com>
Message-ID: <4492D27A.2030400@codesourcery.com>

Assem,

I just checked in my png bits, so your patch may already get a bit smaller.

Assem Salama wrote:

> +  // generic reader that allows us to read a generic type and cast to another
> +  
> +  // the read function for real or complex depending of the view that was
> +  // passed in
> +  template <typename T1,
> +            typename T2,
> +	    typename ViewT>
> +  void read(std::istream& is,ViewT v)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    T1 data;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // read all the points
> +    for(vsip::index_type i=0;i<num_points;i++) {
> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
> +      put(v,my_index,T2(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }

What's the reason for you using the 'put' function here, instead of
some v method ? And, why are you casting to T2 in that call, instead
of casting to ViewT::value_type ? As it stands, the above read function
takes three distinct type parameters: T1, T2, and ViewT::value_type.
I think only two are required (and the first may default to ViewT::value_type,
actually).

How portable is the above code ? It doesn't appear to care for endianness,
i.e. you cast between 'char *' and T2 without any endianness check. If you
write on a big-endian machine, and read it back on a little-endian
machine, you will thus get different values.

> +  // a write function to output a view to a matlab file.
> +  template <typename T,
> +	    typename ViewT>
> +  void write(std::ostream& os,ViewT v)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    T data;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // write all the points
> +    for(vsip::index_type i=0;i<num_points;i++) {
> +      data = get(v,my_index);
> +      os.write(reinterpret_cast<char*>(&data),sizeof(data));

The same point about endianness applies here.


> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }

Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718


From don at codesourcery.com  Fri Jun 16 16:37:49 2006
From: don at codesourcery.com (Don McCoy)
Date: Fri, 16 Jun 2006 10:37:49 -0600
Subject: [vsipl++] CFAR Benchmark cleanup
In-Reply-To: <449221AE.8090205@codesourcery.com>
References: <4491258F.3030502@codesourcery.com> <449221AE.8090205@codesourcery.com>
Message-ID: <4492DE5D.1060300@codesourcery.com>

Jules Bergmann wrote:
> 
> 'strip' should be allocated outside of cfar_detect, similar to cpow.
> 
> Unfortunately, passing an additional parameter breaks the interface 
> consistency with ImplSlice and ImplVector.
> 

I think it would be a cleaner solution if I just passed 'loop' and 
'&time' in as additional parameters and then the temp v4sf vector could 
be created before the timer was started.  I believe firbank does it that 
way, so it would make those two cases match a little better.  It also 
has the effect of eliminating the function call overhead.

Would that be ok?

Regards,

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712


From jules at codesourcery.com  Fri Jun 16 18:30:11 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Fri, 16 Jun 2006 14:30:11 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <44928635.8080304@codesourcery.com>
References: <44928635.8080304@codesourcery.com>
Message-ID: <4492F8B3.5040305@codesourcery.com>

Assem Salama wrote:
> Everyone,
>  I apologize about last e-mail, I forgot to include layout.hpp in the 
> patch.
> 

Assem,

This looks good.  Three small comments:

  - delete old get_real_ptr/get_imag_ptr functions
  - make new get_real_ptr/get_imag_ptr functions static members of
    Storage (and use storage_type::get_real_ptr(...) to access them).
  - change type of 'sz' from int32_t to uint32_t.

Also, please coordinate with Stefan, I believe he had some 
questions/comments for you on this patch.

Once the items above are fixed and Stefan's happy, please check it in.

				thanks,
				-- Jules

> +  

You should delete these now that they've been moved to layout.hpp:

> +  template<typename T>
> +  inline T* get_real_ptr(std::pair<T*,T*> ptr)
> +    { return ptr.first; }
> +  template<typename T>
> +  inline T* get_real_ptr(T* ptr)
> +    { return ptr; }
> +
> +  template<typename T>
> +  inline T* get_imag_ptr(std::pair<T*,T*> ptr)
> +    { return ptr.second; }
> +  template<typename T>
> +  inline T* get_imag_ptr(T* ptr)
> +    { return ptr; }
> +
> +
> +

> +}
> +// operator to write a view to a matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class const_View>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&                                       o,
> +  Matlab_bin_formatter<const_View<T,Block0> > const&  mbf)
> +{
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  matlab::data_element temp_data_element;
> +  int32_t    sz;

Since 'sz' is going into a uint32_t (m_view.header.size), it should be a 
  unit32_t too.

...

> +  m_view.header.size = sz;
> +
> +  o.write(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // write array name
> +  o.write(mbf.name.c_str(),mbf.name.length());
> +  // pad
> +  { 
> +    char c=0;
> +    for(vsip::length_type i=0;i<((8-mbf.name.length())&0x7);i++) o.write(&c,1);
> +  }
> +
> +  // write data
> +  {
> +  
> +    // make sure we don't need a copy if we use Ext data
> +    if(vsip::impl::Ext_data_cost<Block0,
> +      typename matlab::Matlab_desired_LP<const_View>::type >::value==0)
> +    {
> +      vsip::impl::Ext_data<Block0,
> +	                 typename matlab::Matlab_desired_LP<const_View>::type >
> +	     
> +	       m_ext(mbf.view.block());
> +
> +      typedef typename vsip::impl::Ext_data<Block0,
> +	typename matlab::Matlab_desired_LP<const_View>::type >::storage_type
> +		storage_type;
> +
> +      storage_type tmp_storage;
> +
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) o.write(reinterpret_cast<char*>
> +             (tmp_storage.get_real_ptr(m_ext.data())),

Once you make get_real_ptr a static member of Storage, you should do:

		storage_type::get_real_ptr(m_ext.data())),

> +                  num_points*sizeof(scalar_type));
> +        else o.write(reinterpret_cast<char*>
> +             (tmp_storage.get_imag_ptr(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +      }
> +    }
> +    else
> +    {
> +      typedef matlab::Subview_helper<const_View<T,Block0> > subview;
> +      typedef typename subview::realview_type r_v;
> +      typedef typename subview::imagview_type i_v;
> +      typedef typename vsip::impl::Scalar_of<T>::type sT;
> +
> +      // conventional way
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) matlab::write<sT,r_v>(o,subview::real(mbf.view));
> +        else     matlab::write<sT,i_v>(o,subview::imag(mbf.view));
> +      }
> +    }
> +  }
> +
> +  return o;
> +}


>  
>  #endif // VSIP_CSL_OUTPUT_HPP
> Index: layout.hpp
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/src/vsip/impl/layout.hpp,v
> retrieving revision 1.23
> diff -u -r1.23 layout.hpp
> --- layout.hpp	14 May 2006 02:21:04 -0000	1.23
> +++ layout.hpp	16 Jun 2006 10:21:06 -0000
> @@ -1089,6 +1089,12 @@
>  
>    static type offset(type ptr, stride_type stride)
>    { return ptr + stride; }

These should be static member functions:

> +
> +  T* get_real_ptr(type ptr)
> +    { return ptr; }
> +  T* get_imag_ptr(type ptr)
> +    { return ptr; }
> +
>  };
>  
>  
> @@ -1147,6 +1153,12 @@
>  
>    static type offset(type ptr, stride_type stride)
>    { return type(ptr.first + stride, ptr.second + stride); }
> +

Likewise:

> +  T* get_real_ptr(type ptr)
> +    { return ptr.first; }
> +  T* get_imag_ptr(type ptr)
> +    { return ptr.second; }
> +
>  };
>  
>  


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From don at codesourcery.com  Fri Jun 16 18:32:54 2006
From: don at codesourcery.com (Don McCoy)
Date: Fri, 16 Jun 2006 12:32:54 -0600
Subject: [vsipl++] CFAR Benchmark cleanup
In-Reply-To: <4492DE5D.1060300@codesourcery.com>
References: <4491258F.3030502@codesourcery.com> <449221AE.8090205@codesourcery.com> <4492DE5D.1060300@codesourcery.com>
Message-ID: <4492F956.1040303@codesourcery.com>

Don McCoy wrote:
> 
> I think it would be a cleaner solution if I just passed 'loop' and 
> '&time' in as additional parameters and then the temp v4sf vector could 
> be created before the timer was started.  I believe firbank does it that 
> way, so it would make those two cases match a little better.  It also 
> has the effect of eliminating the function call overhead.
> 
The attached patch moves the timing loop inside of cfar_detect as 
suggested above.

Ok to commit?

-- 
Don McCoy
don (at) CodeSourcery
(888) 776-0262 / (650) 331-3385, x712
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cf5.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/a6014fdc/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cf5.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/a6014fdc/attachment-0001.ksh>

From jules at codesourcery.com  Fri Jun 16 18:33:17 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Fri, 16 Jun 2006 14:33:17 -0400
Subject: [vsipl++] CFAR Benchmark cleanup
In-Reply-To: <4492DE5D.1060300@codesourcery.com>
References: <4491258F.3030502@codesourcery.com> <449221AE.8090205@codesourcery.com> <4492DE5D.1060300@codesourcery.com>
Message-ID: <4492F96D.5020304@codesourcery.com>

Don McCoy wrote:
> Jules Bergmann wrote:
>>
>> 'strip' should be allocated outside of cfar_detect, similar to cpow.
>>
>> Unfortunately, passing an additional parameter breaks the interface 
>> consistency with ImplSlice and ImplVector.
>>
> 
> I think it would be a cleaner solution if I just passed 'loop' and 
> '&time' in as additional parameters and then the temp v4sf vector could 
> be created before the timer was started.  I believe firbank does it that 
> way, so it would make those two cases match a little better.  It also 
> has the effect of eliminating the function call overhead.
> 
> Would that be ok?

That sounds great!  It is much simpler than what I was proposing.

				-- Jules
-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From jules at codesourcery.com  Fri Jun 16 19:57:52 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Fri, 16 Jun 2006 15:57:52 -0400
Subject: [vsipl++] CFAR Benchmark cleanup
In-Reply-To: <4492F956.1040303@codesourcery.com>
References: <4491258F.3030502@codesourcery.com> <449221AE.8090205@codesourcery.com> <4492DE5D.1060300@codesourcery.com> <4492F956.1040303@codesourcery.com>
Message-ID: <44930D40.9010409@codesourcery.com>

Don McCoy wrote:
> Don McCoy wrote:
>>
>> I think it would be a cleaner solution if I just passed 'loop' and 
>> '&time' in as additional parameters and then the temp v4sf vector 
>> could be created before the timer was started.  I believe firbank does 
>> it that way, so it would make those two cases match a little better.  
>> It also has the effect of eliminating the function call overhead.
>>
> The attached patch moves the timing loop inside of cfar_detect as 
> suggested above.
> 
> Ok to commit?
> 
>

Don, Yes, please check this in.  thanks, -- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From don at codesourcery.com  Sat Jun 17 00:55:59 2006
From: don at codesourcery.com (Don McCoy)
Date: Fri, 16 Jun 2006 18:55:59 -0600
Subject: [patch] Benchmarks update
Message-ID: <4493531F.5080605@codesourcery.com>

The attached patch fixes one bug (in firbank.cpp) and cleans up the 
makefiles used to build the benchmarks. 

Now, when building from source, type these commands from the object dir 
to build benchmarks:

    make benchmarks      <-- to build the all normal benchmarks
    make hpec_kernel      <-- to build the HPEC Kernel-Level benchmarks.

Building against a binary distribution of the library is very similar, 
except that it is run from within the 'benchmarks/' directory and it 
uses the make.standalone makefile.  As such, use these commands:

    cd benchmarks/
    make -f make.standalone PREFIX=/path/to/vsipl++ benchmarks
    make -f make.standalone PREFIX=/path/to/vsipl++ hpec_kernel

Several of the benchmarks require certain configuration options because 
they are written to use a certain "back-end" library explicitly.  When 
building from source, it automatically skips the benchmarks for which it 
is not configured.  For example: benchmarks/vmul_ipp.cpp will only be 
compiled if the library is configured to use Intel IPP.

When building against a binary distribution, no special benchmarks are 
built by default.  However, they may be built directly using the 
executable name.  For example:

    make -f make.standalone PREFIX=/path/to/vsipl++ vmul_ipp

The user may also wish to use the 'vars' target to determine that the 
correct PREFIX is being used and to see which libraries the installed 
VSIPL++ library is using.  E.g.

    make -f make.standalone PREFIX=/path/to/vsipl++ vars

Regards,

-- 
Don McCoy
don (at) CodeSourcery 
(888) 776-0262 / (650) 331-3385, x712

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mb.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/d87c42ba/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mb.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060616/d87c42ba/attachment-0001.ksh>

From assem at codesourcery.com  Mon Jun 19 09:44:52 2006
From: assem at codesourcery.com (Assem Salama)
Date: Mon, 19 Jun 2006 05:44:52 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <4492D27A.2030400@codesourcery.com>
References: <44928635.8080304@codesourcery.com> <4492D27A.2030400@codesourcery.com>
Message-ID: <44967214.7080801@codesourcery.com>

Stefan Seefeld wrote:
> Assem,
>
> I just checked in my png bits, so your patch may already get a bit smaller.
>
> Assem Salama wrote:
>
>   
>> +  // generic reader that allows us to read a generic type and cast to another
>> +  
>> +  // the read function for real or complex depending of the view that was
>> +  // passed in
>> +  template <typename T1,
>> +            typename T2,
>> +	    typename ViewT>
>> +  void read(std::istream& is,ViewT v)
>> +  {
>> +    vsip::dimension_type const View_dim = ViewT::dim;
>> +    vsip::Index<View_dim> my_index;
>> +    vsip::impl::Length<View_dim> v_extent = extent(v);
>> +    T1 data;
>> +
>> +    // get num_points
>> +    vsip::length_type num_points = v.size();
>> +
>> +    // read all the points
>> +    for(vsip::index_type i=0;i<num_points;i++) {
>> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
>> +      put(v,my_index,T2(data));
>> +
>> +      // increment index
>> +      my_index = vsip::impl::next(v_extent,my_index);
>> +    }
>> +
>> +  }
>>     
>
> What's the reason for you using the 'put' function here, instead of
> some v method ? And, why are you casting to T2 in that call, instead
> of casting to ViewT::value_type ? As it stands, the above read function
> takes three distinct type parameters: T1, T2, and ViewT::value_type.
> I think only two are required (and the first may default to ViewT::value_type,
> actually).
>   
The reason that I am using the put function is because I need to pass 
index into the function because of arbitrary dimension. I didn't know 
that ViewT::value_type existed. Thanks for pointing that out to me, I 
will make use of that.
> How portable is the above code ? It doesn't appear to care for endianness,
> i.e. you cast between 'char *' and T2 without any endianness check. If you
> write on a big-endian machine, and read it back on a little-endian
> machine, you will thus get different values.
>   
You are correct about endianness, I still haven't looked at the endian 
issue yet.

>   
>> +  // a write function to output a view to a matlab file.
>> +  template <typename T,
>> +	    typename ViewT>
>> +  void write(std::ostream& os,ViewT v)
>> +  {
>> +    vsip::dimension_type const View_dim = ViewT::dim;
>> +    vsip::Index<View_dim> my_index;
>> +    vsip::impl::Length<View_dim> v_extent = extent(v);
>> +    T data;
>> +
>> +    // get num_points
>> +    vsip::length_type num_points = v.size();
>> +
>> +    // write all the points
>> +    for(vsip::index_type i=0;i<num_points;i++) {
>> +      data = get(v,my_index);
>> +      os.write(reinterpret_cast<char*>(&data),sizeof(data));
>>     
>
> The same point about endianness applies here.
>
>
>   
>> +
>> +      // increment index
>> +      my_index = vsip::impl::next(v_extent,my_index);
>> +    }
>> +
>> +  }
>>     
>
> Thanks,
> 		Stefan
>
>   



From assem at codesourcery.com  Mon Jun 19 10:13:19 2006
From: assem at codesourcery.com (Assem Salama)
Date: Mon, 19 Jun 2006 06:13:19 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <4492D27A.2030400@codesourcery.com>
References: <44928635.8080304@codesourcery.com> <4492D27A.2030400@codesourcery.com>
Message-ID: <449678BF.5090007@codesourcery.com>

Stefan Seefeld wrote:
> Assem,
>
> I just checked in my png bits, so your patch may already get a bit smaller.
>
> Assem Salama wrote:
>
>   
>> +  // generic reader that allows us to read a generic type and cast to another
>> +  
>> +  // the read function for real or complex depending of the view that was
>> +  // passed in
>> +  template <typename T1,
>> +            typename T2,
>> +	    typename ViewT>
>> +  void read(std::istream& is,ViewT v)
>> +  {
>> +    vsip::dimension_type const View_dim = ViewT::dim;
>> +    vsip::Index<View_dim> my_index;
>> +    vsip::impl::Length<View_dim> v_extent = extent(v);
>> +    T1 data;
>> +
>> +    // get num_points
>> +    vsip::length_type num_points = v.size();
>> +
>> +    // read all the points
>> +    for(vsip::index_type i=0;i<num_points;i++) {
>> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
>> +      put(v,my_index,T2(data));
>> +
>> +      // increment index
>> +      my_index = vsip::impl::next(v_extent,my_index);
>> +    }
>> +
>> +  }
>>     
>
> What's the reason for you using the 'put' function here, instead of
> some v method ? And, why are you casting to T2 in that call, instead
> of casting to ViewT::value_type ? As it stands, the above read function
> takes three distinct type parameters: T1, T2, and ViewT::value_type.
> I think only two are required (and the first may default to ViewT::value_type,
> actually).
>
> How portable is the above code ? It doesn't appear to care for endianness,
> i.e. you cast between 'char *' and T2 without any endianness check. If you
> write on a big-endian machine, and read it back on a little-endian
> machine, you will thus get different values.
>
>   
>> +  // a write function to output a view to a matlab file.
>> +  template <typename T,
>> +	    typename ViewT>
>> +  void write(std::ostream& os,ViewT v)
>> +  {
>> +    vsip::dimension_type const View_dim = ViewT::dim;
>> +    vsip::Index<View_dim> my_index;
>> +    vsip::impl::Length<View_dim> v_extent = extent(v);
>> +    T data;
>> +
>> +    // get num_points
>> +    vsip::length_type num_points = v.size();
>> +
>> +    // write all the points
>> +    for(vsip::index_type i=0;i<num_points;i++) {
>> +      data = get(v,my_index);
>> +      os.write(reinterpret_cast<char*>(&data),sizeof(data));
>>     
>
> The same point about endianness applies here.
>   

I disagree. We can write in either endian format and we chose to write 
in the native format of the machine.
>
>   
>> +
>> +      // increment index
>> +      my_index = vsip::impl::next(v_extent,my_index);
>> +    }
>> +
>> +  }
>>     
>
> Thanks,
> 		Stefan
>
>   



From assem at codesourcery.com  Mon Jun 19 11:36:03 2006
From: assem at codesourcery.com (Assem Salama)
Date: Mon, 19 Jun 2006 07:36:03 -0400
Subject: Matlab IO
Message-ID: <44968C23.5090008@codesourcery.com>

Everyone,
  This is the new Matlab IO patch addressing Stefan and Jule's issues.

Thanks,
Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06192006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060619/e3175312/attachment.ksh>

From jules at codesourcery.com  Tue Jun 20 15:51:43 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Tue, 20 Jun 2006 11:51:43 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <44968C23.5090008@codesourcery.com>
References: <44968C23.5090008@codesourcery.com>
Message-ID: <4498198F.4090106@codesourcery.com>

Assem Salama wrote:
> Everyone,
>  This is the new Matlab IO patch addressing Stefan and Jule's issues.

Assem,

The corrections from the previous patch look good, however the new bits 
for handling byte-ordering need a couple of changes.

First, you need to read and write the endian word as a single 16-bit 
value (instead of as 2 8-bit values).  This way, the system byte-order 
will be reflected in the value on disk.  (The current code writes the 
endian word out as individual 8-bit values, which results in the same 
value on disk regardless of the system byte-ordering).

To write the value:

	uint16_t endian = 'M' << 8 | 'I';
	o.write(&endian, sizeof(uint16_t);

Likewise, to read the value back in:

	uint16_t endian;
	is.read(&endian, sizeof(uint16_t));

Once you've read the value back in, you don't need to know the 
byte-order of the host (the 'get_machine_endian' function isn't 
necessary), you just need to know whether the byte-order is the same as 
or different from the file.  You check this by examining the endian word 
from the header.  If it is equivalent to 'MI', then the host and file 
have the same byte-order (both little-endian or both big-endian).  If it 
is equivalent to 'IM', then the host and file have different byte 
orders, and you need to byte swap.

	... read in endian ...
	if (endian == 'M' << 8 | 'I')
	   // The system and file have same byte-order,
	   // so we don't need to swizzle bytes.
	   byte_swap = 0;
	else if (endian == 'I' << 8 | 'M')
	   // The system and file have different byte-orders,
	   // so we need to swizzle bytes.
	   byte_swap = 1;
	else
	   // Something bad happened, we expect to see either
	   // 'MI' or 'IM'.
	   throw ...

Second, If the system and file have different byte-ordering, than you 
need to swap bytes for *all* multi-byte values read in, including the 
header fields for type, size, matrix dimensionality, etc, not just for 
data values.

				-- Jules


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From assem at codesourcery.com  Tue Jun 20 23:30:33 2006
From: assem at codesourcery.com (Assem Salama)
Date: Tue, 20 Jun 2006 19:30:33 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <4498198F.4090106@codesourcery.com>
References: <44968C23.5090008@codesourcery.com> <4498198F.4090106@codesourcery.com>
Message-ID: <44988519.2050601@codesourcery.com>

Jules,
  I don't understand. The endian field is a string, not a 16 bit 
value... I tried as a test to switch the endian field and swap the data 
and it works fine...

Thanks,
Assem

Jules Bergmann wrote:
> Assem Salama wrote:
>> Everyone,
>>  This is the new Matlab IO patch addressing Stefan and Jule's issues.
>
> Assem,
>
> The corrections from the previous patch look good, however the new 
> bits for handling byte-ordering need a couple of changes.
>
> First, you need to read and write the endian word as a single 16-bit 
> value (instead of as 2 8-bit values).  This way, the system byte-order 
> will be reflected in the value on disk.  (The current code writes the 
> endian word out as individual 8-bit values, which results in the same 
> value on disk regardless of the system byte-ordering).
>
> To write the value:
>
>     uint16_t endian = 'M' << 8 | 'I';
>     o.write(&endian, sizeof(uint16_t);
>
> Likewise, to read the value back in:
>
>     uint16_t endian;
>     is.read(&endian, sizeof(uint16_t));
>
> Once you've read the value back in, you don't need to know the 
> byte-order of the host (the 'get_machine_endian' function isn't 
> necessary), you just need to know whether the byte-order is the same 
> as or different from the file.  You check this by examining the endian 
> word from the header.  If it is equivalent to 'MI', then the host and 
> file have the same byte-order (both little-endian or both 
> big-endian).  If it is equivalent to 'IM', then the host and file have 
> different byte orders, and you need to byte swap.
>
>     ... read in endian ...
>     if (endian == 'M' << 8 | 'I')
>        // The system and file have same byte-order,
>        // so we don't need to swizzle bytes.
>        byte_swap = 0;
>     else if (endian == 'I' << 8 | 'M')
>        // The system and file have different byte-orders,
>        // so we need to swizzle bytes.
>        byte_swap = 1;
>     else
>        // Something bad happened, we expect to see either
>        // 'MI' or 'IM'.
>        throw ...
>
> Second, If the system and file have different byte-ordering, than you 
> need to swap bytes for *all* multi-byte values read in, including the 
> header fields for type, size, matrix dimensionality, etc, not just for 
> data values.
>
>                 -- Jules
>
>



From jules at codesourcery.com  Wed Jun 21 11:39:23 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Wed, 21 Jun 2006 07:39:23 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <44988519.2050601@codesourcery.com>
References: <44968C23.5090008@codesourcery.com> <4498198F.4090106@codesourcery.com> <44988519.2050601@codesourcery.com>
Message-ID: <44992FEB.7070606@codesourcery.com>

Assem Salama wrote:
> Jules,
>  I don't understand. The endian field is a string, not a 16 bit value... 
> I tried as a test to switch the endian field and swap the data and it 
> works fine...
> 

Assem,

 From the matlab file format description, the "Endian Indicator":

"Contains the two characters, M and I, written to the
MAT-file in this order, as a 16-bit value. If, when read
from the MAT-file as a 16-bit value, the characters appear
in reversed order (IM rather than MI), it indicates that the
program reading the MAT-file must perform
byte-swapping to interpret the data in the MAT-file
correctly."

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From assem at codesourcery.com  Wed Jun 21 16:06:31 2006
From: assem at codesourcery.com (Assem Salama)
Date: Wed, 21 Jun 2006 12:06:31 -0400
Subject: Matlab IO
Message-ID: <44996E87.7060707@codesourcery.com>

Everyone,
  Fixed endian stuff according to Jule's comments.

Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06212006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060621/81e1165b/attachment.ksh>

From assem at codesourcery.com  Wed Jun 21 17:15:02 2006
From: assem at codesourcery.com (Assem Salama)
Date: Wed, 21 Jun 2006 13:15:02 -0400
Subject: [vsipl++] Matlab IO
In-Reply-To: <44996E87.7060707@codesourcery.com>
References: <44996E87.7060707@codesourcery.com>
Message-ID: <44997E96.2020302@codesourcery.com>

Everyone,
  Just realized that I still have to work on swapping headers, doing 
that now...

Thanks,
Assem

Assem Salama wrote:
> Everyone,
>  Fixed endian stuff according to Jule's comments.
>
> Assem
> ------------------------------------------------------------------------
>
> ? .matlab_file.cpp.swp
> ? .matlab_file.hpp.swp
> ? generic_reader.hpp
> ? matlab_file.cpp
> ? matlab_file.hpp
> ? matlab_temp
> Index: matlab.hpp
> ===================================================================
> RCS file: matlab.hpp
> diff -N matlab.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab.hpp	21 Jun 2006 16:05:23 -0000
> @@ -0,0 +1,279 @@
> +#ifndef VSIP_CSL_MATLAB_HPP
> +#define VSIP_CSL_MATLAB_HPP
> +
> +#include <stdint.h>
> +#include <iostream>
> +#include <vsip/support.hpp>
> +#include <vsip/impl/metaprogramming.hpp>
> +#include <vsip/impl/fns_elementwise.hpp>
> +#include <vsip/impl/length.hpp>
> +#include <vsip/impl/domain-utils.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +namespace matlab
> +{
> +  struct data_element
> +  {
> +    int32_t type;
> +    uint32_t size;
> +  };
> +
> +  template <int Dim>
> +  struct view_header
> +  {
> +    data_element header;
> +    data_element array_flags_header;
> +    char array_flags[8];
> +    data_element dim_header;
> +    uint32_t dim[Dim + Dim%2]; //the dim has to be aligned to an 8 byte boundary
> +    data_element array_name_header;
> +  };
> +
> +  // helper struct to get the imaginary part of a view.
> +  template <typename ViewT,
> +            bool IsComplex =
> +	      vsip::impl::Is_complex<typename ViewT::value_type>::value>
> +  struct Subview_helper;
> +
> +  template <typename ViewT>
> +  struct Subview_helper<ViewT,true>
> +  {
> +    typedef typename ViewT::realview_type realview_type;
> +    typedef typename ViewT::imagview_type imagview_type;
> +
> +    static realview_type real(ViewT v) { return v.real(); }
> +    static imagview_type imag(ViewT v) { return v.imag(); }
> +  };
> +
> +  template <typename ViewT>
> +  struct Subview_helper<ViewT,false>
> +  {
> +    typedef ViewT realview_type;
> +    typedef ViewT imagview_type;
> +
> +    static realview_type real(ViewT v) { return v; }
> +    static imagview_type imag(ViewT v) { return v; }
> +  };
> +
> +  template <typename T,size_t type_size,bool to_swap_or_not_to_swap>
> +  struct swap_value 
> +  { 
> +    static void swap(T *d) {d=d;} 
> +  };
> +
> +  template <typename T>
> +  struct swap_value<T,2,true>
> +  {
> +    static void swap(T* d)
> +    {
> +      char *p = reinterpret_cast<char*>(d);
> +      std::swap(p[0],p[1]);
> +    }
> +  };
> +
> +  template <typename T>
> +  struct swap_value<T,4,true>
> +  {
> +    static void swap(T* d)
> +    {
> +      char *p = reinterpret_cast<char*>(d);
> +      std::swap(p[0],p[3]);
> +      std::swap(p[1],p[2]);
> +    }
> +  };
> +
> +  template <typename T>
> +  struct swap_value<T,8,true>
> +  {
> +    static void swap(T* d)
> +    {
> +      char *p = reinterpret_cast<char*>(d);
> +      std::swap(p[0],p[7]);
> +      std::swap(p[1],p[6]);
> +      std::swap(p[2],p[5]);
> +      std::swap(p[3],p[4]);
> +    }
> +  };
> +
> +
> +  // generic reader that allows us to read a generic type and cast to another
> +  
> +  // the read function for real or complex depending of the view that was
> +  // passed in
> +  template <typename T1,
> +	    typename ViewT>
> +  void read(std::istream& is,ViewT v,uint16_t endian)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    T1 data;
> +    typedef typename ViewT::value_type scalar_type;
> +    typedef void (*fn_type)(T1 *data);
> +    fn_type swap_fn;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // figure out if we need to do endian swaps
> +    if(endian != ('M' << 8 | 'I'))
> +      swap_fn = swap_value<T1,sizeof(T1),true>::swap;
> +    else
> +      swap_fn = swap_value<T1,sizeof(T1),false>::swap;
> +
> +    // read all the points
> +    for(vsip::index_type i=0;i<num_points;i++) {
> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
> +      swap_fn(&data);
> +      put(v,my_index,scalar_type(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }
> +
> +  // a write function to output a view to a matlab file.
> +  template <typename ViewT>
> +  void write(std::ostream& os,ViewT v)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    typename ViewT::value_type data;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // write all the points
> +    for(vsip::index_type i=0;i<num_points;i++) {
> +      data = get(v,my_index);
> +      os.write(reinterpret_cast<char*>(&data),sizeof(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }
> +
> +  struct header
> +  {
> +    char description[116];
> +    char subsyt_data[8];
> +    char version[2];
> +    uint16_t endian;
> +  };
> +
> +  // constants for matlab binary format
> +
> +  // data types
> +  static int const miINT8           = 1;
> +  static int const miUINT8          = 2;
> +  static int const miINT16          = 3;
> +  static int const miUINT16         = 4;
> +  static int const miINT32          = 5;
> +  static int const miUINT32         = 6;
> +  static int const miSINGLE         = 7;
> +  static int const miDOUBLE         = 9;
> +  static int const miINT64          = 12;
> +  static int const miUINT64         = 13;
> +  static int const miMATRIX         = 14;
> +  static int const miCOMPRESSED     = 15;
> +  static int const miUTF8           = 16;
> +  static int const miUTF16          = 17;
> +  static int const miUTF32          = 18;
> +  
> +  // class types
> +  static int const mxCELL_CLASS     = 1;
> +  static int const mxSTRUCT_CLASS   = 2;
> +  static int const mxOBJECT_CLASS   = 3;
> +  static int const mxCHAR_CLASS     = 4;
> +  static int const mxSPARSE_CLASS   = 5;
> +  static int const mxDOUBLE_CLASS   = 6;
> +  static int const mxSINGLE_CLASS   = 7;
> +  static int const mxINT8_CLASS     = 8;
> +  static int const mxUINT8_CLASS    = 9;
> +  static int const mxINT16_CLASS    = 10;
> +  static int const mxUINT16_CLASS   = 11;
> +  static int const mxINT32_CLASS    = 12;
> +  static int const mxUINT32_CLASS   = 13;
> +
> +  // matlab header traits
> +  template <int size,bool is_signed,bool is_int>
> +  struct Matlab_header_traits;
> +
> +  template <>
> +  struct Matlab_header_traits<1, true, true> // char
> +  { 
> +    static int const value_type = miINT8;
> +    static int const class_type = mxINT8_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<1, false, true> // unsigned char
> +  { 
> +    static int const value_type = miUINT8;
> +    static int const class_type = mxUINT8_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<2, true, true> // short
> +  { 
> +    static int const value_type = miINT16;
> +    static int const class_type = mxINT16_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<2, false, true> // unsigned short
> +  { 
> +    static int const value_type = miUINT16;
> +    static int const class_type = mxUINT16_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, true, true> // int
> +  { 
> +    static int const value_type= miINT32;
> +    static int const class_type= mxINT32_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, false, true> // unsigned int
> +  { 
> +    static int const value_type= miUINT32;
> +    static int const class_type= mxUINT32_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, true, false> // float
> +  { 
> +    static int const value_type= miSINGLE;
> +    static int const class_type= mxSINGLE_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<8, true, false> // double
> +  { 
> +    static int const value_type= miDOUBLE;
> +    static int const class_type= mxDOUBLE_CLASS;
> +  };
> +
> +  // matlab desired layouts
> +  template <template <typename,typename> class View>
> +  struct Matlab_desired_LP
> +  {
> +    static vsip::dimension_type const dim = vsip::impl::Dim_of_view<View>::dim;
> +    typedef vsip::impl::Layout<dim,
> +                     typename vsip::impl::Col_major<dim>::type,
> +                     vsip::impl::Stride_unit_dense,
> +		     vsip::impl::Cmplx_split_fmt> type;
> +  };
> +
> +
> +} // namesapce matlab
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_HPP
> Index: matlab_bin_formatter.hpp
> ===================================================================
> RCS file: matlab_bin_formatter.hpp
> diff -N matlab_bin_formatter.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab_bin_formatter.hpp	21 Jun 2006 16:05:23 -0000
> @@ -0,0 +1,370 @@
> +/* Copyright (c) 2005, 2006 by CodeSourcery.  All rights reserved. */
> +
> +/** @file    vsip_csl/matlab_bin_formatter.hpp
> +    @author  Assem Salama
> +    @date    2006-05-22
> +    @brief   VSIPL++ CodeSourcery Library: Matlab binary formatter
> +*/
> +
> +#ifndef VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> +#define VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> +
> +#include <stdint.h>
> +#include <string>
> +#include <limits>
> +#include <vsip_csl/matlab.hpp>
> +#include <vsip/impl/fns_scalar.hpp>
> +#include <vsip/impl/fns_elementwise.hpp>
> +#include <vsip/impl/metaprogramming.hpp>
> +#include <vsip/impl/view_traits.hpp>
> +#include <vsip/impl/extdata.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +  struct Matlab_bin_hdr
> +  {
> +    Matlab_bin_hdr(std::string const& descr) : 
> +      description(descr),version("MATLAB 5.0 : ") {}
> +    Matlab_bin_hdr() : 
> +      description(" "),version("MATLAB 5.0 : ") {}
> +
> +    // description
> +    std::string description;
> +    std::string version;
> +    uint16_t endian;
> +
> +  };
> +
> +  template <typename ViewT>
> +  struct Matlab_bin_formatter
> +  {
> +    Matlab_bin_formatter(ViewT v,std::string const& name) :
> +      view(v), name(name), header()  {}
> +    Matlab_bin_formatter(ViewT v,std::string const& name,
> +      Matlab_bin_hdr &h) :
> +        view(v), name(name), header(h)  {}
> +
> +    ViewT view;
> +    std::string name;
> +    Matlab_bin_hdr header;
> +
> +  };
> +
> +} // namespace vsip_csl
> +
> +/****************************************************************************
> + * Definitions
> + ***************************************************************************/
> +
> +namespace vsip_csl
> +{
> +
> +// operator to write matlab header
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&           o,
> +  Matlab_bin_hdr const&   h)
> +{
> +  matlab::header m_hdr;
> +
> +  // set hdr to spaces
> +  memset(&(m_hdr),' ',sizeof(m_hdr));
> +  strncpy(m_hdr.description, h.version.data(), h.version.length());
> +  strncpy(m_hdr.description+h.version.length(), h.description.data(),
> +    h.description.length());
> +  m_hdr.version[1] = 0x01; m_hdr.version[0] = 0x00;
> +  m_hdr.endian = 'M' << 8 | 'I';
> +
> +  // write header
> +  o.write(reinterpret_cast<char*>(&m_hdr),sizeof(m_hdr));
> +
> +  return o;
> +}
> +// operator to write a view to a matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class const_View>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&                                       o,
> +  Matlab_bin_formatter<const_View<T,Block0> > const&  mbf)
> +{
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  matlab::data_element temp_data_element;
> +  size_t    sz;
> +  matlab::view_header<vsip::impl::Dim_of_view<const_View>::dim > m_view;
> +  vsip::length_type num_points = mbf.view.size();
> +  vsip::dimension_type v_dims = vsip::impl::Dim_of_view<const_View>::dim;
> +
> +  memset(&m_view,0,sizeof(m_view));
> +
> +  // matrix data type
> +  m_view.header.type = matlab::miMATRIX;
> +  m_view.header.size = 1; // TEMP
> +
> +  // array flags
> +  m_view.array_flags_header.type = matlab::miUINT32;
> +  m_view.array_flags_header.size = 8;
> +  if(vsip::impl::Is_complex<T>::value) 
> +    m_view.array_flags[1] |= 0x8; // Complex
> +
> +  // fill in class
> +  m_view.array_flags[0] = 
> +    matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type;
> +
> +  // make sure we found a matching trait
> +  assert(m_view.array_flags[0] != 0);
> +  
> +  // dimension sizes
> +  m_view.dim_header.type = matlab::miINT32;
> +  m_view.dim_header.size = v_dims*4; // 4 bytes per dimension
> +  // fill in dimension
> +  for(vsip::dimension_type i =0;i<v_dims;i++)
> +  {
> +    m_view.dim[i] = mbf.view.size(i);
> +  }
> +
> +  // if this view is a vector, we need to make second dimension a one
> +  if(v_dims == 1)
> +  {
> +    m_view.dim_header.size += 4;
> +    m_view.dim[1] = 1;
> +  }
> +
> +  // array name
> +  m_view.array_name_header.type = matlab::miINT8;
> +  m_view.array_name_header.size = mbf.name.length();
> +
> +
> +  // calculate size
> +  sz = sizeof(m_view)-8;
> +  sz += mbf.name.length();
> +  sz += (8-mbf.name.length())&0x7;
> +  sz += 8; // 8 bytes of header for real data
> +  if(vsip::impl::Is_complex<T>::value) sz += 8; // 8 more for complex data
> +  sz += num_points*sizeof(T);
> +  m_view.header.size = sz;
> +
> +  o.write(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // write array name
> +  o.write(mbf.name.c_str(),mbf.name.length());
> +  // pad
> +  { 
> +    char c=0;
> +    for(vsip::length_type i=0;i<((8-mbf.name.length())&0x7);i++) o.write(&c,1);
> +  }
> +
> +  // write data
> +  {
> +  
> +    // make sure we don't need a copy if we use Ext data
> +    if(vsip::impl::Ext_data_cost<Block0,
> +      typename matlab::Matlab_desired_LP<const_View>::type >::value==0)
> +    {
> +      vsip::impl::Ext_data<Block0,
> +	                 typename matlab::Matlab_desired_LP<const_View>::type >
> +	     
> +	       m_ext(mbf.view.block());
> +
> +      typedef typename vsip::impl::Ext_data<Block0,
> +	typename matlab::Matlab_desired_LP<const_View>::type >::storage_type
> +		storage_type;
> +
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) o.write(reinterpret_cast<char*>
> +             (storage_type::get_real_ptr(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +        else o.write(reinterpret_cast<char*>
> +             (storage_type::get_imag_ptr(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +      }
> +    }
> +    else
> +    {
> +      typedef matlab::Subview_helper<const_View<T,Block0> > subview;
> +      typedef typename subview::realview_type r_v;
> +      typedef typename subview::imagview_type i_v;
> +
> +      // conventional way
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) matlab::write<r_v>(o,subview::real(mbf.view));
> +        else     matlab::write<i_v>(o,subview::imag(mbf.view));
> +      }
> +    }
> +  }
> +
> +  return o;
> +}
> +
> +// operator to read matlab header
> +inline
> +std::istream&
> +operator>>(
> +  std::istream&           is,
> +  Matlab_bin_hdr          &h)
> +{
> +  matlab::header m_hdr;
> +
> +  // read header
> +  is.read(reinterpret_cast<char*>(&m_hdr),sizeof(m_hdr));
> +
> +  h.version[1] = m_hdr.version[1];
> +  h.version[0] = m_hdr.version[0];
> +  h.endian = m_hdr.endian;
> +
> +  return is;
> +}
> +
> +// operator to read view from matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class View>
> +inline
> +std::istream&
> +operator>>(
> +  std::istream&                                       is,
> +  Matlab_bin_formatter<View<T,Block0> >               mbf)
> +{
> +  matlab::data_element temp_data_element;
> +  matlab::view_header<vsip::impl::Dim_of_view<View>::dim> m_view;
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  typedef matlab::Subview_helper<View<T,Block0> > subview;
> +  typedef typename subview::realview_type r_v;
> +  typedef typename subview::imagview_type i_v;
> +  vsip::dimension_type v_dim = vsip::impl::Dim_of_view<View>::dim;
> +
> +
> +  // read header
> +  is.read(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // is this complex?
> +  if(vsip::impl::Is_complex<T>::value && !(m_view.array_flags[1]&0x8))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read complex matrix into a real matrix"));
> +
> +
> +  // is this the same class?
> +  if(!(m_view.array_flags[0] == 
> +            (matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type)))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read a matrix of a different class"));
> +
> +  // do dimensions agree?
> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for vectors
> +  if(v_dim != (m_view.dim_header.size/4))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read a matrix of different dimensions"));
> +
> +  for(vsip::dimension_type i=0;i<v_dim;i++)
> +    if(mbf.view.size(i) != m_view.dim[i])
> +      VSIP_IMPL_THROW(std::runtime_error(
> +        "Matrix dimensions don't agree"));
> +
> +  // read array name
> +  if(m_view.array_name_header.type & 0xffff0000)
> +  {
> +    // array name is short
> +
> +  }
> +  else
> +  {
> +    int length = m_view.array_name_header.size;
> +    char c;
> +    char c_array[128];
> +    // the name is longer than 4 bytes
> +    if(length > 128)
> +      VSIP_IMPL_THROW(std::runtime_error(
> +        "Name of matrix is too large"));
> +
> +    is.read(c_array,length);
> +    c_array[length] = 0;
> +    // read padding
> +    for(int i=0;i<((8-length)&0x7);i++) is.read(&c,1);
> +  }
> +
> +  // read data, we will go in this loop twice if we have complex data
> +  for (int i=0;i <= vsip::impl::Is_complex<T>::value;i++)
> +  {
> +    uint16_t endian = mbf.header.endian;
> +
> +    // read data header
> +    is.read(reinterpret_cast<char*>(&temp_data_element),
> +            sizeof(temp_data_element));
> +
> +    // Because we don't know how the data was stored, we need to instantiate
> +    // generic_reader which can read a type and cast into a different one
> +    if(temp_data_element.type == matlab::miINT8) 
> +    {
> +      if(i==0)matlab::read<int8_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<int8_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miUINT8) 
> +    {
> +      if(i==0)matlab::read<uint8_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<uint8_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miINT16) 
> +    {
> +      if(i==0)matlab::read<int16_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<int16_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miUINT16) 
> +    {
> +      if(i==0)matlab::read<uint16_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<uint16_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miINT32) 
> +    {
> +      if(i==0)matlab::read<int32_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<int32_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miUINT32) 
> +    {
> +      if(i==0)matlab::read<uint32_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<uint32_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miSINGLE) 
> +    {
> +      if(i==0)matlab::read<float,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<float,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else
> +    {
> +      if(i==0)matlab::read<double,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<double,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +
> +  }
> +
> +  return is;
> +}
> +
> +
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> Index: matlab_text_formatter.hpp
> ===================================================================
> RCS file: matlab_text_formatter.hpp
> diff -N matlab_text_formatter.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab_text_formatter.hpp	21 Jun 2006 16:05:23 -0000
> @@ -0,0 +1,91 @@
> +/* Copyright (c) 2005, 2006 by CodeSourcery.  All rights reserved. */
> +
> +/** @file    vsip_csl/matlab_text_formatter.hpp
> +    @author  Assem Salama
> +    @date    2006-05-22
> +    @brief   VSIPL++ CodeSourcery Library: Matlab text formatter
> +*/
> +
> +#ifndef VSIP_CSL_MATLAB_TEXT_FORMATTER_HPP
> +#define VSIP_CSL_MATLAB_TEXT_FORMATTER_HPP
> +
> +#include <string>
> +#include <vsip/support.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +  /// This struct is just used as a wrapper so that we can overload the
> +  /// << operator
> +  template <typename ViewT>
> +  struct Matlab_text_formatter
> +  {
> +    Matlab_text_formatter(ViewT v) : v_(v), view_name_("a")  {}
> +    Matlab_text_formatter(ViewT v,std::string name) :
> +      v_(v), view_name_(name)  {}
> +
> +    ViewT v_;
> +    std::string view_name_;
> +  };
> +
> +
> +} // namespace vsip_csl
> +
> +
> +/****************************************************************************
> + * Definitions
> + ***************************************************************************/
> +
> +namespace vsip_csl
> +{
> +
> +/// Write a matrix to a stream using a Matlab_text_formatter
> +
> +template <typename T,
> +          typename Block0>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&		                                out,
> +  Matlab_text_formatter<vsip::Matrix<T,Block0> >        mf)
> +  VSIP_NOTHROW
> +
> +{
> +  out << mf.view_name_ << " = " << std::endl;
> +  out << "[" << std::endl;
> +  for(vsip::index_type i=0;i<mf.v_.size(0);i++) {
> +    out << "  [ ";
> +    for(vsip::index_type j=0;j<mf.v_.size(1);j++)
> +      out << mf.v_.get(i,j) << " ";
> +    out << "]" << std::endl;
> +  }
> +  out << "];" << std::endl;
> +
> +  return out;
> +}
> +
> +/// Write a vector to a stream using a Matlab_text_formatter
> +
> +template <typename T,
> +          typename Block0>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&		                          out,
> +  Matlab_text_formatter<vsip::Vector<T,Block0> >  mf)
> +  VSIP_NOTHROW
> +
> +{
> +  out << mf.view_name_ << " = " << std::endl;
> +  out << "[ "; 
> +  for(vsip::index_type i=0;i<mf.v_.size(0);i++) {
> +    out << mf.v_.get(i) << " ";
> +  }
> +  out << "];" << std::endl;
> +
> +  return out;
> +}
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_TEXT_FORMATTER_HPP
> Index: output.hpp
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/src/vsip_csl/output.hpp,v
> retrieving revision 1.2
> diff -u -r1.2 output.hpp
> --- output.hpp	25 May 2006 19:06:49 -0000	1.2
> +++ output.hpp	21 Jun 2006 16:05:23 -0000
> @@ -114,6 +114,6 @@
>    return out;
>  }
>  
> -} // namespace vsip
> +} // namespace vsip_csl
>  
>  #endif // VSIP_CSL_OUTPUT_HPP
>   



From jules at codesourcery.com  Wed Jun 21 18:52:23 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Wed, 21 Jun 2006 14:52:23 -0400
Subject: [vsipl++] [patch] Benchmarks update
In-Reply-To: <4493531F.5080605@codesourcery.com>
References: <4493531F.5080605@codesourcery.com>
Message-ID: <44999567.2040902@codesourcery.com>

Don, This looks good.  Please check it in. -- Jules

Don McCoy wrote:
> The attached patch fixes one bug (in firbank.cpp) and cleans up the 
> makefiles used to build the benchmarks.
> Now, when building from source, type these commands from the object dir 
> to build benchmarks:
> 
>    make benchmarks      <-- to build the all normal benchmarks
>    make hpec_kernel      <-- to build the HPEC Kernel-Level benchmarks.
> 
> Building against a binary distribution of the library is very similar, 
> except that it is run from within the 'benchmarks/' directory and it 
> uses the make.standalone makefile.  As such, use these commands:
> 
>    cd benchmarks/
>    make -f make.standalone PREFIX=/path/to/vsipl++ benchmarks
>    make -f make.standalone PREFIX=/path/to/vsipl++ hpec_kernel
> 
> Several of the benchmarks require certain configuration options because 
> they are written to use a certain "back-end" library explicitly.  When 
> building from source, it automatically skips the benchmarks for which it 
> is not configured.  For example: benchmarks/vmul_ipp.cpp will only be 
> compiled if the library is configured to use Intel IPP.
> 
> When building against a binary distribution, no special benchmarks are 
> built by default.  However, they may be built directly using the 
> executable name.  For example:
> 
>    make -f make.standalone PREFIX=/path/to/vsipl++ vmul_ipp
> 
> The user may also wish to use the 'vars' target to determine that the 
> correct PREFIX is being used and to see which libraries the installed 
> VSIPL++ library is using.  E.g.
> 
>    make -f make.standalone PREFIX=/path/to/vsipl++ vars
> 
> Regards,
> 


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From jules at codesourcery.com  Wed Jun 21 19:14:35 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Wed, 21 Jun 2006 15:14:35 -0400
Subject: Fix for matvec-prod - Re: [patch] Dispatch fixes
In-Reply-To: <4492A5D7.2000309@codesourcery.com>
References: <4492A5D7.2000309@codesourcery.com>
Message-ID: <44999A9B.4080502@codesourcery.com>

Jules Bergmann wrote:
> This patch fixes a couple of dispatch issues:
> 
>  - First, it updates the SAL and IPP dispatch to explicitly request
>    1-dimensional Ext_data access.  This is necessary when dealing with
>    multi-dimensional data that has been forwarded by the
>    eval_dense_expr.
>  - Second, it updates the SAL dispatch evaluators to use SFINAE to only
>    enable themselves if their expected leaf blocks match those of the
>    expression.  This prevents the (VV)V and V(VV) evaluators from being
>    ambiguous for expressions like (VV)(VV) (Neither one is enabled.)
>  - Finally fixes a bug when a Redim_block is applied to a 3-dimensional
>    block that resulted in the wrong stride being reported.
> 
> With this patch in place, all tests pass (with the exception of 
> ref-impl/solver-qr which requires a full QR) for the configuration 
> Stefan posted Wednesday, including matvec.cpp.

Stefan,

With this patch, the matvec.cpp and/or matvec-prod.cpp failures should 
have been fixed.  IIRC believe the problem was with gems (generlized 
matrix sum), which does:

	C = alpha * A + beta * C;

This was getting redispatched from a matrix expression to a vector 
expression.  However, SAL dispatch hadn't been updated to handle this 
properly (Ext_data by default uses Block::dim to determine 
dimensionality, which breaks when a 2-D dense block is used in a 1-D 
context.  The fix is to tell Ext_data which dimensionality to use).

Let me know if IPP is still broken with this patch.

				-- Jules


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From assem at codesourcery.com  Thu Jun 22 19:10:45 2006
From: assem at codesourcery.com (Assem Salama)
Date: Thu, 22 Jun 2006 15:10:45 -0400
Subject: Matlab  IO
Message-ID: <449AEB35.6030307@codesourcery.com>

Everyone,
  Fixed endian stuff.

Thanks,
Assem
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cvs.diff.06222006.1.log
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060622/24547b95/attachment.ksh>

From assem at codesourcery.com  Sat Jun 24 01:41:37 2006
From: assem at codesourcery.com (Assem Salama)
Date: Fri, 23 Jun 2006 21:41:37 -0400
Subject: [vsipl++] Matlab  IO
In-Reply-To: <449AEB35.6030307@codesourcery.com>
References: <449AEB35.6030307@codesourcery.com>
Message-ID: <449C9851.2020006@codesourcery.com>

Assem Salama wrote:
> Everyone,
>  Fixed endian stuff.
>
> Thanks,
> Assem
> ------------------------------------------------------------------------
>
> ? .matlab.hpp.swp
> ? generic_reader.hpp
> ? matlab_file.cpp
> ? matlab_file.hpp
> ? matlab_temp
> Index: matlab.hpp
> ===================================================================
> RCS file: matlab.hpp
> diff -N matlab.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab.hpp	22 Jun 2006 19:06:38 -0000
> @@ -0,0 +1,313 @@
> +#ifndef VSIP_CSL_MATLAB_HPP
> +#define VSIP_CSL_MATLAB_HPP
> +
> +#include <stdint.h>
> +#include <iostream>
> +#include <vsip/support.hpp>
> +#include <vsip/impl/metaprogramming.hpp>
> +#include <vsip/impl/fns_elementwise.hpp>
> +#include <vsip/impl/length.hpp>
> +#include <vsip/impl/domain-utils.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +namespace matlab
> +{
> +  struct data_element
> +  {
> +    int32_t type;
> +    uint32_t size;
> +  };
> +
> +  template <vsip::dimension_type Dim>
> +  struct view_header
> +  {
> +    data_element header;
> +    data_element array_flags_header;
> +    //char array_flags[8];
>   
Forgot to remove this comment... It is now taken out.
> +    uint32_t array_flags[2];
> +    data_element dim_header;
> +    uint32_t dim[Dim + Dim%2]; //the dim has to be aligned to an 8 byte boundary
> +    data_element array_name_header;
> +  };
> +
> +  // helper struct to get the imaginary part of a view.
> +  template <typename ViewT,
> +            bool IsComplex =
> +	      vsip::impl::Is_complex<typename ViewT::value_type>::value>
> +  struct Subview_helper;
> +
> +  template <typename ViewT>
> +  struct Subview_helper<ViewT,true>
> +  {
> +    typedef typename ViewT::realview_type realview_type;
> +    typedef typename ViewT::imagview_type imagview_type;
> +
> +    static realview_type real(ViewT v) { return v.real(); }
> +    static imagview_type imag(ViewT v) { return v.imag(); }
> +  };
> +
> +  template <typename ViewT>
> +  struct Subview_helper<ViewT,false>
> +  {
> +    typedef ViewT realview_type;
> +    typedef ViewT imagview_type;
> +
> +    static realview_type real(ViewT v) { return v; }
> +    static imagview_type imag(ViewT v) { return v; }
> +  };
> +
> +  template <typename T,size_t type_size,bool to_swap_or_not_to_swap>
> +  struct swap_value 
> +  { 
> +    static void swap(T *d) {d=d;} 
> +  };
> +
> +  template <typename T>
> +  struct swap_value<T,2,true>
> +  {
> +    static void swap(T* d)
> +    {
> +      char *p = reinterpret_cast<char*>(d);
> +      std::swap(p[0],p[1]);
> +    }
> +  };
> +
> +  template <typename T>
> +  struct swap_value<T,4,true>
> +  {
> +    static void swap(T* d)
> +    {
> +      char *p = reinterpret_cast<char*>(d);
> +      std::swap(p[0],p[3]);
> +      std::swap(p[1],p[2]);
> +    }
> +  };
> +
> +  template <typename T>
> +  struct swap_value<T,8,true>
> +  {
> +    static void swap(T* d)
> +    {
> +      char *p = reinterpret_cast<char*>(d);
> +      std::swap(p[0],p[7]);
> +      std::swap(p[1],p[6]);
> +      std::swap(p[2],p[5]);
> +      std::swap(p[3],p[4]);
> +    }
> +  };
> +
> +  // swaps an array of values based on a template param
> +  template <typename T>
> +  void swap_array(T *d, vsip::impl::Int_type<1>)
> +  { swap_value<T,sizeof(T),true>::swap(&(d[0])); }
> +  template <typename T>
> +  void swap_array(T *d, vsip::impl::Int_type<2>)
> +  { swap_value<T,sizeof(T),true>::swap(&(d[0]));
> +    swap_value<T,sizeof(T),true>::swap(&(d[1])); }
> +  template <typename T>
> +  void swap_array(T *d, vsip::impl::Int_type<3>)
> +  { swap_value<T,sizeof(T),true>::swap(&(d[0]));
> +    swap_value<T,sizeof(T),true>::swap(&(d[1]));
> +    swap_value<T,sizeof(T),true>::swap(&(d[2])); }
> +
> +  // swaps the header of a view
> +  template <vsip::dimension_type dim>
> +  void swap_header(view_header<dim> &header, uint16_t endian)
> +  {
> +    if(endian == ('I' << 8 | 'M') )
> +    {
> +      // swap all fields
> +      swap_value<int32_t,4,true>::swap(&(header.header.type));
> +      swap_value<uint32_t,4,true>::swap(&(header.header.size));
> +      swap_value<int32_t,4,true>::swap(&(header.array_flags_header.type));
> +      swap_value<uint32_t,4,true>::swap(&(header.array_flags_header.size));
> +      swap_value<int32_t,4,true>::swap(&(header.dim_header.type));
> +      swap_value<uint32_t,4,true>::swap(&(header.dim_header.size));
> +      swap_value<int32_t,4,true>::swap(&(header.array_name_header.type));
> +      swap_value<uint32_t,4,true>::swap(&(header.array_name_header.size));
> +      swap_array<uint32_t>(header.dim, vsip::impl::Int_type<dim>());
> +      swap_array<uint32_t>(header.array_flags, vsip::impl::Int_type<2>());
> +    }
> +  }
> +
> +  // generic reader that allows us to read a generic type and cast to another
> +  
> +  // the read function for real or complex depending of the view that was
> +  // passed in
> +  template <typename T1,
> +	    typename ViewT>
> +  void read(std::istream& is,ViewT v,uint16_t endian)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    T1 data;
> +    typedef typename ViewT::value_type scalar_type;
> +    typedef void (*fn_type)(T1 *data);
> +    fn_type swap_fn;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // figure out if we need to do endian swaps
> +    if(endian != ('M' << 8 | 'I'))
> +      swap_fn = swap_value<T1,sizeof(T1),true>::swap;
> +    else
> +      swap_fn = swap_value<T1,sizeof(T1),false>::swap;
> +
> +    // read all the points
> +    for(vsip::index_type i=0;i<num_points;i++) {
> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
> +      swap_fn(&data);
> +      put(v,my_index,scalar_type(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }
> +
> +  // a write function to output a view to a matlab file.
> +  template <typename ViewT>
> +  void write(std::ostream& os,ViewT v)
> +  {
> +    vsip::dimension_type const View_dim = ViewT::dim;
> +    vsip::Index<View_dim> my_index;
> +    vsip::impl::Length<View_dim> v_extent = extent(v);
> +    typename ViewT::value_type data;
> +
> +    // get num_points
> +    vsip::length_type num_points = v.size();
> +
> +    // write all the points
> +    for(vsip::index_type i=0;i<num_points;i++) {
> +      data = get(v,my_index);
> +      os.write(reinterpret_cast<char*>(&data),sizeof(data));
> +
> +      // increment index
> +      my_index = vsip::impl::next(v_extent,my_index);
> +    }
> +
> +  }
> +
> +  struct header
> +  {
> +    char description[116];
> +    char subsyt_data[8];
> +    char version[2];
> +    uint16_t endian;
> +  };
> +
> +  // constants for matlab binary format
> +
> +  // data types
> +  static int const miINT8           = 1;
> +  static int const miUINT8          = 2;
> +  static int const miINT16          = 3;
> +  static int const miUINT16         = 4;
> +  static int const miINT32          = 5;
> +  static int const miUINT32         = 6;
> +  static int const miSINGLE         = 7;
> +  static int const miDOUBLE         = 9;
> +  static int const miINT64          = 12;
> +  static int const miUINT64         = 13;
> +  static int const miMATRIX         = 14;
> +  static int const miCOMPRESSED     = 15;
> +  static int const miUTF8           = 16;
> +  static int const miUTF16          = 17;
> +  static int const miUTF32          = 18;
> +  
> +  // class types
> +  static int const mxCELL_CLASS     = 1;
> +  static int const mxSTRUCT_CLASS   = 2;
> +  static int const mxOBJECT_CLASS   = 3;
> +  static int const mxCHAR_CLASS     = 4;
> +  static int const mxSPARSE_CLASS   = 5;
> +  static int const mxDOUBLE_CLASS   = 6;
> +  static int const mxSINGLE_CLASS   = 7;
> +  static int const mxINT8_CLASS     = 8;
> +  static int const mxUINT8_CLASS    = 9;
> +  static int const mxINT16_CLASS    = 10;
> +  static int const mxUINT16_CLASS   = 11;
> +  static int const mxINT32_CLASS    = 12;
> +  static int const mxUINT32_CLASS   = 13;
> +
> +  // matlab header traits
> +  template <int size,bool is_signed,bool is_int>
> +  struct Matlab_header_traits;
> +
> +  template <>
> +  struct Matlab_header_traits<1, true, true> // char
> +  { 
> +    static int const value_type = miINT8;
> +    static uint8_t const class_type = mxINT8_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<1, false, true> // unsigned char
> +  { 
> +    static int const value_type = miUINT8;
> +    static uint8_t const class_type = mxUINT8_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<2, true, true> // short
> +  { 
> +    static int const value_type = miINT16;
> +    static uint8_t const class_type = mxINT16_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<2, false, true> // unsigned short
> +  { 
> +    static int const value_type = miUINT16;
> +    static uint8_t const class_type = mxUINT16_CLASS; 
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, true, true> // int
> +  { 
> +    static int const value_type= miINT32;
> +    static uint8_t const class_type= mxINT32_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, false, true> // unsigned int
> +  { 
> +    static int const value_type= miUINT32;
> +    static uint8_t const class_type= mxUINT32_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<4, true, false> // float
> +  { 
> +    static int const value_type= miSINGLE;
> +    static uint8_t const class_type= mxSINGLE_CLASS;
> +  };
> +
> +  template <>
> +  struct Matlab_header_traits<8, true, false> // double
> +  { 
> +    static int const value_type= miDOUBLE;
> +    static uint8_t const class_type= mxDOUBLE_CLASS;
> +  };
> +
> +  // matlab desired layouts
> +  template <template <typename,typename> class View>
> +  struct Matlab_desired_LP
> +  {
> +    static vsip::dimension_type const dim = vsip::impl::Dim_of_view<View>::dim;
> +    typedef vsip::impl::Layout<dim,
> +                     typename vsip::impl::Col_major<dim>::type,
> +                     vsip::impl::Stride_unit_dense,
> +		     vsip::impl::Cmplx_split_fmt> type;
> +  };
> +
> +
> +} // namesapce matlab
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_HPP
> Index: matlab_bin_formatter.hpp
> ===================================================================
> RCS file: matlab_bin_formatter.hpp
> diff -N matlab_bin_formatter.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab_bin_formatter.hpp	22 Jun 2006 19:06:38 -0000
> @@ -0,0 +1,379 @@
> +/* Copyright (c) 2005, 2006 by CodeSourcery.  All rights reserved. */
> +
> +/** @file    vsip_csl/matlab_bin_formatter.hpp
> +    @author  Assem Salama
> +    @date    2006-05-22
> +    @brief   VSIPL++ CodeSourcery Library: Matlab binary formatter
> +*/
> +
> +#ifndef VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> +#define VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> +
> +#include <stdint.h>
> +#include <string>
> +#include <limits>
> +#include <vsip_csl/matlab.hpp>
> +#include <vsip/impl/fns_scalar.hpp>
> +#include <vsip/impl/fns_elementwise.hpp>
> +#include <vsip/impl/metaprogramming.hpp>
> +#include <vsip/impl/view_traits.hpp>
> +#include <vsip/impl/extdata.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +  struct Matlab_bin_hdr
> +  {
> +    Matlab_bin_hdr(std::string const& descr) : 
> +      description(descr),version("MATLAB 5.0 : ") {}
> +    Matlab_bin_hdr() : 
> +      description(" "),version("MATLAB 5.0 : ") {}
> +
> +    // description
> +    std::string description;
> +    std::string version;
> +    uint16_t endian;
> +
> +  };
> +
> +  template <typename ViewT>
> +  struct Matlab_bin_formatter
> +  {
> +    Matlab_bin_formatter(ViewT v,std::string const& name) :
> +      view(v), name(name), header()  {}
> +    Matlab_bin_formatter(ViewT v,std::string const& name,
> +      Matlab_bin_hdr &h) :
> +        view(v), name(name), header(h)  {}
> +
> +    ViewT view;
> +    std::string name;
> +    Matlab_bin_hdr header;
> +
> +  };
> +
> +} // namespace vsip_csl
> +
> +/****************************************************************************
> + * Definitions
> + ***************************************************************************/
> +
> +namespace vsip_csl
> +{
> +
> +// operator to write matlab header
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&           o,
> +  Matlab_bin_hdr const&   h)
> +{
> +  matlab::header m_hdr;
> +
> +  // set hdr to spaces
> +  memset(&(m_hdr),' ',sizeof(m_hdr));
> +  strncpy(m_hdr.description, h.version.data(), h.version.length());
> +  strncpy(m_hdr.description+h.version.length(), h.description.data(),
> +    h.description.length());
> +  m_hdr.version[1] = 0x01; m_hdr.version[0] = 0x00;
> +  m_hdr.endian = 'M' << 8 | 'I';
> +
> +  // write header
> +  o.write(reinterpret_cast<char*>(&m_hdr),sizeof(m_hdr));
> +
> +  return o;
> +}
> +// operator to write a view to a matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class const_View>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&                                       o,
> +  Matlab_bin_formatter<const_View<T,Block0> > const&  mbf)
> +{
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  matlab::data_element temp_data_element;
> +  size_t    sz;
> +  matlab::view_header<vsip::impl::Dim_of_view<const_View>::dim > m_view;
> +  vsip::length_type num_points = mbf.view.size();
> +  vsip::dimension_type v_dims = vsip::impl::Dim_of_view<const_View>::dim;
> +
> +  memset(&m_view,0,sizeof(m_view));
> +
> +  // matrix data type
> +  m_view.header.type = matlab::miMATRIX;
> +  m_view.header.size = 1; // TEMP
> +
> +  // array flags
> +  m_view.array_flags_header.type = matlab::miUINT32;
> +  m_view.array_flags_header.size = 8;
> +  if(vsip::impl::Is_complex<T>::value) 
> +    m_view.array_flags[0] |= (1<<11); // Complex
> +
> +  // fill in class
> +  m_view.array_flags[0] |= 
> +    (matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type);
> +
> +  // dimension sizes
> +  m_view.dim_header.type = matlab::miINT32;
> +  m_view.dim_header.size = v_dims*4; // 4 bytes per dimension
> +  // fill in dimension
> +  for(vsip::dimension_type i =0;i<v_dims;i++)
> +  {
> +    m_view.dim[i] = mbf.view.size(i);
> +  }
> +
> +  // if this view is a vector, we need to make second dimension a one
> +  if(v_dims == 1)
> +  {
> +    m_view.dim_header.size += 4;
> +    m_view.dim[1] = 1;
> +  }
> +
> +  // array name
> +  m_view.array_name_header.type = matlab::miINT8;
> +  m_view.array_name_header.size = mbf.name.length();
> +
> +
> +  // calculate size
> +  sz = sizeof(m_view)-8;
> +  sz += mbf.name.length();
> +  sz += (8-mbf.name.length())&0x7;
> +  sz += 8; // 8 bytes of header for real data
> +  if(vsip::impl::Is_complex<T>::value) sz += 8; // 8 more for complex data
> +  sz += num_points*sizeof(T);
> +  m_view.header.size = sz;
> +
> +  o.write(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // write array name
> +  o.write(mbf.name.c_str(),mbf.name.length());
> +  // pad
> +  { 
> +    char c=0;
> +    for(vsip::length_type i=0;i<((8-mbf.name.length())&0x7);i++) o.write(&c,1);
> +  }
> +
> +  // write data
> +  {
> +  
> +    // make sure we don't need a copy if we use Ext data
> +    if(vsip::impl::Ext_data_cost<Block0,
> +      typename matlab::Matlab_desired_LP<const_View>::type >::value==0)
> +    {
> +      vsip::impl::Ext_data<Block0,
> +	                 typename matlab::Matlab_desired_LP<const_View>::type >
> +	     
> +	       m_ext(mbf.view.block());
> +
> +      typedef typename vsip::impl::Ext_data<Block0,
> +	typename matlab::Matlab_desired_LP<const_View>::type >::storage_type
> +		storage_type;
> +
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) o.write(reinterpret_cast<char*>
> +             (storage_type::get_real_ptr(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +        else o.write(reinterpret_cast<char*>
> +             (storage_type::get_imag_ptr(m_ext.data())),
> +                  num_points*sizeof(scalar_type));
> +      }
> +    }
> +    else
> +    {
> +      typedef matlab::Subview_helper<const_View<T,Block0> > subview;
> +      typedef typename subview::realview_type r_v;
> +      typedef typename subview::imagview_type i_v;
> +
> +      // conventional way
> +      temp_data_element.type = matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::value_type;
> +
> +      temp_data_element.size = num_points*sizeof(scalar_type);
> +      for(int i=0;i<=vsip::impl::Is_complex<T>::value;i++)
> +      {
> +        o.write(reinterpret_cast<char*>(&temp_data_element),
> +                  sizeof(temp_data_element));
> +        if(i==0) matlab::write<r_v>(o,subview::real(mbf.view));
> +        else     matlab::write<i_v>(o,subview::imag(mbf.view));
> +      }
> +    }
> +  }
> +
> +  return o;
> +}
> +
> +// operator to read matlab header
> +inline
> +std::istream&
> +operator>>(
> +  std::istream&           is,
> +  Matlab_bin_hdr          &h)
> +{
> +  matlab::header m_hdr;
> +
> +  // read header
> +  is.read(reinterpret_cast<char*>(&m_hdr),sizeof(m_hdr));
> +
> +  h.version[1] = m_hdr.version[1];
> +  h.version[0] = m_hdr.version[0];
> +  h.endian = m_hdr.endian;
> +
> +  return is;
> +}
> +
> +// operator to read view from matlab file
> +template <typename T,
> +          typename Block0,
> +	  template <typename,typename> class View>
> +inline
> +std::istream&
> +operator>>(
> +  std::istream&                                       is,
> +  Matlab_bin_formatter<View<T,Block0> >               mbf)
> +{
> +  matlab::data_element temp_data_element;
> +  matlab::view_header<vsip::impl::Dim_of_view<View>::dim> m_view;
> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
> +  typedef matlab::Subview_helper<View<T,Block0> > subview;
> +  typedef typename subview::realview_type r_v;
> +  typedef typename subview::imagview_type i_v;
> +  vsip::dimension_type v_dim = vsip::impl::Dim_of_view<View>::dim;
> +
> +
> +  // read header
> +  is.read(reinterpret_cast<char*>(&m_view),sizeof(m_view));
> +
> +  // do we need to swap fields?
> +  matlab::swap_header(m_view,mbf.header.endian);
> +
> +  // is this complex?
> +  if(vsip::impl::Is_complex<T>::value && !(m_view.array_flags[0]&(1<<11)))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read complex matrix into a real matrix"));
> +
> +
> +  // is this the same class?
> +  if(!((m_view.array_flags[0] & 0xff) == 
> +            (matlab::Matlab_header_traits<sizeof(scalar_type),
> +                  std::numeric_limits<scalar_type>::is_signed,
> +                  std::numeric_limits<scalar_type>::is_integer>::class_type)
> +	    ))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read a matrix of a different class"));
> +
> +  // do dimensions agree?
> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for vectors
> +  if(v_dim != (m_view.dim_header.size/4))
> +    VSIP_IMPL_THROW(std::runtime_error(
> +      "Trying to read a matrix of different dimensions"));
> +
> +  for(vsip::dimension_type i=0;i<v_dim;i++)
> +    if(mbf.view.size(i) != m_view.dim[i])
> +      VSIP_IMPL_THROW(std::runtime_error(
> +        "Matrix dimensions don't agree"));
> +
> +  // read array name
> +  if(m_view.array_name_header.type & 0xffff0000)
> +  {
> +    // array name is short
> +
> +  }
> +  else
> +  {
> +    int length = m_view.array_name_header.size;
> +    char c;
> +    char c_array[128];
> +    // the name is longer than 4 bytes
> +    if(length > 128)
> +      VSIP_IMPL_THROW(std::runtime_error(
> +        "Name of matrix is too large"));
> +
> +    is.read(c_array,length);
> +    c_array[length] = 0;
> +    // read padding
> +    for(int i=0;i<((8-length)&0x7);i++) is.read(&c,1);
> +  }
> +
> +  // read data, we will go in this loop twice if we have complex data
> +  for (int i=0;i <= vsip::impl::Is_complex<T>::value;i++)
> +  {
> +    uint16_t endian = mbf.header.endian;
> +
> +    // read data header
> +    is.read(reinterpret_cast<char*>(&temp_data_element),
> +            sizeof(temp_data_element));
> +
> +    // should we swap this field?
> +    if(endian == ('I' << 8 | 'M'))
> +    {
> +      matlab::swap_value<int32_t,4,true>::swap(&(temp_data_element.type));
> +      matlab::swap_value<uint32_t,4,true>::swap(&(temp_data_element.size));
> +    }
> +
> +
> +    // Because we don't know how the data was stored, we need to instantiate
> +    // generic_reader which can read a type and cast into a different one
> +    if(temp_data_element.type == matlab::miINT8) 
> +    {
> +      if(i==0)matlab::read<int8_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<int8_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miUINT8) 
> +    {
> +      if(i==0)matlab::read<uint8_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<uint8_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miINT16) 
> +    {
> +      if(i==0)matlab::read<int16_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<int16_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miUINT16) 
> +    {
> +      if(i==0)matlab::read<uint16_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<uint16_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miINT32) 
> +    {
> +      if(i==0)matlab::read<int32_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<int32_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miUINT32) 
> +    {
> +      if(i==0)matlab::read<uint32_t,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<uint32_t,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else if(temp_data_element.type == matlab::miSINGLE) 
> +    {
> +      if(i==0)matlab::read<float,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<float,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +    else
> +    {
> +      if(i==0)matlab::read<double,r_v>(is,subview::real(mbf.view),endian);
> +      else    matlab::read<double,i_v>(is,subview::imag(mbf.view),endian);
> +    }
> +
> +  }
> +
> +  return is;
> +}
> +
> +
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_BIN_FORMATTER_HPP
> Index: matlab_text_formatter.hpp
> ===================================================================
> RCS file: matlab_text_formatter.hpp
> diff -N matlab_text_formatter.hpp
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ matlab_text_formatter.hpp	22 Jun 2006 19:06:38 -0000
> @@ -0,0 +1,91 @@
> +/* Copyright (c) 2005, 2006 by CodeSourcery.  All rights reserved. */
> +
> +/** @file    vsip_csl/matlab_text_formatter.hpp
> +    @author  Assem Salama
> +    @date    2006-05-22
> +    @brief   VSIPL++ CodeSourcery Library: Matlab text formatter
> +*/
> +
> +#ifndef VSIP_CSL_MATLAB_TEXT_FORMATTER_HPP
> +#define VSIP_CSL_MATLAB_TEXT_FORMATTER_HPP
> +
> +#include <string>
> +#include <vsip/support.hpp>
> +
> +namespace vsip_csl
> +{
> +
> +  /// This struct is just used as a wrapper so that we can overload the
> +  /// << operator
> +  template <typename ViewT>
> +  struct Matlab_text_formatter
> +  {
> +    Matlab_text_formatter(ViewT v) : v_(v), view_name_("a")  {}
> +    Matlab_text_formatter(ViewT v,std::string name) :
> +      v_(v), view_name_(name)  {}
> +
> +    ViewT v_;
> +    std::string view_name_;
> +  };
> +
> +
> +} // namespace vsip_csl
> +
> +
> +/****************************************************************************
> + * Definitions
> + ***************************************************************************/
> +
> +namespace vsip_csl
> +{
> +
> +/// Write a matrix to a stream using a Matlab_text_formatter
> +
> +template <typename T,
> +          typename Block0>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&		                                out,
> +  Matlab_text_formatter<vsip::Matrix<T,Block0> >        mf)
> +  VSIP_NOTHROW
> +
> +{
> +  out << mf.view_name_ << " = " << std::endl;
> +  out << "[" << std::endl;
> +  for(vsip::index_type i=0;i<mf.v_.size(0);i++) {
> +    out << "  [ ";
> +    for(vsip::index_type j=0;j<mf.v_.size(1);j++)
> +      out << mf.v_.get(i,j) << " ";
> +    out << "]" << std::endl;
> +  }
> +  out << "];" << std::endl;
> +
> +  return out;
> +}
> +
> +/// Write a vector to a stream using a Matlab_text_formatter
> +
> +template <typename T,
> +          typename Block0>
> +inline
> +std::ostream&
> +operator<<(
> +  std::ostream&		                          out,
> +  Matlab_text_formatter<vsip::Vector<T,Block0> >  mf)
> +  VSIP_NOTHROW
> +
> +{
> +  out << mf.view_name_ << " = " << std::endl;
> +  out << "[ "; 
> +  for(vsip::index_type i=0;i<mf.v_.size(0);i++) {
> +    out << mf.v_.get(i) << " ";
> +  }
> +  out << "];" << std::endl;
> +
> +  return out;
> +}
> +
> +} // namespace vsip_csl
> +
> +#endif // VSIP_CSL_MATLAB_TEXT_FORMATTER_HPP
> Index: output.hpp
> ===================================================================
> RCS file: /home/cvs/Repository/vpp/src/vsip_csl/output.hpp,v
> retrieving revision 1.2
> diff -u -r1.2 output.hpp
> --- output.hpp	25 May 2006 19:06:49 -0000	1.2
> +++ output.hpp	22 Jun 2006 19:06:38 -0000
> @@ -114,6 +114,6 @@
>    return out;
>  }
>  
> -} // namespace vsip
> +} // namespace vsip_csl
>  
>  #endif // VSIP_CSL_OUTPUT_HPP
>   



From jules at codesourcery.com  Tue Jun 27 19:39:13 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Tue, 27 Jun 2006 15:39:13 -0400
Subject: [vsipl++] Matlab  IO
In-Reply-To: <449C9851.2020006@codesourcery.com>
References: <449AEB35.6030307@codesourcery.com> <449C9851.2020006@codesourcery.com>
Message-ID: <44A18961.2060504@codesourcery.com>

Assem Salama wrote:
> Assem Salama wrote:
>> Everyone,
>>  Fixed endian stuff.

Assem,

>> +
>> +  template <typename T,size_t type_size,bool to_swap_or_not_to_swap>
>> +  struct swap_value +  { +    static void swap(T *d) {d=d;} +  };

For our coding convention, struct and class names should begin with a 
capital letter: 'Swap_value'

>> +
>> +  template <typename T>
>> +  struct swap_value<T,2,true>
>> +  {
>> +    static void swap(T* d)
>> +    {
>> +      char *p = reinterpret_cast<char*>(d);
>> +      std::swap(p[0],p[1]);
>> +    }
>> +  };
>> +
>> +  template <typename T>
>> +  struct swap_value<T,4,true>
>> +  {
>> +    static void swap(T* d)
>> +    {
>> +      char *p = reinterpret_cast<char*>(d);
>> +      std::swap(p[0],p[3]);
>> +      std::swap(p[1],p[2]);
>> +    }
>> +  };
>> +
>> +  template <typename T>
>> +  struct swap_value<T,8,true>
>> +  {
>> +    static void swap(T* d)
>> +    {
>> +      char *p = reinterpret_cast<char*>(d);
>> +      std::swap(p[0],p[7]);
>> +      std::swap(p[1],p[6]);
>> +      std::swap(p[2],p[5]);
>> +      std::swap(p[3],p[4]);
>> +    }
>> +  };

You can wrap the 'Swap_value' class with a function:

template <typename T>
void
swap_value(T& value, bool swap)
{
   if (swap)
     swap_value<T, sizeof(T), true>::swap(&value);
}

>> +
>> +  // swaps an array of values based on a template param
>> +  template <typename T>
>> +  void swap_array(T *d, vsip::impl::Int_type<1>)
>> +  { swap_value<T,sizeof(T),true>::swap(&(d[0])); }
>> +  template <typename T>
>> +  void swap_array(T *d, vsip::impl::Int_type<2>)
>> +  { swap_value<T,sizeof(T),true>::swap(&(d[0]));
>> +    swap_value<T,sizeof(T),true>::swap(&(d[1])); }
>> +  template <typename T>
>> +  void swap_array(T *d, vsip::impl::Int_type<3>)
>> +  { swap_value<T,sizeof(T),true>::swap(&(d[0]));
>> +    swap_value<T,sizeof(T),true>::swap(&(d[1]));
>> +    swap_value<T,sizeof(T),true>::swap(&(d[2])); }

Is there a reason that swap_array takes the array size as a template 
parameter?

The pros of passing the size this way are primarily in performance.  The 
above code will force the compiler to inline the individual calls 
instead of performing a loop.

However, the cons are increased code size (both source code and object 
code), longer compile times, and limiting the situations where the 
function can be called.

Can you change swap_array to take the array size as a regular parameter.

>> +
>> +  // swaps the header of a view
>> +  template <vsip::dimension_type dim>
>> +  void swap_header(view_header<dim> &header, uint16_t endian)

Instead of passing 'endian' to each function and having it decode 'MI' 
vs 'IM' to determine if swapping is necessary, it would be better to 
have operator>> perform the check and pass a boolean parameter:

	void swap_header(..., bool swap_bytes)

This centralizes the knowledge of how matlab files encode endianness 
into one place in the code instead of replicating it.  It also makes the 
function's behavior easier to understand.

>> +  {

With the 'swap_value' helper function and the 'swap_bytes' bool 
parameter, these become:

	swap_value(header.header.type, swap_bytes);
	swap_value(header.header.size, swap_bytes);
	...

>> +    if(endian == ('I' << 8 | 'M') )
>> +    {
>> +      // swap all fields
>> +      swap_value<int32_t,4,true>::swap(&(header.header.type));
>> +      swap_value<uint32_t,4,true>::swap(&(header.header.size));
>> +      
>> swap_value<int32_t,4,true>::swap(&(header.array_flags_header.type));
>> +      
>> swap_value<uint32_t,4,true>::swap(&(header.array_flags_header.size));
>> +      swap_value<int32_t,4,true>::swap(&(header.dim_header.type));
>> +      swap_value<uint32_t,4,true>::swap(&(header.dim_header.size));
>> +      
>> swap_value<int32_t,4,true>::swap(&(header.array_name_header.type));
>> +      
>> swap_value<uint32_t,4,true>::swap(&(header.array_name_header.size));
>> +      swap_array<uint32_t>(header.dim, vsip::impl::Int_type<dim>());
>> +      swap_array<uint32_t>(header.array_flags, 
>> vsip::impl::Int_type<2>());
>> +    }
>> +  }
>> +
>> +  // generic reader that allows us to read a generic type and cast to 
>> another
>> +  +  // the read function for real or complex depending of the view 
>> that was
>> +  // passed in

What does "generic type" mean in the above comment?

A comment like the following would be more clear:

// Read a N-dimensional matlab XXX.  The value type of the file object
// is specified by T1 and can be different from the value type of the
// VSIPL++ view.  For views of complex data, this function is called
// once for the real subview and once for the imaginary subview.

>> +  template <typename T1,
>> +        typename ViewT>
>> +  void read(std::istream& is,ViewT v,uint16_t endian)
>> +  {
>> +    vsip::dimension_type const View_dim = ViewT::dim;
>> +    vsip::Index<View_dim> my_index;
>> +    vsip::impl::Length<View_dim> v_extent = extent(v);
>> +    T1 data;
>> +    typedef typename ViewT::value_type scalar_type;
>> +    typedef void (*fn_type)(T1 *data);
>> +    fn_type swap_fn;
>> +
>> +    // get num_points
>> +    vsip::length_type num_points = v.size();
>> +
>> +    // figure out if we need to do endian swaps
>> +    if(endian != ('M' << 8 | 'I'))
>> +      swap_fn = swap_value<T1,sizeof(T1),true>::swap;
>> +    else
>> +      swap_fn = swap_value<T1,sizeof(T1),false>::swap;
>> +
>> +    // read all the points
>> +    for(vsip::index_type i=0;i<num_points;i++) {
>> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
>> +      swap_fn(&data);

With 'swap_value' wrapper, this becomes:

	  swap_value(data, swap_bytes);

>> +      put(v,my_index,scalar_type(data));
>> +
>> +      // increment index
>> +      my_index = vsip::impl::next(v_extent,my_index);
>> +    }
>> +
>> +  }
>> +


>> +
>> +// operator to read view from matlab file
>> +template <typename T,
>> +          typename Block0,
>> +      template <typename,typename> class View>
>> +inline
>> +std::istream&
>> +operator>>(
>> +  std::istream&                                       is,
>> +  Matlab_bin_formatter<View<T,Block0> >               mbf)
>> +{
>> +  matlab::data_element temp_data_element;
>> +  matlab::view_header<vsip::impl::Dim_of_view<View>::dim> m_view;
>> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
>> +  typedef matlab::Subview_helper<View<T,Block0> > subview;
>> +  typedef typename subview::realview_type r_v;
>> +  typedef typename subview::imagview_type i_v;
>> +  vsip::dimension_type v_dim = vsip::impl::Dim_of_view<View>::dim;
>> +
>> +
>> +  // read header
>> +  is.read(reinterpret_cast<char*>(&m_view),sizeof(m_view));

After reading the header, this is the place to check 'endian' to 
determine if byte swapping is necessary:

	bool swap_bytes = (endian != 'M' << 8 | 'I');

>> +
>> +  // do we need to swap fields?

Since we already know if it is necessary to swap bytes, the comment 
might be:

	// Swap header fields if necessary.

>> +  matlab::swap_header(m_view,mbf.header.endian);
>> +
>> +  // is this complex?
>> +  if(vsip::impl::Is_complex<T>::value && 
>> !(m_view.array_flags[0]&(1<<11)))
>> +    VSIP_IMPL_THROW(std::runtime_error(
>> +      "Trying to read complex matrix into a real matrix"));
>> +
>> +
>> +  // is this the same class?
>> +  if(!((m_view.array_flags[0] & 0xff) == +            
>> (matlab::Matlab_header_traits<sizeof(scalar_type),
>> +                  std::numeric_limits<scalar_type>::is_signed,
>> +                  
>> std::numeric_limits<scalar_type>::is_integer>::class_type)
>> +        ))
>> +    VSIP_IMPL_THROW(std::runtime_error(
>> +      "Trying to read a matrix of a different class"));

The error message should mention "view" instead of "matrix":

	"Trying to read a view of a different class"

>> +
>> +  // do dimensions agree?
>> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for 
>> vectors
>> +  if(v_dim != (m_view.dim_header.size/4))
>> +    VSIP_IMPL_THROW(std::runtime_error(
>> +      "Trying to read a matrix of different dimensions"));

	"Trying to read a view with different dimensions"

>> +
>> +  for(vsip::dimension_type i=0;i<v_dim;i++)
>> +    if(mbf.view.size(i) != m_view.dim[i])
>> +      VSIP_IMPL_THROW(std::runtime_error(
>> +        "Matrix dimensions don't agree"));

	"View dimensions don't agree"



-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705


From assem at codesourcery.com  Wed Jun 28 03:18:41 2006
From: assem at codesourcery.com (Assem Salama)
Date: Tue, 27 Jun 2006 23:18:41 -0400
Subject: [vsipl++] Matlab  IO
In-Reply-To: <44A18961.2060504@codesourcery.com>
References: <449AEB35.6030307@codesourcery.com> <449C9851.2020006@codesourcery.com> <44A18961.2060504@codesourcery.com>
Message-ID: <44A1F511.8080201@codesourcery.com>

Jules Bergmann wrote:
> Assem Salama wrote:
>> Assem Salama wrote:
>>> Everyone,
>>>  Fixed endian stuff.
>
> Assem,
>
>>> +
>>> +  template <typename T,size_t type_size,bool to_swap_or_not_to_swap>
>>> +  struct swap_value +  { +    static void swap(T *d) {d=d;} +  };
>
> For our coding convention, struct and class names should begin with a 
> capital letter: 'Swap_value'
>
>>> +
>>> +  template <typename T>
>>> +  struct swap_value<T,2,true>
>>> +  {
>>> +    static void swap(T* d)
>>> +    {
>>> +      char *p = reinterpret_cast<char*>(d);
>>> +      std::swap(p[0],p[1]);
>>> +    }
>>> +  };
>>> +
>>> +  template <typename T>
>>> +  struct swap_value<T,4,true>
>>> +  {
>>> +    static void swap(T* d)
>>> +    {
>>> +      char *p = reinterpret_cast<char*>(d);
>>> +      std::swap(p[0],p[3]);
>>> +      std::swap(p[1],p[2]);
>>> +    }
>>> +  };
>>> +
>>> +  template <typename T>
>>> +  struct swap_value<T,8,true>
>>> +  {
>>> +    static void swap(T* d)
>>> +    {
>>> +      char *p = reinterpret_cast<char*>(d);
>>> +      std::swap(p[0],p[7]);
>>> +      std::swap(p[1],p[6]);
>>> +      std::swap(p[2],p[5]);
>>> +      std::swap(p[3],p[4]);
>>> +    }
>>> +  };
>
> You can wrap the 'Swap_value' class with a function:
>
> template <typename T>
> void
> swap_value(T& value, bool swap)
> {
>   if (swap)
>     swap_value<T, sizeof(T), true>::swap(&value);
> }
>
The reason that I didn't want this to be a function is because if I call 
this in a loop, it will execute a condition every iteration of the loop. 
If it is a template parameter, it might be a little better. What do you 
think?
>>> +
>>> +  // swaps an array of values based on a template param
>>> +  template <typename T>
>>> +  void swap_array(T *d, vsip::impl::Int_type<1>)
>>> +  { swap_value<T,sizeof(T),true>::swap(&(d[0])); }
>>> +  template <typename T>
>>> +  void swap_array(T *d, vsip::impl::Int_type<2>)
>>> +  { swap_value<T,sizeof(T),true>::swap(&(d[0]));
>>> +    swap_value<T,sizeof(T),true>::swap(&(d[1])); }
>>> +  template <typename T>
>>> +  void swap_array(T *d, vsip::impl::Int_type<3>)
>>> +  { swap_value<T,sizeof(T),true>::swap(&(d[0]));
>>> +    swap_value<T,sizeof(T),true>::swap(&(d[1]));
>>> +    swap_value<T,sizeof(T),true>::swap(&(d[2])); }
>
> Is there a reason that swap_array takes the array size as a template 
> parameter?
yes, because I call this function when Dim is a template parameter and I 
cannot iterate over this number.
>
> The pros of passing the size this way are primarily in performance.  
> The above code will force the compiler to inline the individual calls 
> instead of performing a loop.
>
> However, the cons are increased code size (both source code and object 
> code), longer compile times, and limiting the situations where the 
> function can be called.
>
> Can you change swap_array to take the array size as a regular parameter.
>
>>> +
>>> +  // swaps the header of a view
>>> +  template <vsip::dimension_type dim>
>>> +  void swap_header(view_header<dim> &header, uint16_t endian)
>
> Instead of passing 'endian' to each function and having it decode 'MI' 
> vs 'IM' to determine if swapping is necessary, it would be better to 
> have operator>> perform the check and pass a boolean parameter:
>
>     void swap_header(..., bool swap_bytes)
>
> This centralizes the knowledge of how matlab files encode endianness 
> into one place in the code instead of replicating it.  It also makes 
> the function's behavior easier to understand.
Sounds much better.
>
>>> +  {
>
> With the 'swap_value' helper function and the 'swap_bytes' bool 
> parameter, these become:
>
>     swap_value(header.header.type, swap_bytes);
>     swap_value(header.header.size, swap_bytes);
>     ...
>
>>> +    if(endian == ('I' << 8 | 'M') )
>>> +    {
>>> +      // swap all fields
>>> +      swap_value<int32_t,4,true>::swap(&(header.header.type));
>>> +      swap_value<uint32_t,4,true>::swap(&(header.header.size));
>>> +      
>>> swap_value<int32_t,4,true>::swap(&(header.array_flags_header.type));
>>> +      
>>> swap_value<uint32_t,4,true>::swap(&(header.array_flags_header.size));
>>> +      swap_value<int32_t,4,true>::swap(&(header.dim_header.type));
>>> +      swap_value<uint32_t,4,true>::swap(&(header.dim_header.size));
>>> +      
>>> swap_value<int32_t,4,true>::swap(&(header.array_name_header.type));
>>> +      
>>> swap_value<uint32_t,4,true>::swap(&(header.array_name_header.size));
>>> +      swap_array<uint32_t>(header.dim, vsip::impl::Int_type<dim>());
>>> +      swap_array<uint32_t>(header.array_flags, 
>>> vsip::impl::Int_type<2>());
>>> +    }
>>> +  }
>>> +
>>> +  // generic reader that allows us to read a generic type and cast 
>>> to another
>>> +  +  // the read function for real or complex depending of the view 
>>> that was
>>> +  // passed in
>
> What does "generic type" mean in the above comment?
>
> A comment like the following would be more clear:
>
> // Read a N-dimensional matlab XXX.  The value type of the file object
> // is specified by T1 and can be different from the value type of the
> // VSIPL++ view.  For views of complex data, this function is called
> // once for the real subview and once for the imaginary subview.
>
>>> +  template <typename T1,
>>> +        typename ViewT>
>>> +  void read(std::istream& is,ViewT v,uint16_t endian)
>>> +  {
>>> +    vsip::dimension_type const View_dim = ViewT::dim;
>>> +    vsip::Index<View_dim> my_index;
>>> +    vsip::impl::Length<View_dim> v_extent = extent(v);
>>> +    T1 data;
>>> +    typedef typename ViewT::value_type scalar_type;
>>> +    typedef void (*fn_type)(T1 *data);
>>> +    fn_type swap_fn;
>>> +
>>> +    // get num_points
>>> +    vsip::length_type num_points = v.size();
>>> +
>>> +    // figure out if we need to do endian swaps
>>> +    if(endian != ('M' << 8 | 'I'))
>>> +      swap_fn = swap_value<T1,sizeof(T1),true>::swap;
>>> +    else
>>> +      swap_fn = swap_value<T1,sizeof(T1),false>::swap;
>>> +
>>> +    // read all the points
>>> +    for(vsip::index_type i=0;i<num_points;i++) {
>>> +      is.read(reinterpret_cast<char*>(&data),sizeof(data));
>>> +      swap_fn(&data);
>
> With 'swap_value' wrapper, this becomes:
>
>       swap_value(data, swap_bytes);

>
>>> +      put(v,my_index,scalar_type(data));
>>> +
>>> +      // increment index
>>> +      my_index = vsip::impl::next(v_extent,my_index);
>>> +    }
>>> +
>>> +  }
>>> +
>
>
>>> +
>>> +// operator to read view from matlab file
>>> +template <typename T,
>>> +          typename Block0,
>>> +      template <typename,typename> class View>
>>> +inline
>>> +std::istream&
>>> +operator>>(
>>> +  std::istream&                                       is,
>>> +  Matlab_bin_formatter<View<T,Block0> >               mbf)
>>> +{
>>> +  matlab::data_element temp_data_element;
>>> +  matlab::view_header<vsip::impl::Dim_of_view<View>::dim> m_view;
>>> +  typedef typename vsip::impl::Scalar_of<T>::type scalar_type;
>>> +  typedef matlab::Subview_helper<View<T,Block0> > subview;
>>> +  typedef typename subview::realview_type r_v;
>>> +  typedef typename subview::imagview_type i_v;
>>> +  vsip::dimension_type v_dim = vsip::impl::Dim_of_view<View>::dim;
>>> +
>>> +
>>> +  // read header
>>> +  is.read(reinterpret_cast<char*>(&m_view),sizeof(m_view));
>
> After reading the header, this is the place to check 'endian' to 
> determine if byte swapping is necessary:
>
>     bool swap_bytes = (endian != 'M' << 8 | 'I');
>
>>> +
>>> +  // do we need to swap fields?
>
> Since we already know if it is necessary to swap bytes, the comment 
> might be:
>
>     // Swap header fields if necessary.
>
>>> +  matlab::swap_header(m_view,mbf.header.endian);
>>> +
>>> +  // is this complex?
>>> +  if(vsip::impl::Is_complex<T>::value && 
>>> !(m_view.array_flags[0]&(1<<11)))
>>> +    VSIP_IMPL_THROW(std::runtime_error(
>>> +      "Trying to read complex matrix into a real matrix"));
>>> +
>>> +
>>> +  // is this the same class?
>>> +  if(!((m_view.array_flags[0] & 0xff) == +            
>>> (matlab::Matlab_header_traits<sizeof(scalar_type),
>>> +                  std::numeric_limits<scalar_type>::is_signed,
>>> +                  
>>> std::numeric_limits<scalar_type>::is_integer>::class_type)
>>> +        ))
>>> +    VSIP_IMPL_THROW(std::runtime_error(
>>> +      "Trying to read a matrix of a different class"));
>
> The error message should mention "view" instead of "matrix":
>
>     "Trying to read a view of a different class"
>
>>> +
>>> +  // do dimensions agree?
>>> +  if(v_dim == 1) m_view.dim_header.size -= 4; // special case for 
>>> vectors
>>> +  if(v_dim != (m_view.dim_header.size/4))
>>> +    VSIP_IMPL_THROW(std::runtime_error(
>>> +      "Trying to read a matrix of different dimensions"));
>
>     "Trying to read a view with different dimensions"
>
>>> +
>>> +  for(vsip::dimension_type i=0;i<v_dim;i++)
>>> +    if(mbf.view.size(i) != m_view.dim[i])
>>> +      VSIP_IMPL_THROW(std::runtime_error(
>>> +        "Matrix dimensions don't agree"));
>
>     "View dimensions don't agree"
>
>
>



From jules at codesourcery.com  Fri Jun 30 18:27:46 2006
From: jules at codesourcery.com (Jules Bergmann)
Date: Fri, 30 Jun 2006 14:27:46 -0400
Subject: [vsipl++] Matlab  IO
In-Reply-To: <44A1F511.8080201@codesourcery.com>
References: <449AEB35.6030307@codesourcery.com> <449C9851.2020006@codesourcery.com> <44A18961.2060504@codesourcery.com> <44A1F511.8080201@codesourcery.com>
Message-ID: <44A56D22.6020705@codesourcery.com>


>> You can wrap the 'Swap_value' class with a function:
>>
>> template <typename T>
>> void
>> swap_value(T& value, bool swap)
>> {
>>   if (swap)
>>     swap_value<T, sizeof(T), true>::swap(&value);
>> }
>>
> The reason that I didn't want this to be a function is because if I call 
> this in a loop, it will execute a condition every iteration of the loop. 
> If it is a template parameter, it might be a little better. What do you 
> think?

The template parameter version would be faster than the runtime version 
if called directly.  However, since it is called through a function 
pointer, the benefit is somewhat offset.

To move the conditional and function pointer out of the inside loop, you 
can do something like:

	top_level_read()
	{
	  ... read matlab header ...
	
	  bool swap_bytes = (... check endian ...);

	  if (swap_bytes)
	    low_level_read<true>();
	  else
	    low_level_read<false>();
	}

	template <bool SwapBytes>
	low_level_read()
	{
	  ...
	  swap_value<T, sizeof(T), SwapBytes>::swap(&value);
	}

Even in this case you could benefit from a helper function that deduces 
T and calls sizeof():

	template <bool     SwapBytes,
	          typename T>
	void
	swap_value(T& value)
	{
	  swap_value<T, sizeof(T), SwapBytes>::swap(&value);
	}

which you would call as:

	  swap_value<SwapBytes>(value);

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705