Various issues encountered while modifying the Linpack source program.

Where is the main function? The Makfile file is not particularly familiar with the code Publisher to write the makefile file is very layered, very nested, let people find it is time-consuming, just beginning to see the complex makefile file a face confused force. It may be more convenient to look for it, however, the executable file generated in the HPL in Linpack is XPHL, not to mention the same name. c files are not, as a habit to programming in the upper-level language, accustomed to using the IDE's older generation C # yards, C Development under Linux lacks similar project management tools and is not adaptable.
Return to the header, from the makefile file, found that the HPL directory has two makefile files, one is Make.top, the other is make.test, that is, we previously edited the arch schema for the test of the corresponding file. of which in the former include the latter, so the variables defined in the latter are also visible in the former.

In makefile, you specify which makefile file the Make command executes by MAKE–F.

Look, you see, this is make.top.
Overall look is make, makefile->make.top->make.test
This set of, you can only feel: well ... The logical hierarchy is strong,
The Makefile.test file defines some variables that will be used later: such as the target schema name:

Various paths related to HPL:
Related Paths for MPI:
Path to the math library Blas:
The path to the compiler:

2. The command of make is: Make Arch=test
The arch=test here actually assigns the variable arch to test, which works in makefile because the makefile file is useful for this arch variable.

The install here relies on the startup refresh build three item.
And startup is generated by subsequent commands. The make–f command specifies that the execution is in the Make.top file.
Startup_dir item, and the parameter entry

Pass the value of arch to arch in Make.top then we're going to go to make.top.
Items, as follows:

Creates the associated folder path, including creating the test directory under include, creating the Lib directory and creating the test directory under the Lib directory, creating the bin directory, and creating the test directory in the bin directory.
Next is

At first I did not understand what the leaf meant, thought it was make related orders or what, stare not found, in the Make.top file behind the discovery
It dawned on the fact that the leaf here is similar to the pseudo-target of clean, such as make cleaning, which cleans the relevant files, and Make–leaf performs the related command operations defined under the leaf.
All that's behind is just an assignment statement for the variable. Under File path, create the test folder under this path.

Transfer to src/auxil/test/Path
Ln_s is assigned a value of ln–s in Make.test the command creates a link for a file.
So the hpl/make.test file is about to create a link file to the current path, that is, src/auxil/test/make.inc
The following analysis is similar to the above.
3.


These two refresh files are performed by copying work. As you can see, the author separates the functional code from the engineering code. is a structured, hierarchical, modular thinking embodies the incisively and vividly, the soft worker really is very nice.
And we usually do this work after the completion of code development, and finally found that sometimes the code to write the relevance of the coupling is very strong, like a group of paste, has been quite helpless.
4. The build process

Go to the corresponding folder path, perform their own make, generate the corresponding target file, ultimately to generate a library file LIBHPL.A how to achieve it. Looking for Ah, not a moment to see, so look at each makefile file under the makes file, in

Found in:
We know that the last executable that was generated was named XPHL, and now the word finally appears. , there was no good excitement. Looking for so long time, I only think it is more miserable, dumass.
Now look at how it's generated, depending on the dependencies, look at this

The variable linker,linkflags here can be found in the make.test.
This instruction executes a link that links the two together to produce the final output file, $HPL _pteobj defined in this makefile, namely:

So what's the $hpl_libs in the back? It is assigned a value in the Make.test file.
We can see that it consists of three items,
Hpllib is actually a HPL library file.

Lalib is actually a gotoblas library file.

Mpilib is actually an MPI library file, which is used by Openmpi.
Gotoblas and MPI libraries are generated at the time of their compilation, so how does the HPL library build at compile time? Currently we do not see its build process.
But we already know how XHPL is generated, and it's a little bit comforting. Then find out how the legendary LIBHPL.A is generated.
Look at the other makefile files under the makes folder, such as this Make.blas file, which will be found in this section:

The variable hpl_blaobj refers to the target file, as shown in the figure above, the variable archiver archiver arflags and $hpllib are assigned in the Make.test file.

As you can see, the command to execute is actually: ar R (libdir)/LIBHPL.A (libdir)/LIBHPL.A (hpl_blaobj)
What is AR command, and what does the back R mean?
See also: http://blog.csdn.net/xljiulong/article/details/7082960

Now that we know that AR is a command to create a library, r means inserting a module into the library, that is, inserting the latter hpl_dcopy.o, HPL_DAXPY.O, HPL_DSCAL.O, etc. as modules into the LIBHPL.A library file.
As a result, if you have similar passages in these files,
The corresponding. o files that are generated are also inserted into the LIBHPL.A library file, step-by-step, and gradually generate the complete LIBHPL.A file, the code we see earlier is modular, either under SRC or testing, When compiling the. o files of the respective modules in the makefile of their respective folders, the AR command is used to insert the parameter option R into the LIBHPL.A library.

Said before, see the XHPL typeface, then follow it to find our main function, first find the corresponding makefile file,/home/zgz/sourcecode/linpack/hpl/testing/ptest/ The Make.ptest file under test.

You can see that when linking, in addition to the library files, there are some target files, corresponding to the purple section.
So where is the main function? Open the corresponding. c file to see it. Have you ever felt even a trembling soul?
Uh... In fact, it is really in the hpl_pddriver.c ...

In addition, under the Comm folder, there are

Under the Grid folder path, there are

As you can see, these two files are related to the definition and implementation of MPI communication, so it is important to focus on modifying the program.

Murphy's Law, it's possible to make a mistake.
Things will take longer than you planned.
This is a small step in code modification, but not a big step in the paper, do not take a heavy task, do not TM ink.