Monday 26 February 2018

Inline Assembler

This blog will guide you through inline assembler in AArch64 but first let me introduce you to What inline assembler is? In workstation programming, a inline constructing agent is An characteristic about a portion compilers that permits low-level code composed in low level computing construct will be installed inside a program, "around code that generally need been aggregated from a higher-level dialect for example, such that c alternately ada. In simple words, inline assembler allows us to apply assembly language code into our high-level code (such as C) and have it work more efficiently, due to the nature of assembly language.

Firstly we will test the performance(build ,compile and run) of this program below
//this file is vol_simd.c
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include "vol.h"

int main() {

        int16_t*                in;             // input array
        int16_t*                limit;          // end of input array
        int16_t*                out;            // output array

        // these variables will be used in our assembler code, so we're going
        // to hand-allocate which register they are placed in
        // Q: what is an alternate approach?
        register int16_t*       in_cursor       asm("r20");     // input cursor
        register int16_t*       out_cursor      asm("r21");     // output cursor
        register int16_t        vol_int         asm("r22");     // volume as int16_t

        int                     x;              // array interator
        int                     ttl;            // array total

        in=(int16_t*) calloc(SAMPLES, sizeof(int16_t));
        out=(int16_t*) calloc(SAMPLES, sizeof(int16_t));

        srand(-1);
        printf("Generating sample data.\n");
        for (x = 0; x < SAMPLES; x++) {
                in[x] = (rand()%65536)-32768;
        }

// --------------------------------------------------------------------

        in_cursor = in;
        out_cursor = out;
        limit = in + SAMPLES ;

        // set vol_int to fixed-point representation of 0.75
        // Q: should we use 32767 or 32768 in next line? why?
        vol_int = (int16_t) (0.75 * 32767.0);

        printf("Scaling samples.\n");

        // Q: what does it mean to "duplicate" values in the next line?
        __asm__ ("dup v1.8h,%w0"::"r"(vol_int)); // duplicate vol_int into v1.8h

        while ( in_cursor < limit ) {
                __asm__ (
                        "ldr q0, [%[in]],#16            \n\t"
                        // load eight samples into q0 (v0.8h)
                        // from in_cursor, and post-increment
                        // in_cursor by 16 bytes

                        "sqdmulh v0.8h, v0.8h, v1.8h    \n\t"
                        // multiply each lane in v0 by v1*2
                        // saturate results
                        // store upper 16 bits of results into v0

                        "str q0, [%[out]],#16           \n\t"
                        // store eight samples to out_cursor
                        // post-increment out_cursor by 16 bytes

                        // Q: what happens if we remove the following
                        // two lines? Why?
                        : [in]"+r"(in_cursor)
                        : "0"(in_cursor),[out]"r"(out_cursor)
                        );
        }

// --------------------------------------------------------------------

        printf("Summing samples.\n");
        for (x = 0; x < SAMPLES; x++) {
                ttl=(ttl+out[x])%1000;
        }

        // Q: are the results usable? are they correct?
        printf("Result: %d\n", ttl);

        return 0;

}

#define SAMPLES 500000 in vol.h this is the sample size we are using currently to test above code
Compiling it with gcc vol_simd.c and running it with ./a.out we will get output

Generating sample data.
Scaling samples.
Summing samples.
Result: -894

real    0m0.033s
user    0m0.033s
sys     0m0.000s

Now changing sample size in vol.h from 500000 to 2500000 we will get

Generating sample data.
Scaling samples.
Summing samples.
Result: 249

real    0m0.145s
user    0m0.125s
sys     0m0.019s

Processing times without any banner appears to make code quicker to run than those of inline constructing agent code. Gathering for an -O3 banner produces generally comparable run-times for both projects. I find it because of the motivation behind a -O3 makes a run-time that is not exclusively "code-dependent" inasmuch as no flags will depend wholly on the caliber for code (and asm purpose coded) done it.

Q: what is an alternate approach?
An alternate approach would be not to assign registers for the variables in_cursor, out_cursor. By implementing this approach  will result in the allocating registers on its own.

Q: should we use 32767 or 32768 in next line? why?
32767, for the reason it is the maximum allowed value of data type int16_t.

Q: what does it mean to "duplicate" values here?
copying what's in register 22 vol_int into vector v1.8h this is what duplicate values means

Q: what happens if we remove the following lines? Why?
Those accompanying lines are answerable for relegating comparing qualities under those code's variables for scaling purpose. Removing them results in
 vol_simd.c: In function ‘int main()’:
vol_simd.c:69:5: error: undefined named operand ‘in’
    );
     ^
vol_simd.c:69:5: error: undefined named operand ‘out.

Q: are the results usable? are they correct?
Yes they are correct as we change the scaling value our main output is changing too

Part 2
I have picked Busy Box for this particular section
A bit of background for BusyBox from the official website:

"BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system."

