Lubię przykłady, więc napisałem trochę samo modyfikującego się kodu w c ...

#include <stdio.h>
#include <sys/mman.h> // linux

int main(void) {
    unsigned char *c = mmap(NULL, 7, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|
                            MAP_ANONYMOUS, -1, 0); // get executable memory
    c[0] = 0b11000111; // mov (x86_64), immediate mode, full-sized (32 bits)
    c[1] = 0b11000000; // to register rax (000) which holds the return value
                       // according to linux x86_64 calling convention 
    c[6] = 0b11000011; // return
    for (c[2] = 0; c[2] < 30; c[2]++) { // incr immediate data after every run
        // rest of immediate data (c[3:6]) are already set to 0 by MAP_ANONYMOUS
        printf("%d ", ((int (*)(void)) c)()); // cast c to func ptr, call ptr
    }
    putchar('\n');
    return 0;
}

... który działa najwyraźniej:

>>> gcc -Wall -Wextra -std=c11 -D_GNU_SOURCE -o test test.c; ./test
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Ale szczerze mówiąc, nieoczekiwać to w ogóle działa. Spodziewałem się instrukcji zawierającejc[2] = 0 do buforowania przy pierwszym wywołaniuc, po czym wszystkie kolejne połączenia doc ignorowałby powtarzające się zmianyc (chyba że jakoś w jakiś sposób unieważniłem pamięć podręczną). Na szczęście mój procesor wydaje się być mądrzejszy.

Domyślam się, że procesor porównuje pamięć RAM (zakładającc nawet znajduje się w pamięci RAM) z pamięcią podręczną instrukcji, gdy wskaźnik instrukcji powoduje duży skok (tak jak w przypadku wywołania powyższej pamięci) i unieważnia pamięć podręczną, gdy nie pasuje (wszystko?), ale ja mam nadzieję uzyskać dokładniejsze informacje na ten temat. W szczególności chciałbym wiedzieć, czy to zachowanie można uznać za przewidywalne (z wyjątkiem różnic sprzętowych i os), i na których polegało?

(Prawdopodobnie powinienem zapoznać się z instrukcją Intela, ale ta rzecz ma tysiące stron i często się w niej gubię ...)