integers are 8 bytes (64 bits). This version allows the user access to
larger memory sizes and helps when porting legacy Cray codes. It can be
loaded by using either the ----llllssssccccssss____iiii8888 or ----llllssssccccssss____iiii8888____mmmmpppp link option. Note
that any program may use only one of the two versions; 4-byte integer and
8-byte integer library calls cannot be mixed.
C/C++ function prototypes for the signal processing routines are provided
in <<<<ssssccccssssllll____fffffffftttt....hhhh>>>>, when using the default 4-byte integers, and
<<<<ssssccccssssllll____fffffffftttt____iiii8888....hhhh>>>>, when using 8-byte integers. These header files define
the complex types ssssccccssssllll____ccccoooommmmpppplllleeeexxxx and ssssccccssssllll____zzzzoooommmmpppplllleeeexxxx, which are used in the
prototypes. Alternatively, C++ programs may declare arguments using the
types ccccoooommmmpppplllleeeexxxx<<<<ffffllllooooaaaatttt>>>> and ccccoooommmmpppplllleeeexxxx<<<<ddddoooouuuubbbblllleeee>>>> from the standard template
library. But if these types are used, <<<<ccccoooommmmpppplllleeeexxxx....hhhh>>>> must be included before
<<<<ssssccccssssllll____fffffffftttt....hhhh>>>> (or <<<<ssssccccssssllll____fffffffftttt____iiii8888....hhhh>>>>). Note, though, that both complex types
are equivalent: they simply represent (real, imaginary) pairs of floating
point numbers stored contiguously in memory. With the proper casts, you
can simply pass arrays of floating point data to the routines where
complex arguments are expected.
Casts, however, can be avoided. The header files <<<<ssssccccssssllll____fffffffftttt....hhhh>>>> and
<<<<ssssccccssssllll____fffffffftttt____iiii8888....hhhh>>>> directly support the use of user-defined complex types or
disabling prototype checking for complex arguments completely. By
defining the symbol SSSSCCCCSSSSLLLL____VVVVOOOOIIIIDDDD____AAAARRRRGGGGSSSS before including <<<<ssssccccssssllll____fffffffftttt....hhhh>>>> or
<<<<ssssccccssssllll____fffffffftttt____iiii8888....hhhh>>>> all complex arguments will be prototyped as vvvvooooiiiidddd ****. To
define the symbol SSSSCCCCSSSSLLLL____VVVVOOOOIIIIDDDD____AAAARRRRGGGGSSSS at compile time use the ----DDDD compiler
option (i.e., ----DDDDSSSSCCCCSSSSLLLL____VVVVOOOOIIIIDDDD____AAAARRRRGGGGSSSS) or use an explicit ####ddddeeeeffffiiiinnnneeee SSSSCCCCSSSSLLLL____VVVVOOOOIIIIDDDD____AAAARRRRGGGGSSSS
in the source code. This allows the use of any complex data structure
without warnings from the compiler, provided the structure is as
described above; that is:
1. The real and imaginary components must be contiguous in memory.
2. Sequential array elements must also be contiguous in memory.
While this allows the use of non-standard complex types without
generating compiler warnings, it has the disadvantage that the compiler
will not catch type mismatches.
Strong type checking can be enabled employing user-defined complex types
instead of SCSL's standard complex types. To do this, define
SSSSCCCCSSSSLLLL____UUUUSSSSEEEERRRR____CCCCOOOOMMMMPPPPLLLLEEEEXXXX____TTTT====_m_y__c_o_m_p_l_e_x and SSSSCCCCSSSSLLLL____UUUUSSSSEEEERRRR____ZZZZOOOOMMMMPPPPLLLLEEEEXXXX____TTTT====_m_y__z_o_m_p_l_e_x, where
_m_y__c_o_m_p_l_e_x and _m_y__z_o_m_p_l_e_x are the names of user-defined complex types.
These complex types must be defined before including the <<<<ssssccccssssllll____fffffffftttt....hhhh>>>> (or
In the Origin series implementation, _i_s_y_s((((0000))))====0000 and _i_s_y_s((((0000))))=1 are
supported. In SCSL versions prior to 1.3, only _i_s_y_s((((0000))))====0000 was allowed.
For _i_s_y_s((((0000))))====0000, _N_F====33330000 and _N_F_R====11115555, and for _i_s_y_s((((0000))))====1111, _N_F=_N_F_R=222255556666. The _N_F(_R)
words of storage in the table array contain a factorization of the length
of the transform.
The smaller values of _N_F and _N_F_R for _i_s_y_s((((0000))))====0000 are historical. They are
too small to store all the required factors for the highest performing
FFT, so when _i_s_y_s((((0000))))====0000, extra space is allocated when the table array is
initialized. To avoid memory leaks, this extra space must be deallocated
when the table array is no longer needed. The routines CCCCCCCCFFFFFFFFTTTTFFFF, CCCCCCCCFFFFFFFFTTTTMMMMFFFF,
etc., are used to release this memory. Due to the potential for memory
leaks, the use of _i_s_y_s((((0000))))====0000 should be avoided.
For _i_s_y_s((((0000))))====1111, the values of _N_F and _N_F_R are large enough so that no extra
memory needs to be allocated, and there is no need to call CCCCCCCCFFFFFFFFTTTTFFFF, etc.
to release memory. (If called, these routines will do nothing.)
NOTE: _i_s_y_s((((0000)))) ==== 1111 means that _i_s_y_s is an integer array with two elements.
The second element, _i_s_y_s((((1111)))), will not be accessed.
Finally, in addition to the _w_o_r_k array, the FFT routines also dynamically
allocate scratch space from the stack. The amount of space allocated can
be slightly bigger than the size of the largest processor cache. For
single processor runs, the default stack size is large enough that these
allocations generally cause no problems. But for parallel runs, you need
to ensure that the stack size of slave threads is big enough to hold this
scratch space. Failure to reserve sufficient stack space will cause
programs to dump core due to stack overflows. The stack size of MP
library slave threads is controlled via the MMMMPPPP____SSSSLLLLAAAAVVVVEEEE____SSSSTTTTAAAACCCCKKKKSSSSIIIIZZZZEEEE
environment variable or the mmmmpppp____sssseeeetttt____ssssllllaaaavvvveeee____ssssttttaaaacccckkkkssssiiiizzzzeeee(((()))) library routine. See
the mmmmpppp(3C), mmmmpppp(3F) and ppppeeee____eeeennnnvvvviiiirrrroooonnnn(5) reference pages for more information
on controlling the slave stack size. For pthreads applications, the
thread's stack size is specified as one of many creation attributes
provided in the pthread_attr_t argument to pppptttthhhhrrrreeeeaaaadddd____ccccrrrreeeeaaaatttteeee(3P). The
stacksize attribute should be set explicitly to a non-default value using
the pppptttthhhhrrrreeeeaaaadddd____aaaattttttttrrrr____sssseeeettttssssttttaaaacccckkkkssssiiiizzzzeeee(3P) call, described in the
pppptttthhhhrrrreeeeaaaadddd____aaaattttttttrrrr____iiiinnnniiiitttt(3P) man page.
