1,885
edits
Changes
no edit summary
* Start blogging about your project
<!--
== Week 10 ==
=== Week 10 - Class I ===
==== Video ====
* Summary Video
=== Week 10 - Class II ===
==== Video ====
* Summary Video
=== Week 10 Deliverables ===
== Week 11 ==
=== Week 11 - Class I ===
==== Video ====
* Summary Video
=== Week 11 - Class II ===
==== Video ====
* Summary Video
=== Week 11 Deliverables ===
== Week 12 ==
=== Week 12 - Class I ===
==== Video ====
* Summary Video
=== Week 12 - Class II ===
* Summary Video
==== Video ====
* [https://web.microsoftstream.com/video/fcc73002-b59c-4bc7-b0e6-c73706b492e8 Summary Video] - Step-by-Step discussion of the minimum requirements for a successful project
==== Minimum Requirements for a Successful Project ====
* Remember: This project is about building a ''tool'' that processes C source code. The tool itself can be in any suitable computer language. It is recommended that you use a language that can manipulate text easily. The tool will receive an input file containing a C function. The tool will output a modified file(s) with ifunc capability for asimd/sve/sve2 computers.
* Requirements for a minimum implementation:
# Find the protype and function name by analyzing the C function.
#* Example name: <code>adjust_channels</code>
#* Example prototype: <code>void adjust_channels(unsigned char *image,int x_size,int y_size,float red_factor,float green_factor,float blue_factor);</code>
#* Hint/suggestion: compiling the function file with the <code>-S</code> option will produce an assembly-language output file. You can parse this file for lines like <code>.type adjust_channels, %function</code> to find the function name(s).
#* Hint/suggestion #2: the <code>makeheaders</code> utility can produce a header file from an C source code input file. It is easier to find the function prototypes in the header file than in the C source file.
# Place the prototype into the output file, adding the ifunc atttribute and resolver name. This produces the indirect function.
#* Example indirect function: <code>__attribute__ (( ifunc("''name_of_resolver_function''") )) void adjust_channels(unsigned char *image,int x_size,int y_size,float red_factor,float green_factor,float blue_factor);</code>
# Repeat these next two steps three times, once for each target (see the table below)
## Place a GCC pragma directive into the output file to select one of the three targets: <code>#pragma GCC target arch="''put the target architecture string here''"</code>
## Paste in the function, changing the function name so that the various versions don't conflict. For example, you could append a suffix identifying the architecture target, changing the function name <code>adjust_channels</code> to something like <code>adjust_channels_sve</code>.
##* Tip: After the last function, add a pragma to switch the compiler back to targeting basic <code>armv8-a</code>
# Add the resolver function, being sure to include the header file <code><nowiki><sys/auxv.h></nowiki></code> so that we can access the auxilliary vector (and therefore the description of available hardware capabilities).
static void (*''name_of_resolver_function''(void)) {
long hwcaps = getauxval(AT_HWCAP);
long hwcaps2 = getauxval(AT_HWCAP2);
printf("\n### Resolver function - selecting the implementation to use for foo()\n");
if (hwcaps2 & HWCAP2_SVE2) {
return adjust_channels_sve2;
} else if (hwcaps & HWCAP_SVE) {
return adjust_channels_sve;
} else {
return adjust_channels_asimd;
}
};
<ol><li value="5"> Build the software using the output file in place of the input file.
<li> Test it thoroughly! Use your tool and compile the output. Look at the final binary to check for asimd/sve/sve2 code, and make sure the program runs in both contexts (run the binary directly to test it in asimd mode, and use the qemu-aarch64 tool to run the binary in sve2 mode).
<li> Write it up in one or more blog posts.
* The mark assigned will depend on:
** The quality of the implementation - For example, does it accept various input files and process them correctly? Are the output files reliably usable? Is the tool user-friendly?
** The amount and quality of the testing - For example, have you demonstrated that the tool works correctly? Can you show the asimd, sve, and sve2 code in the compiled binary?
** The quality of the writing - For example, have you fully explained the code? Have you documented how to use your tool with clear, step-by-step instructions? Is the code provided in a form that makes it easy to test?
** If the basic operation of the program is good, bonus marks may be assigned for additional features and for overcoming the (permitted) limitations. See the project page for details.
</ol>
=== Week 12 Deliverables ===
* Blog about your Project
* Note: Project Stage II is due next Wednesday, December 7, at 12 noon.
-->
<!-- Memory System Design - Paging ; Memory - Cache/Numa ; Memory - Observability, Barriers -->
<!--