How much assembley-language code is present?
To see I used egrep command and found some of the assembly language code in the package. Code I found was based on networking and include directory.

Which platform it is used on?
Supported by gcc but cannot support arm , x86_64

Why it is there (what it does)?
The functions can be found in "networking/tls_pstm_montgomery_reduce.c". The file holds a handful from claiming inline constructing agent works whose motivation may be on improve operations inside different platforms/architectures.

What happens on other platforms?
the directory networking checks  if the software runs properly on all platforms using its own script based on inline assembler code

Your opinion of the value of the assembler code VS the loss of portability/increase in complexity of the code.

Similarly as a wide margin Similarly on my observation see, constructing agent code might a chance to be greatly effective for ventures Anyway could a chance to be exact drawn out Furthermore emptying. Those many-sided nature for constructing agent code and need to conform it for every each construction modeling make it impeding to huge scale ventures Furthermore make standard assignments for example, such that debugging alternately support a chance to be exact modest What's more taxis. However, the quality about constructing agent code could doubtlessly make necessary for ventures for example, "BusyBox" that need aid striving to be all-enveloping operations faster, additional proficient and general preferred.

Wednesday 21 February 2018

Algorithm Selection using Assembly Language

This blog is based on selection of two algorithms for adjusting the volume of PCM audio samples based on bench-marking of two possible approaches. Digital sound is typically represented, uncompressed, as signed 16-bit integer signal samples.

There is one stream of samples for the left and right stereo channels, at typical sample rates of 44.1 or 48 thousand samples per second, for a total of 88.2 or 96 thousand samples per second. Since there are 16 bits (2 bytes) per sample, the data rate is 88.2 * 1000 * 2 = 176,400 bytes/second (~172 KiB/sec) or 96 * 1000 * 2 = 192,000 bytes/second (~187.5 KiB/sec).
To change the volume of sound, each sample can be scaled by a volume factor, in the range of 0.00 (silence) to 1.00 (full volume).
On a mobile device, the amount of processing required to scale sound will affect battery life.

Our first step would be to start with ARMv8 AARch64 SPO600 Server. Here we have a file vol1.c and vol.h. vol.h has define 500000 Samples in it while vol1.c creates 500,000 random "sound samples" in an input array (the number of samples is set in the vol.h file). Scales those samples by the volume factor 0.75 and stores them in an output array.Sums the output array and prints the sum.

Our method 1 would be simple to test the script below simply by multiplying each sample by the floating point volume factor 0.75 to get the scaled sample value

#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <time.h>
#include "vol.h"

// Function to scale a sound sample using a volume_factor
// in the range of 0.00 to 1.00.
static inline int16_t scale_sample(int16_t sample, float volume_factor) {
        return (int16_t) (volume_factor * (float) sample);
}

int main() {

        // Allocate memory for large in and out arrays
        int16_t*        in;
        int16_t*        out;
        clock_t startTime, endTime;
        double totalTime;
        in = (int16_t*) calloc(SAMPLES, sizeof(int16_t));
        out = (int16_t*) calloc(SAMPLES, sizeof(int16_t));

        int             x;
        int             ttl;

        // Seed the pseudo-random number generator
        srand(-1);

        // Fill the array with random data
        for (x = 0; x < SAMPLES; x++) {
                in[x] = (rand()%65536)-32768;
        }
        startTime = clock();

        // ######################################
        // This is the interesting part!
        // Scale the volume of all of the samples
        for (x = 0; x < SAMPLES; x++) {
                out[x] = scale_sample(in[x], 0.75);
        }
        // ######################################
        startTime = clock();

        // Sum up the data
        for (x = 0; x < SAMPLES; x++) {
                ttl = (ttl+out[x])%1000;
        }
        totalTime= (double)(endTime-startTime)/CLOCKS_PER_SEC;
        // Print the sum
        printf("Result: %d\n", ttl);
        printf("CPU time used to scale samples: %1f seconds\n",totalTime);
        return 0;

}

The clock function is used to determine the quantity of CPU processing time this is used to calculate the scaled sample values and shop them in any other array. i will first run all my tests on Aarchie. I collect my program with no optimization. I take advantage of the time command to determine how long it takes to run my software. The time command shows the real time, the person CPU time and the system CPU time. here is the end result:

By compiling the code of vol1.c using command g++ -o vol1 vol1.c 
running it with:-  time ./vol1  we get
Result: -86
CPU time used to scale samples: -0.032502 seconds

real    0m0.038s
user    0m0.037s
sys     0m0.000s

An alternate approach to this approach would be to pre-create a lookup table of all possible sample values multiplies by  the volume factor, and look up each sample in that table to get the scaled values

#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <time.h>
#include "vol.h"

// Function to scale a sound sample using a volume_factor
// in the range of 0.00 to 1.00.
static inline int16_t scale_sample(int16_t sample, float volume_factor) {
        return (int16_t) (volume_factor * (float) sample);
}

