I have a user defined type, that contains a pointer to another user defined type, which contains an array.
In the older version of the compiler (pre-ASSOCIATE) I use a pointer to an array => firstObject%secondObject%array
In an effort to reduce access time. The older code, while faster, required copying the array descriptor into the pointer (and making an alias in the process).
With the newer compiler I experimented with using ASSOCIATE under an assumption that the compiler could optimize out the array descriptor copy by effectively constructing a reference to the outlaying array descriptor, thus saving the array descriptor copy time. This is not the case:
;;; ASSOCIATE(rBMS => pFiniteSolution%rBMS, & vmovups xmm0, XMMWORD PTR [3800+rbx] ;118.5 vmovups XMMWORD PTR [rbp], xmm0 ;118.5 vmovups xmm1, XMMWORD PTR [3816+rbx] ;118.5 vmovups XMMWORD PTR [16+rbp], xmm1 ;118.5 vmovups xmm2, XMMWORD PTR [3832+rbx] ;118.5 vmovups XMMWORD PTR [32+rbp], xmm2 ;118.5 vmovups xmm3, XMMWORD PTR [3848+rbx] ;118.5 vmovups XMMWORD PTR [48+rbp], xmm3 ;118.5 mov rax, QWORD PTR [3864+rbx] ;118.5 mov QWORD PTR [64+rbp], rax ;118.5
The first level of the indirection was performed earlier.
The above code potentially be replace by an
lea...
mov ..
or
mov...
lea...
mov...
to effectively place the address (reference) of the array descriptor into a register or into a stack temporary.
In the above case, the array has a few 1000's of cells so the extra overhead is not all that large. When the arrays are smaller, then the overhead becomes larger proportionally.
In the process of setting up the experiment of testing ASSOCIATE I discovered an annoying side effect.
My code used to use the "." member variable separator as opposed to the official "%" separator:
Foo.bar.nada
as opposed to
Foo%bar%nada
As it is easier to syntactically evaluate the reference.
When a source file uses ASSOCIATE, the alternate "." separator is disabled, even for variables not involved with the ASSOCIATE.
In order to perform the test, I had to spend several hours changing the .'s to %'s being careful not to trash the IF statements.
Jim Dempsey