Parcourir la source

add pics from old blog

master
wacked il y a 4 ans
Parent
révision
8f73fcf829
3 fichiers modifiés avec 2 ajouts et 2 suppressions
  1. +2
    -2
      content/posts/arm-glibc-strlen.md
  2. BIN
      static/img/arm-glibc-strlen/strlen-loop.png
  3. BIN
      static/img/arm-glibc-strlen/strlen-side-by-side.png

+ 2
- 2
content/posts/arm-glibc-strlen.md Voir le fichier

@@ -7,7 +7,7 @@ draft: false
I wanted to get back into ARM assembler so I wrote my own strlen. And then I looked at the strlen() glibc uses and did not understand
a single thing. So I sat down and figured it out.

XXX IMG HERE XXX
![side by side comparsion](https://wacked.codes/img/arm-glibc-strlen/strlen-side-by-side.png)

On the left you see a flow diagram of the building blocks of my naive implementation. On the right you see glibc's. You might
notice that it is more complex. (How much faster it is, and which optimization exactly makes it fast is an interesting topic.
@@ -22,7 +22,7 @@ The first thing I noticed about the inner loop is that it is unrolled. That is a
because strlen does not clearly unroll as the input is cleanly divisible by word size. So on the end of every basic block there
is a check which skips out of the loop and to the end where the result is calculated and returned.

XXX IMG HERE XXX
![side by side comparsion](https://wacked.codes/img/arm-glibc-strlen/strlen-loop.png)

The basic blocks are basically identical. First the registers r2 and r3 are populated with the next two words to be checked for
the null byte. Now r2 and r3 each contain one word (i.e. 4 bytes). How do you check whether there is a null byte *somewhere* in them?

BIN
static/img/arm-glibc-strlen/strlen-loop.png Voir le fichier

Before After
Width: 575  |  Height: 552  |  Size: 43KB

BIN
static/img/arm-glibc-strlen/strlen-side-by-side.png Voir le fichier

Before After
Width: 1000  |  Height: 814  |  Size: 62KB

Chargement…
Annuler
Enregistrer