int main() {

        // Allocate memory for large in and out arrays
        int16_t*        in;
        int16_t*        out;
        int16_t lookupTable[65536];
        clock_t startTime, endTime;
        double totalTime;
        in = (int16_t*) calloc(SAMPLES, sizeof(int16_t));
        out = (int16_t*) calloc(SAMPLES, sizeof(int16_t));

        int             x;
        int             ttl;

        for(x=0;x<65536;x++){
        lookupTable[x]=(x-32768)*.75;
        }
        // Seed the pseudo-random number generator
        srand(-1);

        // Fill the array with random data
        for (x = 0; x < SAMPLES; x++) {
                in[x] = (rand()%65536)-32768;
        }

        for(x=0;x<SAMPLES;x++){
        out[1]=lookupTable[in[1]+32768];
        }
        startTime = clock();

        // ######################################
        // This is the interesting part!
        // Scale the volume of all of the samples
        for (x = 0; x < SAMPLES; x++) {
                out[x] = scale_sample(in[x], 0.75);
        }
        // ######################################
        startTime = clock();

        // Sum up the data
        for (x = 0; x < SAMPLES; x++) {
                ttl = (ttl+out[x])%1000;
        }
        totalTime= (double)(endTime-startTime)/CLOCKS_PER_SEC;
        // Print the sum
        printf("Result: %d\n", ttl);
        printf("CPU time used to scale samples: %1f seconds\n",totalTime);
        return 0;

}
Compiling and running this code with the same command as previous one we get

Result: -86
CPU time used to scale samples: -0.041233 seconds

real    0m0.046s
user    0m0.046s
sys     0m0.000s

The result summing of the samples is the same but time to calculate those samples has pretty much increased by 0.008731 seconds compared to previous result

The last and final approach is to convert the volume factor 0.75 to a fix-point integer by multiplying by a binary number representing a fixed-point value "1". For example, you could use 0b100000000 (= 256 in decimal) to represent 1.00. Shift the result to the right the required number of bits after the multiplication (>>8 if you're using 256 as the multiplier).

#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <time.h>
#include "vol.h"

// Function to scale a sound sample using a volume_factor
// in the range of 0.00 to 1.00.
static inline int16_t scale_sample(int16_t sample, float volume_factor) {
        return (int16_t) (volume_factor * (float) sample);
}

int main() {

        // Allocate memory for large in and out arrays
        int16_t*        in;
        int16_t*        out;
        clock_t startTime, endTime;
        double totalTime;
        in = (int16_t*) calloc(SAMPLES, sizeof(int16_t));
        out = (int16_t*) calloc(SAMPLES, sizeof(int16_t));
        short volumeFactor = 0b100000000 * .75;
        int             x;
        int             ttl;

        // Seed the pseudo-random number generator
        srand(-1);

        // Fill the array with random data
        for (x = 0; x < SAMPLES; x++) {
                in[x] = (rand()%65536)-32768;
        }
        startTime = clock();

        // ######################################
        // This is the interesting part!
        // Scale the volume of all of the samples
        for (x = 0; x < SAMPLES; x++) {
                //out[x] = scale_sample(in[x], 0.75);
                out[x]=in[x]*volumeFactor>>8;
        }
        // ######################################
        startTime = clock();

        // Sum up the data
        for (x = 0; x < SAMPLES; x++) {
                ttl = (ttl+out[x])%1000;
        }
        totalTime= (double)(endTime-startTime)/CLOCKS_PER_SEC;
        // Print the sum
        printf("Result: %d\n", ttl);
        printf("CPU time used to scale samples: %1f seconds\n",totalTime);
        return 0;

}

Result: -386
CPU time used to scale samples: 4.167165 seconds

real    0m0.035s
user    0m0.035s
sys     0m0.000s

Here the result of scaled value is different from previous values because of conversion. Time has increased too.

By implementing -O3 optimization our result and timing quite varies each time.

1) Result: -126
CPU time used to scale samples: -0.024013 seconds

real    0m0.027s
user    0m0.027s
sys     0m0.000s

2) Result: -942
CPU time used to scale samples: -0.024040 seconds

real    0m0.027s
user    0m0.027s
sys     0m0.000s

3) Result: -506
CPU time used to scale samples: -0.023942 seconds

real    0m0.027s
user    0m0.027s
sys     0m0.000s

The entirety of all scaled tests does alter after utilizing -O3 choice. For the moment strategy, it took approximately  more time than the to begin with strategy to calculate the scaled test values and store them in another cluster. For the third strategy, it is approximately nearly 2 times speedier than the to begin with strategy and  nearly 3 times quicker than the moment strategy. The third strategy has the most brief genuine time and client time and the moment strategy has the longest genuine time and client time, which are the same comes about as some time recently. After optimization is empowered utilizing -O3 choice, the preparing time has been definitely diminished for all three strategies. When I compare to no optimization, the to begin with strategy is approximately 3.5 times speedier, the moment strategy is almost 2.4 times speedier and the third strategy is approximately 5.4 times quicker.

