Update README.md

README.md

@@ -113,8 +113,10 @@ The model outputs embeddings of size 768.
 The dataset is derived from the official [Debian Repository](https://wiki.debian.org/DebianRepository). We used the distribution's build and packaging system `apt` to
 cross-compile source packages for multiple ISAs and optimisation levels. We used the standard optimisation levels supported by the distribution's compiler, O0, O1, O2, O3 and Os.
 We also added an optimization level that includes vectorization and cryptographic instructions that we refer to as Optimized-custom, or Oc.
-This results in a maximum of 24 (6 optimisation levels and 4 ISAs) potentially different functions which are semantically identical, i.e. they represent the same functionality.
-However, because not all source packages can be built for all ISAs and because some optimisation levels result in identical functions, the actual number is often lower than that.
+The binary files from each source package are disassembled using Ghidra and the resulting control-flow graphs (CFGs) are exported.
+
+This results in a maximum of 24 (6 optimisation levels and 4 ISAs) potentially CFGs which are semantically identical, i.e. they represent the same functionality.
+However, because not all source packages can be built for all ISAs and because some optimisation levels result in identical code, the actual number is often lower than that.
 
 The dataset is split into a train, test and an evaluation set. This in done on source package basis, so all binaries and functions belonging to one source package are part of
 either the training set or the test set, not both.
@@ -160,27 +162,15 @@ either the training set or the test set, not both.
 ----------------------------
 
 # Preprocessing
-Several preprocessing steps have been taken: CFGs are processed to become a flat token list suitable for a tokenizer or 
-vocabulary builder. This procedure differs slightly between architectures, the processes can be inspected
-[here](https://github.com/NetherlandsForensicInstitute/asmtransformers/tree/main/asmtransformers/asmtransformers/preprocessors).
-
-Some operands have been normalized, 
-to reduce token explosion caused by raw numeric values. These numerical values are expressed as powers of two, such that
-4096 would be 2 ** 12, so `#0x2^c`, so would 6000, but 9000 would be `#0x2^d`. As a consequence, small numbers are distinguishable
-in the vocabulary list, but bigger numbers get one batched representation.
-
-Finally, jump tokens are normalised to be relative `JUMP_ADDR_*` tokens. (* being the line number of the jump adress in the given 
-function, rather than in the full CFG)
-
-
+Several preprocessing steps have been taken. CFGs are processed into a flat token list using ISA aware tokenizers.
+Immediate operands and addresses have been normalized to the nearest power-of-two reduce token explosion caused by raw numeric values.
+Finally, target addresses of jumps, conditional branches or call instructions are normalised to fucntion-relative `JUMP_ADDR_*` tokens. 
 
 # Performance
-Performance was measured in two ways: Mean Reciprocal Rank (MRR) and Accuracy@1. These metrics are useful for this problem 
-since we compare a given embedded function to a database of embedded functions, and then rank the database by cosine similarity.
-Mean Reciprocal rank shows the mean rank (1 the positive example in the database being ranked first, 0.5 when the positive example
-is ranked second, 0.25 when the positive example is ranked fourth, etc). I.e. an MRR of 0.66 shows that the positive example was
-usually ranked first or second. Accuracy@1 shows how many times the positive example ranked first. It is a useful metric, 
-but it's also very strict, which is why we used it combined with MRR.
+We report two performance metrics: Mean Reciprocal Rank (MRR) and Accuracy@1. 
+
+These metrics are suitable for evaluating tasks where a single example is retrieved from a large collection. 
+Accuracy@1 shows how many times the positive example ranked first. It is a useful metric, but it's also very strict, which is why we used it combined with MRR.
 
 |model|ARM64 mrr|ARM64 acc|AMD64 mrr|AMD64 acc|RISC-V mrr|RISC-V acc|I386 mrr|I386 acc|crosslingual mrr|crosslingual acc|
 |-----|---------|---------|---------|---------|----------|----------|--------|--------|----------------|----------------|