[sac-user] sac-visualization tool

[Sunita Chandrasekaran]

and this:
I am really confused sorting these declarations out...i was looking at
sudoku.sac but I am still wondering how to go about declaration multiple
variables

int main(int argc, char *argv[]);

int msap (int **sequences, int *lengths, int *order, int first, int last,
int longest,
          int matrix[max_unique_elements][max_unique_elements],
          int gapo_d, int gapx_d, int matave, int **scores);


On Thu, Jun 12, 2008 at 5:12 PM, Sunita Chandrasekaran <sunisg123 at gmail.com>
wrote:

> how would you handle  c pointers in sac?
>
> for eg (int **sequences, int *lengths, int *order )
>
>
> On Thu, Jun 12, 2008 at 10:21 AM, Sunita Chandrasekaran <
> sunisg123 at gmail.com> wrote:
>
>> Excellent Prof Scholz.
>> Thanks to you for the explanation, yes am getting a hang of what sac can
>> do. I think I will do some more coding myself to figure out what exactly is
>> happening so that I can match that with these outputs.
>>
>> Something that I would definitely mention, is I am really v happy the way
>> the compiler got installed, the installation just didn't break and hardly
>> does this happen while installing a compiler or doing some
>> cross-compilation.
>>
>> The compiler structure is well handled. Appreciate the sac team for this
>> commendable effort taken.
>>
>> On Wed, Jun 11, 2008 at 8:09 PM, Sven-Bodo Scholz <S.Scholz at herts.ac.uk>
>> wrote:
>>
>>> On Wed, Jun 11, 2008 at 03:32:39PM +0800, Sunita Chandrasekaran wrote:
>>> > Hi
>>> >
>>> > Does this sac2c compiler come with any graphic analyzer tool?
>>> > How do you view the graphs or the optimization effects? vcg?
>>>
>>> Hi Sunita,
>>>
>>> there are 2 things you might want to visualize: a) programs
>>> b) data (i.e. arrays)
>>>
>>> For the latter, we use off-the-shelve tools that exist as C libraries
>>> such as SDL or DISLIN.
>>>
>>> However, I assume that you are interested in the former since you
>>> mentioned vcg. AFAIK, there exists no graphical tol to visualise SaC
>>> programs. BUT, we have built-in support for printing optimised programs
>>> as SaC code itself. if you use 'sac2c -h' you will get lots of possible
>>> compiler flags include the BREAK-options -b<xyz>.
>>> Be aware though that the further "down" in the compilation process that
>>> you break the more difficult to relate to the original program the code
>>> becomes.
>>>
>>> Here a quick example to get started:
>>>
>>> Let's look at the following program:
>>>
>>>
>>> --------------------------------------------------------------------------------
>>> use Array: all;
>>>
>>> int main()
>>> {
>>>  a = 0;
>>>
>>>  for( i=0; i<10; i++) {
>>>    a += i;
>>>  }
>>>  return( a);
>>> }
>>>
>>> --------------------------------------------------------------------------------
>>>
>>> sac2c -b3 sunita.sac gives
>>>
>>>
>>> --------------------------------------------------------------------------------
>>> [.... lots of "gibberish"....]
>>> /*
>>>  *  function definitions (FUNDEFS)
>>>  */
>>>
>>> int _MAIN::main()
>>> /*
>>>  *  main ::  ---
>>>  */
>>> {
>>>  a = 0;
>>>  i = 0;
>>>  while (i Array::< 10)
>>>  {
>>>    a = Array::+( a, i);
>>>    i = Array::+( i, 1);
>>>  }
>>>  return( a);
>>> }
>>>
>>> --------------------------------------------------------------------------------
>>>
>>> sac2c -b6 sunita.sac gives
>>>
>>>
>>> --------------------------------------------------------------------------------
>>> [.... lots of "gibberish"....]
>>> /*
>>>  *  function definitions (FUNDEFS)
>>>  */
>>>
>>> /* Loop function */
>>> int _MAIN::_dup_5_main__Loop_0( int a, int i)
>>> /*
>>>  *  _dup_5_main__Loop_0 ::  ---
>>>  */
>>> {
>>>  int a__SSA0_3;
>>>  int a__SSA0_2;
>>>  int i__SSA0_1;
>>>  int a__SSA0_1;
>>>  int{1} _flat_2;
>>>  int{10} _flat_4;
>>>  bool _flat_3;
>>>
>>>  a__SSA0_1 = wrapper:Array::+( a, i);
>>>  _flat_2 = 1;
>>>  i__SSA0_1 = wrapper:Array::+( i, _flat_2);
>>>  _flat_4 = 10;
>>>  _flat_3 = wrapper:Array::<( i__SSA0_1, _flat_4);
>>>  if (_flat_3)
>>>  {
>>>    a__SSA0_2 = _MAIN::_dup_5_main__Loop_0( a__SSA0_1, i__SSA0_1);
>>>  }
>>>  else
>>>  {
>>>    /* empty */
>>>  }
>>>  a__SSA0_3 = ( _flat_3 ? a__SSA0_2 : a__SSA0_1 );
>>>  return( a__SSA0_3);
>>> }
>>>
>>> /* Cond function */
>>> int _MAIN::main__Cond_1( int{0} a, int{0} i, bool _flat_0)
>>> /*
>>>  *  main__Cond_1 ::  ---
>>>  */
>>> {
>>>  int a__SSA0_2;
>>>  int a__SSA0_1;
>>>
>>>  if (_flat_0)
>>>  {
>>>    a__SSA0_1 = _MAIN::_dup_5_main__Loop_0( a, i);
>>>  }
>>>  else
>>>  {
>>>    /* empty */
>>>  }
>>>  a__SSA0_2 = ( _flat_0 ? a__SSA0_1 : a );
>>>  return( a__SSA0_2);
>>> }
>>>
>>> int _MAIN::main()
>>> /*
>>>  *  main ::  ---
>>>  */
>>> {
>>>  int a__SSA0_2;
>>>  int a__SSA0_1;
>>>  bool _flat_0;
>>>  int{10} _flat_1;
>>>  int{0} i;
>>>  int{0} a;
>>>
>>>  a = 0;
>>>  i = 0;
>>>  _flat_1 = 10;
>>>  _flat_0 = wrapper:Array::<( i, _flat_1);
>>>  a__SSA0_1 = _MAIN::main__Cond_1( a, i, _flat_0);
>>>  a__SSA0_2 = _type_conv_( int, a__SSA0_1);
>>>  return( a__SSA0_2);
>>> }
>>>
>>> --------------------------------------------------------------------------------
>>>
>>> Here you can see that our compiler has transformed the loop into a tail
>>> recursive function called _MAIN::_dup_5_main__Loop_0. You can also see
>>> what the type inference has found out.
>>> Notice here as well that, on this level, we may have things that are
>>> exceed the set of user-level SaC. An example are types of the form
>>> int{0} a which indicates that a has the value 0!
>>>
>>> If we preceed and let the optimiser do its job, i.e.
>>> sac2c -b11 sunita.sac, we obtain:
>>>
>>>
>>> --------------------------------------------------------------------------------
>>> [ I am picking the relevant parts here :-) ]
>>>
>>> int _MAIN::main()
>>> /*
>>>  *  main ::  ---
>>>  */
>>> {
>>>  int a__SSA0_1;
>>>  int{0} a;
>>>
>>>  a = 0;
>>>  a__SSA0_1 = _MAIN::_dup_279__main__Loop_0( a, a);
>>>  return( a__SSA0_1);
>>> }
>>>
>>> int _MAIN::_dup_279__main__Loop_0( int a, int i)
>>> /*
>>>  *  _dup_279__main__Loop_0 ::  ---
>>>  */
>>> {
>>>  int _pinl_19__flat_69;
>>>  int _pinl_20__flat_69;
>>>  bool _pinl_21__flat_42;
>>>  int a__SSA0_3;
>>>  int a__SSA0_2;
>>>
>>>  _pinl_19__flat_69 = _add_SxS_( a, i);
>>>  _pinl_20__flat_69 = _add_SxS_( i, 1);
>>>  _pinl_21__flat_42 = _lt_SxS_( _pinl_20__flat_69, 10);
>>>  if (_pinl_21__flat_42)
>>>  {
>>>    a__SSA0_2 = _MAIN::_dup_279__main__Loop_0( _pinl_19__flat_69,
>>> _pinl_20__flat_69);
>>>  }
>>>  else
>>>  {
>>>    /* empty */
>>>  }
>>>  a__SSA0_3 = ( _pinl_21__flat_42 ? a__SSA0_2 : _pinl_19__flat_69 );
>>>  return( a__SSA0_3);
>>> }
>>>
>>>
>>> --------------------------------------------------------------------------------
>>> Usually, you do NOT want to see any code thereafter because our C-code
>>> generator is rather generic and therefore the intermediate code becomes
>>> ebven less readable to the "untrained eye" ;-)
>>>
>>> If you want to tweak the optimisation you could, for example, increase
>>> the loop unrolling threshold by using
>>>
>>> sac2c -maxlur 10 -b11 sunita.sac
>>>
>>> In which case you obtain:
>>>
>>> --------------------------------------------------------------------------------
>>> [...gibberish...]
>>>
>>> int{45} _MAIN::main()
>>> /*
>>>  *  main ::  ---
>>>  */
>>> {
>>>  int{45} a__SSA0_1;
>>>
>>>  a__SSA0_1 = 45;
>>>  return( a__SSA0_1);
>>> }
>>>
>>> --------------------------------------------------------------------------------
>>>
>>> ' hope that you were after some way to get this kind of information
>>> about about the optimisation results....
>>>
>>> Cheers,
>>>    Bodo
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sac-home.org/pipermail/sac-user/attachments/20080612/ca980be6/attachment-0002.html