“/usr/bin/time -v” to find out how much memory is used to run my program. for all three methods using -O3 option during compilation:

Result: -126
CPU time used to scale samples: -0.023778 seconds
        Command being timed: "./lab5"
        User time (seconds): 0.01
        System time (seconds): 0.00
        Percent of CPU this job got: 96%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 3240
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 551
        Voluntary context switches: 1
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

Result: -942
CPU time used to scale samples: -0.023968 seconds
        Command being timed: "./lab5_2"
        User time (seconds): 0.02
        System time (seconds): 0.00
        Percent of CPU this job got: 100%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 3364
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 583
        Voluntary context switches: 1
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0


Result: -506
CPU time used to scale samples: -0.023344 seconds
        Command being timed: "./lab5_3"
        User time (seconds): 0.02
        System time (seconds): 0.00
        Percent of CPU this job got: 100%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 3244
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 551
        Voluntary context switches: 1
        Involuntary context switches: 1
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0


Conclusion:
From the comes about over, we see that the third strategy creates the most limited CPU handling time and the moment strategy creates the longest CPU handling time in any case of whether or not optimization is empowered when compiling my program. We get the same comes about when we compare the three strategies utilizing the genuine time and client time from the time command. This implies that the approach to alter volume that comes about in the leading execution is the third strategy. The third strategy changes over the volume figure to a fix-point numbers by duplicating it by a parallel number speaking to a fixed-point , increases this result by each test esteem and shifts the result to the right by the redress number of bits to get the scaled test esteem.

Friday 16 February 2018

Exploring single instruction/multiple data (SIMD) vectorization, and the auto-vectorization capabilities of the GCC compiler

What is SIMD VEctorization

A vector may be a direction book operand holding An situated of information components stuffed under a one-dimensional exhibit. The components camwood a chance to be basic alternately floating-point qualities. Practically Vector/SIMD media development Also SPU educational work on vector operands. Vectors need aid also known as SIMD operands alternately stuffed operands.

What is Auto Vectorization?

Programmed vectorization, clinched alongside parallel computing, may be an extraordinary the event about programmed parallelization, the place a workstation project will be changed over from An scalar implementation, which methods a single match of operands In a time, will a vector implementation, which methods person operation looking into numerous pairs from claiming operands without a moment's delay.

So the general purpose of this post is to show to how to implement SIMD vectorization and autovectorization in C code and understanding it by breaking down the code using assembly language and will be compiling on GCC compiler to know its capabilities which is integral part. Here we will be creating a short program with  two 1000-element integer arrays and fills them with random numbers in the range -1000 to +1000, then sums those two arrays element-by-element to a third array, and finally sums the third array and prints the result. So, our first step would be to create such program.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main() {
 
int array1[1000];
int array2[1000];
long array3[1000];
long arraySum = 0;

srand(time(NULL));

for (int i = 0; i < 1000; i++) {
        array1[i] = (rand()% 2001) - 1000;
        array2[i] = (rand()% 2001) - 1000;
        array3[i] = array1[i] + array2[i];
        arraySum += array3[i];
}
        printf("The total array sum is: %li\n", arraySum);

return 0;
}

Compiling this code through gcc compiler it using command
 //gcc -O3 -fopt-info-vec-missed=vect_v0.miss vect_v0.c -o vect_v0  gives us something like this
 vector.c:14:1: note: not vectorized: loop contains function calls or data references that cannot be analyzed
vector.c:12:1: note: not vectorized: not enough data-refs in basic block.
vector.c:16:22: note: not vectorized: not enough data-refs in basic block.
vector.c:14:1: note: not vectorized: not enough data-refs in basic block.
vector.c:20:9: note: not vectorized: not enough data-refs in basic block.

 But if we make few changes in our code

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main() {
 
int array1[1000];
int array2[1000];
long array3[1000];
long arraySum = 0;

srand(time(NULL));

for (int i = 0; i < 1000; i++) {
        array1[i] = (rand()% 2001) - 1000;
        array2[i] = (rand()% 2001) - 1000;
}

for (int i = 0; i < 1000; i++) {
        array3[i] = array1[i] + array2[i];
        arraySum += array3[i];
}
        printf("The total array sum is: %li\n", arraySum);

return 0;
}
 after compililation with the command //gcc -O3 -fopt-info-vec-missed=vect_v0.miss vect_v0.c -o vect_v0 note: loop vectorized

Here we can see that our loop got vectorized.

 Now disassembling the code which is autovectorized using simd objdump -d nameof yourfile

