SPO600 Inline Assembler Lab

Purpose of this Lab
This lab is designed to explore the use of inline assembler, and its use in open source software.

Lab 6

References

• Inline Assembly Language
• ARM Developer Information Centre
  • ARM Cortex-A Series Programmer’s Guide for ARMv8-A
• The short guide to the ARMv8 instruction set: ARMv8 Instruction Set Overview ("ARM ISA Overview")
• The long guide to the ARMv8 instruction set: ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile ("ARM ARM")

SQDMULH Instruction

Many of the AArch64 "Advanced SIMD" instructions are designed for use with multimedia data. In this example, we will be using the SQDMULH instruction, which is a "Signed Saturating Doubling Multiply returning High Half". Breaking this down:

• As a vector (SIMD) instruction, this operation works on multiple values in parallel. It can operate on 16- or 32-bit values; since we're dealing with 16-bit signed sound samples, we will use 16-bit values.
• "Saturating" means that if the result overflows (or underflows) the maximum (or minimum) values, the result will be the maximum (or minimum) value. This is useful for graphics, where brightening a pixel that is at 90% brightness by an addition 50% should produce a pixel that is at maximum brightness, even though that's not mathematically correct. Likewise, a sound sample that is increased in volume should not increase past the maximum signal limit.
• We're going to use this instruction to multiply sound samples by a volume scaling factor (V). This instruction doubles the result, so that the V factor will effectively be converted from a 16-bit value to a 17-bit value. We can treat this as a fixed-point number with a maximum value of about 1.
• The result of multiplying two 16-bit numbers together is a 32-bit number. In our fixed-point representation, the 32-bit result has sixteen bits to the right of the radix point. Since this instruction takes the "high half" of the result, lowest 16 bits are discarded, keeping only the integer portion of the result -- which is exactly what we need.

Part A - Class Lab

1. There is a version of the volume scaling problem from the Algorithm Selection Lab for AArch64 which incorporates inline assembler in /public/spo600-20181-inline-assembler-lab.tgz on each of the AArch64 SPO600 Servers. Copy, build, and verify the operation of this program on one of those servers.

2. Test the performance of this solution and compare it to your previous solution(s). Adjust the number of samples (in vol.h) to produce a measurable runtime, and adjust your code for comparable test conditions (number of samples, 1 array vs. 2 arrays, and so forth).

3. Find the answers to the questions identified with "Q:" in the comments in the source code.

4. Blog about your results in detail, including your reflections on performing the lab and what you have learned. Do not just blog the answers to the questions -- explain to the reader what you did, and incorporate your answers into your text.

Part B - Individual Task

1. Select one of the following open source packages which is not claimed by another person in the class. Put your name beside it in (parenthesis) to claim it.

• amule
• ardour
• avidemux
• blender
• bunny
• busybox[srpurani]
• chicken
• cln
• coq
• cxxtools
• faad2
• fawkes (amohammadi5)
• gauche
• gmime
• gnash
• gridengine
• groonga
• hoard
• iaxclient
• k9copy (qchen96)
• lame
• libfame
• libgcroots
• libmad
• libmlx4
• lightsparc
• mediatomb
• mjpegtools
• mlt
• mosh (amohammadi5)
• mpich2
• ocaml-zarith
• openblas (jpham)
• opencore-amr
• openser
• par2cmdline
• picprog
• qlandkartegt
• sooperlooper (mgquan)
• traverso (depstein1)

2. Find the assembly-language code in that software, and determine:

• How much assembley-language code is present
• Is the assembly code in its own file (.s or .S) or inline
• Which platform(s) the assembler is used on
• What happens on other platforms
• Why it is there (what it does)
• Your opinion of the value of the assembler code, especially when contrasted with the loss of portability and increase in complexity of the code.

3. Blog your results in detail, including your reflections on doing the lab.