Merge pull request #2 from gMerm/LP_Corrections

Alternations based on the comments

Author: markos

content/learning-paths/cross-platform/simd-info-demo/conclusion.md

@@ -8,7 +8,7 @@ layout: learningpathall
 
 ### Conclusion and Additional Resources
 
-Porting SIMD code between architecture can be a daunting process, in many cases requiring many hours of studying multiple ISAs in online resources or ISA manuals of thousands pages.
+Porting SIMD code between architecture can be a daunting process, in many cases requiring many hours of studying multiple ISAs in online resources or ISA manuals of thousands pages. Our primary focus in this work was to optimize the existing algorithm directly with SIMD intrinsics, without altering the algorithm or data layout. While reordering data to align with native ARM instructions could offer performance benefits, our scope remained within the constraints of the current data layout and algorithm. For those interested in data layout strategies to further enhance performance on ARM, the [vectorization-friendly data layout learning path](https://learn.arm.com/learning-paths/cross-platform/vectorization-friendly-data-layout/) offers valuable insights.
 
 Using **[SIMD.info](https://simd.info)** can be be instrumental in reducing the amount of time spent in this process, providing a centralized and user-friendly resource for finding **NEON** equivalents to intrinsics of other architectures. It saves considerable time and effort by offering detailed descriptions, prototypes, and comparisons directly, eliminating the need for extensive web searches and manual lookups.
 

content/learning-paths/cross-platform/simd-info-demo/simdinfo-description.md

@@ -64,12 +64,4 @@ When you need to port code from one architecture to another, the advanced search
 
 Furthermore, **SIMD.info**’s comparison tools enhance this process by enabling side-by-side comparisons of instructions from various platforms. This feature highlights the similarities and differences between instructions, which is crucial for accurately adapting your code. By understanding how similar operations are implemented across architectures, you can ensure that your ported code performs optimally.
 
-Let's look at an actual example.
-
-
-
-
-
-
-<!-- IMAGE HERE:
-![example image alt-text#center](example-picture.png "Figure 1. Example image caption") -->
+Let's look at an actual example.

content/learning-paths/cross-platform/simd-info-demo/simdinfo-example1-porting.md

@@ -20,9 +20,12 @@ Create a new file for the ported NEON code named `calculation_neon.c` with the c
 #include <arm_neon.h>
 #include <stdio.h>
 
+float32_t a_array[4] = {1.0f, 4.0f, 9.0f, 16.0f};
+float32_t b_array[4] = {1.0f, 2.0f, 3.0f, 4.0f};
+
 int main() {
-    float32x4_t a = {1.0f, 4.0f, 9.0f, 16.0f};
-    float32x4_t b = {1.0f, 2.0f, 3.0f, 4.0f};
+    float32x4_t a = vld1q_f32(a_array);
+    float32x4_t b = vld1q_f32(b_array);
 
     uint32x4_t cmp_result = vcgtq_f32(a, b);
 
@@ -91,9 +94,6 @@ Square Root Result: 1.41 3.46 6.00 8.94
 
 You can see that the results are the same as in the **SSE4.2** example.
 
-{{% notice Note %}}
-We initialized the vectors in reverse order compared to the **SSE4.2** version because **{}** bracket initialization loads vectors from LSB to MSB, whereas **`_mm_set_ps`** loads the elements MSB to LSB.
-{{% /notice %}}
-
-
-
+{{% notice Note %}} 
+We initialized the vectors in reverse order compared to the **SSE4.2** version because the array initialization and vld1q_f32 function load vectors from LSB to MSB, whereas **`_mm_set_ps`** loads elements MSB to LSB.
+{{% /notice %}}

content/learning-paths/cross-platform/simd-info-demo/simdinfo-example2.md

@@ -63,7 +63,7 @@ _mm_madd_epi16(a, b)          : a4d8    0 56b8    0 2198    0  578    0
 
 You will note that the result of the first element is a negative number, even though we added 2 positive results (`130*140` and `150*160`). That is because the result of the addition has to occupy a 16-bit signed integer element and when the first is larger we have the effect of an negative overflow. The result is the same in binary arithmetic, but when interpreted into a signed integer, it turns the number into a negative.
 
-The rest of the values are as expected. Notice how each pair has a zero element next to it. The results are correct, but they are not in the correct order. You could get the correct order in multiple ways, using the widening intrinsics **`vmovl`** to zero-extend or using the **`zip`** ones to merge with zero elements. The fastest way is the **`vmovl`** intrinsics, as you can see in the next example:
+The rest of the values are as expected. Notice how each pair has a zero element next to it. The results are correct, but they are not in the correct order. In this example, we chose to use **`vmovl`** to zero-extend values, which achieves the correct order with zero elements in place. While both **`vmovl`** and **`zip`** could be used for this purpose, we opted for **`vmovl`** in this implementation. For more details, see the ARM Software Optimization Guides, such as the [Neoverse V2 guide](https://developer.arm.com/documentation/109898/latest/).
 
 ```C
 #include <arm_neon.h>
@@ -74,13 +74,16 @@ void print_s16x8(char *label, int16x8_t v) {
     int16_t out[8];
     vst1q_s16(out, v);
     printf("%-*s: ", 30, label);
-    for (size_t i=0; i < 8; i++) printf("%4x ", (uint16_t) out[i]);
+    for (size_t i = 0; i < 8; i++) printf("%4x ", (uint16_t)out[i]);
     printf("\n");
 }
 
+int16_t a_array[8] = {150, 130, 110, 90, 70, 50, 30, 10};
+int16_t b_array[8] = {160, 140, 120, 100, 80, 60, 40, 20};
+
 int main() {
-    int16x8_t a = { 150, 130, 110, 90, 70, 50, 30, 10 };
-    int16x8_t b = { 160, 140, 120, 100, 80, 60, 40, 20 };
+    int16x8_t a = vld1q_s16(a_array);
+    int16x8_t b = vld1q_s16(b_array);
     int16x8_t zero = vdupq_n_s16(0);
     // 130 * 140 = 18200, 150 * 160 = 24000
     // adding them as 32-bit signed integers -> 42000
@@ -94,7 +97,7 @@ int main() {
     res = vpaddq_s16(res, zero);
     print_s16x8("vpaddq_s16(a, b)", res);
 
-    // vmovl_s16 would sign-extend we just want to zero-extend
+    // vmovl_s16 would sign-extend; we just want to zero-extend
     // so we need to cast to uint16, vmovl_u16 and then cast back to int16
     uint16x4_t res_u16 = vget_low_u16(vreinterpretq_u16_s16(res));
     res = vreinterpretq_s16_u32(vmovl_u16(res_u16));