0000000000400560 <main>:
// Here we reserve space on the stack for local variables
  400560:       d283f010        mov     x16, #0x1f80                    // #8064
  400564:       cb3063ff        sub     sp, sp, x16
  400568:       d2800000        mov     x0, #0x0                        // #0
  40056c:       a9007bfd        stp     x29, x30, [sp]
  400570:       910003fd        mov     x29, sp
  400574:       a90153f3        stp     x19, x20, [sp, #16]
  400578:       529a9c74        mov     w20, #0xd4e3                    // #54499
  40057c:       a9025bf5        stp     x21, x22, [sp, #32]
  400580:       72a83014        movk    w20, #0x4180, lsl #16
  400584:       f9001bf7        str     x23, [sp, #48]
  400588:       910103b5        add     x21, x29, #0x40
  40058c:       913f83b6        add     x22, x29, #0xfe0
  400590:       5280fa33        mov     w19, #0x7d1                     // #2001
  400594:       d2800017        mov     x23, #0x0                       // #0
  400598:       97ffffd6        bl      4004f0 <time@plt>
  40059c:       97ffffe9        bl      400540 <srand@plt>
  4005a0:       97ffffdc        bl      400510 <rand@plt>
  4005a4:       9b347c01        smull   x1, w0, w20
  4005a8:       9369fc21        asr     x1, x1, #41
  4005ac:       4b807c21        sub     w1, w1, w0, asr #31
  4005b0:       1b138020        msub    w0, w1, w19, w0
  4005b4:       510fa000        sub     w0, w0, #0x3e8
  4005b8:       b8376aa0        str     w0, [x21, x23]
  4005bc:       97ffffd5        bl      400510 <rand@plt>
  4005c0:       9b347c01        smull   x1, w0, w20
  4005c4:       9369fc21        asr     x1, x1, #41
  4005c8:       4b807c21        sub     w1, w1, w0, asr #31
  4005cc:       1b138020        msub    w0, w1, w19, w0
  4005d0:       510fa000        sub     w0, w0, #0x3e8
  4005d4:       b8376ac0        str     w0, [x22, x23]
  4005d8:       910012f7        add     x23, x23, #0x4
  4005dc:       f13e82ff        cmp     x23, #0xfa0
  4005e0:       54fffe01        b.ne    4005a0 <main+0x40>  // b.any
  4005e4:       4f000401        movi    v1.4s, #0x0
  4005e8:       d2800000        mov     x0, #0x0                        // #0
  4005ec:       3ce06ac0        ldr     q0, [x22, x0]
  4005f0:       3ce06aa2        ldr     q2, [x21, x0]
  4005f4:       91004000        add     x0, x0, #0x10
  4005f8:       f13e801f        cmp     x0, #0xfa0
// This is what it's all for: vector addition
  4005fc:       4ea28400        add     v0.4s, v0.4s, v2.4s
  400600:       0ea01021        saddw   v1.2d, v1.2d, v0.2s
  400604:       4ea01021        saddw2  v1.2d, v1.2d, v0.4s
  400608:       54ffff21        b.ne    4005ec <main+0x8c>  // b.any
  40060c:       5ef1b821        addp    d1, v1.2d
  400610:       90000000        adrp    x0, 400000 <_init-0x4b8>
  400614:       91200000        add     x0, x0, #0x800
// Move the first and second 64-bit elements from vector 1 to two separate registers
// This might be so that they can be used as arguments for printf?
  400618:       4e083c21        mov     x1, v1.d[0]
  40061c:       97ffffcd        bl      400550 <printf@plt>
  400620:       f9401bf7        ldr     x23, [sp, #48]
  400624:       a94153f3        ldp     x19, x20, [sp, #16]
  400628:       52800000        mov     w0, #0x0                        // #0
  40062c:       a9425bf5        ldp     x21, x22, [sp, #32]
  400630:       d283f010        mov     x16, #0x1f80                    // #8064
  400634:       a9407bfd        ldp     x29, x30, [sp]
  400638:       8b3063ff        add     sp, sp, x16
  40063c:       d65f03c0        ret


In spite of the fact that gcc’s auto-vectorization could build raise execution it might not be useful for certain provisions. But auto vectorization can't be trusted. There are huge numbers confinements states will think about auto-vectorization. Gcc needs affirmation that arrays would adjusted Furthermore information may be adjusted. Also, code will well on the way must make re-written should rearrange circle purpose.


Friday 9 February 2018

Experiment with Assembler on the x86_64 and aarch64 platforms.

At  our system Previously, gathering language, we were specifically modifying those "bare metal" equipment. This implies that a number of the compile-time Also run-time checks, slip messages, Furthermore diagnostics that would display in other dialects would not accessible. The machine will take after your guidelines exactly, regardless of they need aid totally bad (like executing data), What's more when something dives wrong, your system won't end until it tries should do something That's not permitted, for example, execute a invalid opcode or endeavor on right An ensured alternately unmapped district for memory. When that happens, those cpu will sign an exception, Also By and large the working framework will close down the culpable procedure.

X86 is a crew for backward-compatible direction book set architectures dependent upon those Intel cpu What's more its Intel variant. Likewise a fully 16-bit development about Intel's 8-bit-based microprocessor, for memory division Concerning illustration an answer to tending to more memory over a chance to be secured by a plain 16-bit deliver.

New direction book set, A64. Need 31 universally useful 64-bit registers. Need committed zero alternately stack pointer register contingent upon direction book. The system counter may be no more straightforwardly receptive Likewise a register. Guidelines are still 32 odds in length What's more basically the same Likewise A32. Need matched loads/stores. No predication for practically educational. The majority educational make 32-bit or 64-bit contentions.
Addresses expected will make 64-bit.

(1) Our first step is to build 3 C versions of the Hello world program for x86_64
# Portable C versions: # write() version
                        # syscall() wrapper version
                        # printf() version
For example: Compiling code gcc -o hello hello.c 
Running the code ./hello
Use the objdump -d name of file command to dump (print) the object code (machine code)  
In Write version we need to print the string using write. In syscall() wrapper version we need to print the string using syscall and in printf version using printf(). After building and running the code for all three version we will notice a bit difference in amount of code. Write version has basically 185 line and amount of code in main is slightly big than printf while printf has 183 lines and has least amount of code in main. Amount of code in main for syscall version is highest compared to both the versions while number of lines in syscall is 187
 Output should be similar to this in x86_64 architecture

183 -lines x86_64 in total
0000000000400594 <main>:
  400594:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
  400598:       910003fd        mov     x29, sp
  40059c:       90000000        adrp    x0, 400000 <_init-0x418>
  4005a0:       9119c000        add     x0, x0, #0x670
  4005a4:       97ffffb7        bl      400480 <printf@plt>////printf()
  4005a8:       52800000        mov     w0, #0x0                        // #0
  4005ac:       a8c17bfd        ldp     x29, x30, [sp], #16
  4005b0:       d65f03c0        ret
  4005b4:       00000000        .inst   0x00000000 ; undefined

 185-lines in total
0000000000400594 <main>:
  400594:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
  400598:       910003fd        mov     x29, sp
  40059c:       90000000        adrp    x0, 400000 <_init-0x418>
  4005a0:       9119e000        add     x0, x0, #0x678
  4005a4:       d28001a2        mov     x2, #0xd                        // #13
  4005a8:       aa0003e1        mov     x1, x0
  4005ac:       52800020        mov     w0, #0x1                        // #1
  4005b0:       97ffffb0        bl      400470 <write@plt>////Write()
  4005b4:       52800000        mov     w0, #0x0                        // #0
  4005b8:       a8c17bfd        ldp     x29, x30, [sp], #16
  4005bc:       d65f03c0        ret

 187-lines in total
0000000000400594 <main>:
  400594:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
  400598:       910003fd        mov     x29, sp
  40059c:       90000000        adrp    x0, 400000 <_init-0x418>
  4005a0:       911a0000        add     x0, x0, #0x680
  4005a4:       528001a3        mov     w3, #0xd                        // #13
  4005a8:       aa0003e2        mov     x2, x0
  4005ac:       52800021        mov     w1, #0x1                        // #1
  4005b0:       d2800800        mov     x0, #0x40                       // #64
  4005b4:       97ffffb3        bl      400480 <syscall@plt>////syscall()
  4005b8:       52800000        mov     w0, #0x0                        // #0
  4005bc:       a8c17bfd        ldp     x29, x30, [sp], #16
  4005c0:       d65f03c0        ret
  4005c4:       00000000        .inst   0x00000000 ; undefined



(2) Our second step would be to Review, build, and run the aarchie64 assembly language programs. Take a look at the code using objdump -d objectfile and compare it to the source code

For example: Compiling code gcc -o hello hello.c 
Running the code ./hello

.text
.globl _start
_start:

        mov     x0, 1           /* file descriptor: 1 is stdout */
        adr     x1, msg         /* message location (memory address) */
        mov     x2, len         /* message length (bytes) */

        mov     x8, 64          /* write is syscall #64 */
        svc     0               /* invoke syscall */

        mov     x0, 0           /* status -> 0 */
        mov     x8, 93          /* exit is syscall #93 */
        svc     0               /* invoke syscall */

.data
msg:    .ascii      "Hello, world!\n"
len=    . - msg


Use the objdump -d name of file command to dump  the object code 

hello.o:     file format elf64-littleaarch64


Disassembly of section .text:

0000000000000000 <_start>:
   0:   d2800020        mov     x0, #0x1                        // #1
   4:   10000001        adr     x1, 0 <_start>
   8:   d28001c2        mov     x2, #0xe                        // #14
   c:   d2800808        mov     x8, #0x40                       // #64
  10:   d4000001        svc     #0x0
  14:   d2800000        mov     x0, #0x0                        // #0
  18:   d2800ba8        mov     x8, #0x5d                       // #93
  1c:   d4000001        svc     #0x0
 

The goal for this lab may be with execute a basic c circle composed Previously, both x86_64 What's more aarch64 constructing agent dialect. We were given an void x86_64  piece  which loops from 0 will 9, utilizing r15 Similarly as those list (loop control) counter.
Below code is  EMPTY BLOCK


 text
.globl    _start

start = 0                       /* starting value for the loop index; note that this  constant, not a variable */
max = 10                        /* loop exits when the index hits this number loop condition is i<max */

_start:
    mov     $start,%r15         /* loop index */

loop:
    /* ... body of the loop ... do something useful here ... */

    inc     %r15                /* increment index */
    cmp     $max,%r15           /* see if we're done */
    jne     loop                /* loop if we're not */

    mov     $0,%rdi             /* exit status */
    mov     $60,%rax            /* syscall sys_exit */
    syscall


x_86_64 & aarch64 Loops


In order to dissemble a binary file, we can use the CL tool objdump -d. When we dissemble a binary, we can examine that specific machines assembler instruction set.

x86_64 9 Iteration Loop Solution
.text
.global        _start

start = 0
max = 10

_start:
    mov         $start,%r15

loop:
    mov         $len,%rdx
    mov         $msg,%rsi
    mov         $1,%rdi
    mov         $1,%rax
    syscall

    inc         %r15
    mov         %r15,%r14
    add         $'0',%r14
    mov         $num,%r13
    mov         %r14b,(%r13)
    cmp         $max,%r15
    jne         loop

    mov         $0,%rdi
    mov         $60,%rax
    syscall

.section .data
        msg: .ascii  "Loop: 0\n"
        len = . - msg
        num = msg + 6






x86_9_loop:     file format elf64-x86-64


Disassembly of section .text:

00000000004000b0 <_start>:
  4000b0:    49 c7 c7 00 00 00 00     mov    $0x0,%r15

00000000004000b7 <loop>:
  4000b7:    48 c7 c2 08 00 00 00     mov    $0x8,%rdx
  4000be:    48 c7 c6 00 01 60 00     mov    $0x600100,%rsi
  4000c5:    48 c7 c7 01 00 00 00     mov    $0x1,%rdi
  4000cc:    48 c7 c0 01 00 00 00     mov    $0x1,%rax
  4000d3:    0f 05                    syscall
  4000d5:    49 ff c7                 inc    %r15
  4000d8:    4d 89 fe                 mov    %r15,%r14
  4000db:    49 83 c6 30              add    $0x30,%r14
  4000df:    49 c7 c5 06 01 60 00     mov    $0x600106,%r13
  4000e6:    45 88 75 00              mov    %r14b,0x0(%r13)
  4000ea:    49 83 ff 0a              cmp    $0xa,%r15
  4000ee:    75 c7                    jne    4000b7 <loop>
  4000f0:    48 c7 c7 00 00 00 00     mov    $0x0,%rdi
  4000f7:    48 c7 c0 3c 00 00 00     mov    $0x3c,%rax
  4000fe:    0f 05                    syscall 


In spite of aarch64 gathering need an alternate punctuation over its x86_64 partner they even now have their likenesses Previously, rationale.


aarch64 9 Iteration Loop Solution
.text
.globl    _start
start = 0     /* starting value for the loop index; note that this is a symbol (constant), not a variable */
max = 10        /* loop exits when the index hits this number (loop condition is i<max) */
ten = 10

_start:
        mov     x19, start
        mov     x22, ten
       
loop:
        adr     x1, msg
        mov     x2, len
        mov     x0, 1
        mov     x8, 64
        svc     0
        adr     x23, msg
        add     x19, x19, 1
        udiv    x20, x19, x22
        msub    x21, x22, x20, x19
        cmp     x20, 0
        beq     skip
        add     x20, x20, '0'
        strb    w20, [x23,6]
skip:
        add     x21, x21, '0'
        strb    w21, [x23,7]
        cmp     x19, max
        bne     loop
        mov     x0, 0
        mov     x8, 93
        svc     0
.data
        msg: .ascii  "Loop:  0\n"
        len = . - msg


aarch_9_loop:     file format elf64-littleaarch64


Disassembly of section .text:

00000000004000b0 <_start>:
  4000b0:    d2800013     mov    x19, #0x0                       // #0
  4000b4:    d2800156     mov    x22, #0xa                       // #10

00000000004000b8 <loop>:
  4000b8:    10080281     adr    x1, 410108 <msg>
  4000bc:    d2800122     mov    x2, #0x9                       // #9
  4000c0:    d2800020     mov    x0, #0x1                       // #1
  4000c4:    d2800808     mov    x8, #0x40                      // #64
  4000c8:    d4000001     svc    #0x0
  4000cc:    100801f7     adr    x23, 410108 <msg>
  4000d0:    91000673     add    x19, x19, #0x1
  4000d4:    9ad60a74     udiv    x20, x19, x22
  4000d8:    9b14ced5     msub    x21, x22, x20, x19
  4000dc:    f100029f     cmp    x20, #0x0
  4000e0:    54000060     b.eq    4000ec <skip>
  4000e4:    9100c294     add    x20, x20, #0x30
  4000e8:    39001af4     strb    w20, [x23,#6]

00000000004000ec <skip>:
  4000ec:    9100c2b5     add    x21, x21, #0x30
  4000f0:    39001ef5     strb    w21, [x23,#7]
  4000f4:    f1002a7f     cmp    x19, #0xa
  4000f8:    54fffe01     b.ne    4000b8 <loop>
  4000fc:    d2800000     mov    x0, #0x0                       // #0
  400100:    d2800ba8     mov    x8, #0x5d                      // #93
400104: d4000001 svc #0x0


To expand on our past 9 cycle circle we were tasked with growing the check with 30. Resonances straightforward sufficient. Simply increment the max quatity.With circle should a double-digit number, you need will change over those circle record number by separating it Eventually  perusing 10.

With print those circle list value, you will have on change over from a basic should digit character. On ASCII/ISO-8859-1/Unicode UTF-8, the digit characters would in the extent 48-57 (0x30-0x39). You will also requirement on amass the message to a chance to be printed for every accordance – you camwood would this by composing those digit under those message support When outputting it should stdout, which will be likely those best approach, alternately you could perform an arrangement of composes to those three parts of the message (‘Loop: ‘, number, ‘n’). You might need to allude of the `manpage` for ascii.

x86_64 30 Iteration Loop Solution
.text
.globl  _start


start = 0
max = 31
ten = 10

_start:

        mov     $start,%r15
        mov     $ten,%r14

loop:

        mov     $len,%rdx
        mov     $msg,%rsi
        mov     $1,%rdi
        mov     $1,%rax
        syscall

        inc     %r15
        mov     $0,%rdx
        mov     %r15,%rax
        div     %r14

        mov     $num,%r12
        mov     %rax,%r13
        cmp     $0,%r13
        je      skip
        add     $'0',%r13
        mov     %r13b,(%r12)
skip:
        inc     %r12
        mov     %rdx,%r13
        add     $'0',%r13
        mov     %r13b,(%r12)

        cmp     $max,%r15
        jne     loop

        mov     $0,%rdi
        mov     $60,%rax
        syscall

.section .data
        msg: .ascii  "Loop:  0\n"
        len = . - msg
        num = msg + 6

86_30_loop:     file format elf64-x86-64


Disassembly of section .text:

00000000004000b0 <_start>:
  4000b0:    49 c7 c7 00 00 00 00     mov    $0x0,%r15
  4000b7:    49 c7 c6 0a 00 00 00     mov    $0xa,%r14

00000000004000be <loop>:
  4000be:    48 c7 c2 09 00 00 00     mov    $0x9,%rdx
  4000c5:    48 c7 c6 28 01 60 00     mov    $0x600128,%rsi
  4000cc:    48 c7 c7 01 00 00 00     mov    $0x1,%rdi
  4000d3:    48 c7 c0 01 00 00 00     mov    $0x1,%rax
  4000da:    0f 05                    syscall
  4000dc:    49 ff c7                 inc    %r15
  4000df:    48 c7 c2 00 00 00 00     mov    $0x0,%rdx
  4000e6:    4c 89 f8                 mov    %r15,%rax
  4000e9:    49 f7 f6                 div    %r14
  4000ec:    49 c7 c4 2e 01 60 00     mov    $0x60012e,%r12
  4000f3:    49 89 c5                 mov    %rax,%r13
  4000f6:    49 83 fd 00              cmp    $0x0,%r13
  4000fa:    74 08                    je     400104 <skip>
  4000fc:    49 83 c5 30              add    $0x30,%r13
  400100:    45 88 2c 24              mov    %r13b,(%r12)

0000000000400104 <skip>:
  400104:    49 ff c4                 inc    %r12
  400107:    49 89 d5                 mov    %rdx,%r13
  40010a:    49 83 c5 30              add    $0x30,%r13
  40010e:    45 88 2c 24              mov    %r13b,(%r12)
  400112:    49 83 ff 1f              cmp    $0x1f,%r15
  400116:    75 a6                    jne    4000be <loop>
  400118:    48 c7 c7 00 00 00 00     mov    $0x0,%rdi
  40011f:    48 c7 c0 3c 00 00 00     mov    $0x3c,%rax
  400126:    0f 05                    syscall

Reflection.
Personally, i discovered working for low level computing construct will a chance to be testing yet all the In the same run through thick, as compensating. Those grammar might make extremely befuddling and dully with worth of effort with. I revel in Taking in over the full purpose of a procedure. All that that happens between A->B. Picking up introduction should low-level gathering modifying need provided for me exactly knowledge under how mind boggling What's more multifaceted attempting with those fittings could make. I’ve also picked up an entire new appreciation for compilers What's more IDE’s.