<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>I first want to say thank you to Bodo and Clemens for providing me the additional details.</DIV>
<DIV>Since I currently don't have the access to AMD CPUs and AMD/Nividia GPGPU cards, I will try to provide the bindings for Intel MKL first.  Once AMD Fusion chips are available on the market, I can then work on the AMCL-GPU BLAS bindings for these chips if no one else has the time to do it. </DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV> </DIV>
<DIV>Salem</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><BR>--- On <B>Mon, 8/9/10, Clemens Grelck <I><c.grelck@uva.nl></I></B> wrote:<BR></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid"><BR>From: Clemens Grelck <c.grelck@uva.nl><BR>Subject: Re: [sac-user] English Documentation for Calling C from SAC<BR>To: "sac user mailing list" <sac-user@sac-home.org><BR>Cc: "Salem Reyen" <salemreyen@yahoo.com><BR>Date: Monday, August 9, 2010, 6:08 AM<BR><BR>
<DIV class=plainMail>As a short add-on: As Bodo mentioned already, all array-typed values use<BR>call-by-reference (including int[*], etc). In contrast, all scalar values<BR>use call-by-value just as scalars in C.<BR><BR>The refcounting pragma only means that the SAC runtime exposes its internal<BR>state, here the reference counter of a data object, to the external world.<BR>AND, it makes the C code responsible for maintaining the reference counter<BR>appropriately. This requires more insight into how SAC does reference counting.<BR>If you do everything correctly, this gives you considerable power, if not,<BR>you screw up (as always in life ;-) ).<BR><BR>Without the pragma, the SAC runtime does all manipulations of reference counter<BR>states outside the called external function as they would happen by a normal<BR>SAC function.<BR><BR>We're all curious to see your results,<BR>  Clemens<BR><BR>Scholz, Sven-Bodo wrote:<BR>> <BR>> <BR>> On
 07/08/2010 01:56, "Salem Reyen" <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=salemreyen@yahoo.com" ymailto="mailto:salemreyen@yahoo.com">salemreyen@yahoo.com</A>> wrote:<BR>> <BR>>> Thank you so much for clear things up Stephan.  Since I may need to pass large<BR>>> (GB) size matrices, how can I pass the parameters entirely by reference (for<BR>>> saving memory) to a BLAS function?<BR>> <BR>> Yes, you can ! (tm)<BR>> <BR>> Per default, i.e. when you do NOT use a refcounting pragma, you do pass<BR>> arrays per reference into a C function and out as well. For this to be safe<BR>> the following conventions need to be observed by the C function:<BR>> <BR>> 1) arguments (arrays that are passed into the C function) are not modified<BR>> in any form (no overwriting behind pointers and no memory ops such as<BR>> freeing!!)<BR>> 2) return values (arrays that are returned from your C
 function) are freshly<BR>> allocated (no reuse of argument arrays [no aliasing])!<BR>> <BR>> HOWEVER, there is ONE important exception to this:<BR>> <BR>> IFF you use a linksign pragma to map a return position onto the SAME<BR>> argument position you map an argument to<BR>> <BR>> eg   external int[4] foo( int[4] x);<BR>>      #pragma linksign [1,1]<BR>> <BR>> <BR>> (YES you can do this!)<BR>> <BR>> then this expects a function<BR>> <BR>> void foo( int *x);<BR>> <BR>> AND the runtime system of SaC allows you to modify the array behind x in<BR>> place!<BR>> <BR>> The caveat of this is that the runtime system of SaC now ensures that by the<BR>> time foo is called no other part of the program will ever inspect the<BR>> argument again. This may(!) come at the expense of creating a copy!<BR>> <BR>> Example 1:<BR>> <BR>> int main()<BR>>
 {<BR>>   x = [1, 2, 3, 4];<BR>>   val = foo( x);<BR>>   return( val[0] );<BR>> }<BR>> <BR>> Here, no copy of x will be generated.<BR>> <BR>> Example 2:<BR>> <BR>> int main()<BR>> {<BR>>   x = [1, 2, 3, 4];<BR>>   val = foo( x);<BR>>   return( val[0] + bar(x) );<BR>> }<BR>> <BR>> Here, x is copied prior to the call to foo!<BR>> <BR>> So, you only should use this mapping trick if you want to modify only a<BR>> small portion of data!<BR>> <BR>>> Thanks again for the big help,<BR>>><BR>>> Salem<BR>>><BR>>> P.S.  My understanding (and I could be wrong) is that SAC does not support<BR>>> call by reference for calling a SAC function.  Then in actual C translation,<BR>>> can SAC compiler clever enough to pass a read-only parameter by reference?<BR>>
 <BR>> Yes, all arguments are passed by reference. Copies are delayed to the moment<BR>> when existing arrays are to be modified and further references exist<BR>> elsewhere; very much in the same way as described for external functions<BR>> above!<BR>> <BR>> HTH,<BR>>   Bodo<BR>> <BR>> PS: if you create a SaC-binding for BLAS we'd be very interested in adding<BR>> that to the stdlib! :-)<BR>> <BR>>><BR>>> --- On Fri, 8/6/10, Herhut, Stephan <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=s.a.herhut@herts.ac.uk" ymailto="mailto:s.a.herhut@herts.ac.uk">s.a.herhut@herts.ac.uk</A>> wrote:<BR>>>> From: Herhut, Stephan <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=s.a.herhut@herts.ac.uk" ymailto="mailto:s.a.herhut@herts.ac.uk">s.a.herhut@herts.ac.uk</A>><BR>>>> Subject: Re: [sac-user] English Documentation for Calling C from SAC<BR>>>> To: "Salem
 Reyen" <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=salemreyen@yahoo.com" ymailto="mailto:salemreyen@yahoo.com">salemreyen@yahoo.com</A>>, "<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A>"<BR>>>> <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A>><BR>>>> Date: Friday, August 6, 2010, 10:23 AM<BR>>>><BR>>>> Dear Salem,<BR>>>><BR>>>> unfortunately no such documentation exists at the moment. There is a German<BR>>>> masterıs thesis but that is outdated, too.<BR>>>><BR>>>> We have not tried to use a BLAS C implementation in SAC. However, we have<BR>>>> implemented some of the BLAS routines in SAC itself. It would be great to see<BR>>>> how the two
 approaches compare. From our experience, if one compares single<BR>>>> primitives, BLAS C implementations will almost always win as they have been<BR>>>> tuned to the extreme. The power of an optimising compiler like sac2c only<BR>>>> plays out as soon as multiple primitives are called in sequence. Only then<BR>>>> additional optimisation potential arises.<BR>>>><BR>>>> You can find our BLAS implementation in the standard library<BR>>>> (modules/numerical/blas).<BR>>>><BR>>>> Let my try to give you a brief intro into the C interface. This should<BR>>>> suffice<BR>>>> to integrate BLAS. As an example, consider the string module in the standard<BR>>>> library (modules/structures/String.sac). In that file, the SAC function<BR>>>> strtoi<BR>>>> is defined as follows:<BR>>>><BR>>>> external int, string strtoi(string
 S, int BASE);<BR>>>><BR>>>> As the keyword external gives away, the function is not implemented in SAC<BR>>>> but<BR>>>> some other language. The compiler does not actually care what language that<BR>>>> is, as long as it uses C calling conventions. To declare an external<BR>>>> functions, one simply provides its signature prefixed with the keyword<BR>>>> external.<BR>>>> By just using the line above, the SAC compiler will make some assumptions on<BR>>>> how to map the function to an actual C function. Firstly, it will map return<BR>>>> values and arguments from the SAC side to arguments only on the C side. This<BR>>>> is done to map the multiple return values of SAC to the C word. So, for the<BR>>>> above example, the resulting C prototype would be<BR>>>><BR>>>> void strtoi( int *res1, char **res2, char *S, int
 BASE);<BR>>>><BR>>>> As you can see, the return values have been mapped into reference arguments.<BR>>>> Often, this is not desired, like in the example of BLAS where the signatures<BR>>>> are fixed. For those cases, we provide a means to remap SAC results/arguments<BR>>>> to C results/arguments. For the above example, the following pragma is used<BR>>>> in<BR>>>> the standard library:<BR>>>><BR>>>>     #pragma linksign [0,1,2,3]<BR>>>><BR>>>> Pragmas in general directly follow an external function declaration. In this<BR>>>> case, we use the linksign pragma. It maps each result/argument in SAC to the<BR>>>> corresponding C result/arguments by means of a permutation vector. So, to<BR>>>> achieve the desired C signature of strtoi, we want to have the first SAC<BR>>>> result to be mapped to the C result
 and the arguments to be mapped in the<BR>>>> same<BR>>>> order. This is done using the permutation vector [0,1,2,3].  Position zero<BR>>>> thereby represents the C function return value and numbers from one onwards<BR>>>> are the function arguments. Using that vector, we get<BR>>>><BR>>>> int strtoi( char **res1, char *S, int BASE)<BR>>>><BR>>>> which is the standard C signature for that function. As you might guess, SAC<BR>>>> by default uses the permutation vector [1,2,...].<BR>>>><BR>>>> There are some more tuneable settings:<BR>>>><BR>>>>     #pragma linkname " SACstrtoi"<BR>>>><BR>>>> The linkname pragma allows to use a different C function name. Using the<BR>>>> above<BR>>>> pragma, we would get<BR>>>><BR>>>> int SACstrtoi( char **res1, char *S, int
 BASE);<BR>>>><BR>>>> Further two pragmas handle linking:<BR>>>><BR>>>>     #pragma linkobj "src/String/strtoi.o"<BR>>>><BR>>>> would instruct the compiler to link the given file whenever the function is<BR>>>> required in a program. Similarly<BR>>>><BR>>>>     #pragma linkobj "mylib"<BR>>>><BR>>>> would make the compiler link the final executable against the specified<BR>>>> library. The library is looked for in the search path configured in the<BR>>>> sac2crc resource file. The default paths for system wide libraries are<BR>>>> preconfigured. By editing or creating a .sac2crc file in your home directory<BR>>>> and adding the following lines<BR>>>><BR>>>> target default:<BR>>>> EXTLIBPATH       :=
 ³path1:path2:pathn²<BR>>>><BR>>>> you can add additional paths to the search. A description of all valid field<BR>>>> in that file can be found in its master copy in the setup subdirectory of the<BR>>>> sac2c compiler.<BR>>>><BR>>>> Lastly, there is a the<BR>>>><BR>>>> #pragma refcounting [0,1,2]<BR>>>><BR>>>> pragma. This configures whether parameters are passed by value or reference.<BR>>>> Per default, all parameters are passed by value and thus are immutable. If<BR>>>> you<BR>>>> want to modify a parameter, you have to use a slightly more complex calling<BR>>>> convention. I will cover that subject as demand arises.<BR>>>><BR>>>> I hope this suffices to get you started. If you have any further questions,<BR>>>> please feel free to reply to this list. Please use the list instead of<BR>>>>
 contacting me directly as this will increase the audience and ensure a timely<BR>>>> reply<BR>>>><BR>>>> Regards<BR>>>>   Stephan<BR>>>><BR>>>> On 05/08/2010 04:24, "Salem Reyen" <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=salemreyen@yahoo.com" ymailto="mailto:salemreyen@yahoo.com">salemreyen@yahoo.com</A>> wrote:<BR>>>><BR>>>>> Hi,<BR>>>>><BR>>>>>   Is there any documentation (in English) about how to call C functions from<BR>>>>> a SAC Module?  More importantly, has anyone successfully tried to call<BR>>>>> BLAS/LAPACK (eg, Intel MKL or AMD AML) from SAC?  Any help will be greatly<BR>>>>> appreciated.<BR>>>>><BR>>>>> Salem<BR>>>>><BR>>>> --<BR>>>> Stephan Herhut<BR>>>> Centre for Computer Science and
 Informatics Research<BR>>>> Science and Technology Research Institute<BR>>>> University of Hertfordshire<BR>>>><BR>> <BR>> _______________________________________________<BR>> sac-user mailing list<BR>> <A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A><BR>> <A href="http://lists.sac-home.org/mailman/listinfo.cgi/sac-user" target=_blank>http://lists.sac-home.org/mailman/listinfo.cgi/sac-user</A><BR><BR>-- <BR>----------------------------------------------------------------------<BR>Dr Clemens Grelck                                     Science Park 107<BR>Universitair Docent                                  1098 XG Amsterdam<BR>   
                                                           Nederland<BR>Universiteit van Amsterdam<BR>Instituut voor Informatica                       T +31 (0) 20 525 7578<BR>                                                  F +31 (0) 20 525 7419<BR>Office F2.46                                www.science.uva.nl/~grelck<BR>----------------------------------------------------------------------<BR><BR></DIV></BLOCKQUOTE></td></tr></table><br>