:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Ik probeer al een tijdje een rules library te maken voor de ESP8266. Ik weet prima met alle beperkingen van de ESP8266 om te gaan. Zo zit er nauwelijks recursie in en daar waar het onmogelijk is doe ik dat tail-recursive. Ik weet vrij goed om te gaan met de minimale geheugengrootte. Waar ik wel mee loop te stoeien is met een tweetal exceptions: 9 en 29. Exceptie 9 gaat over de 4 byte alignment. Exception 29 gaat over het schrijven in een verboden geheugengebied.
Aangezien geheugenbeheer nogal kritisch is doe ik veel en vaak realloc en memmove. Zo wordt syntax die op het FS staat ingeladen in het geheugen. Die ingeladen syntax wordt token voor token omgezet naar een AST in bytecode. Dat doe ik ook zo efficiënt mogelijk. Dus de syntax alloc wordt token voor token kleiner, de AST wordt token voor token groter.
Voorbeeld:
Er is ook een stack waarin de (tijdelijke) variabelen worden opgeslagen:
Nu heb ik een aantal vragen over de ESP8266:
1. Moet elke allocatie 4 byte aligned zijn of mag ik een 4 byte aligned pool aanmaken waarbinnen ik mijn AST opsla? De vm_tif_t neemt 9 bytes in beslag. Vier byte aligned moet dit in een geheugengebied van 12 bytes worden opgeslagen. Als ik 4 vm_tif_t tokens opsla dan zou in dat geval 48 bytes nodig hebben. Terwijl ik ook een pool kan aanvragen van 36 bytes waarbinnen ik vier 9 bytes vm_tif_t kan plaatsen. De pool is dan 4 bytes aligned. De individuele blokken die ik daarbinnen bewerk niet.
Een 4 bytes aligned pool is véél geheugenvriendelijker dan elke allocatie 4 bytes aligned te doen.
2. Kan exception 29 komen doordat er geen ruimte vrij is om bij een realloc een nieuw geheugengebied te vinden die voldoet aan de nieuwe grootte? Oftewel, het geheugen is te gefragmenteerd om mijn realloc te plaatsen. Wat ik wel typisch zou vinden aangezien er nog 5472 bytes beschikbaar heb. Welke andere oorzaak zou exception 29 kunnen hebben?
Er is jammer genoeg erg weinig hardcore informatie te vinden over het ESP8266 programmeren dus ik leg mijn hoop bij mijn mede tweakers.
Aangezien geheugenbeheer nogal kritisch is doe ik veel en vaak realloc en memmove. Zo wordt syntax die op het FS staat ingeladen in het geheugen. Die ingeladen syntax wordt token voor token omgezet naar een AST in bytecode. Dat doe ik ook zo efficiënt mogelijk. Dus de syntax alloc wordt token voor token kleiner, de AST wordt token voor token groter.
Voorbeeld:
C:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| #define VM_GENERIC_FIELDS \ uint8_t type; \ uint16_t ret; typedef struct vm_tif_t { VM_GENERIC_FIELDS uint16_t go; uint16_t true_; uint16_t false_; } __attribute__((packed)) vm_tif_t; typedef struct vm_toperator_t { VM_GENERIC_FIELDS uint8_t token; uint16_t left; uint16_t right; uint16_t value; } __attribute__((packed)) vm_toperator_t; |
Er is ook een stack waarin de (tijdelijke) variabelen worden opgeslagen:
C:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| typedef struct vm_vchar_t { VM_GENERIC_FIELDS char value[]; } __attribute__((packed)) vm_vchar_t; typedef struct vm_vnull_t { VM_GENERIC_FIELDS } __attribute__((packed)) vm_vnull_t; typedef struct vm_vinteger_t { VM_GENERIC_FIELDS int value; } __attribute__((packed)) vm_vinteger_t; typedef struct vm_vfloat_t { VM_GENERIC_FIELDS float value; } __attribute__((packed)) vm_vfloat_t; |
Nu heb ik een aantal vragen over de ESP8266:
1. Moet elke allocatie 4 byte aligned zijn of mag ik een 4 byte aligned pool aanmaken waarbinnen ik mijn AST opsla? De vm_tif_t neemt 9 bytes in beslag. Vier byte aligned moet dit in een geheugengebied van 12 bytes worden opgeslagen. Als ik 4 vm_tif_t tokens opsla dan zou in dat geval 48 bytes nodig hebben. Terwijl ik ook een pool kan aanvragen van 36 bytes waarbinnen ik vier 9 bytes vm_tif_t kan plaatsen. De pool is dan 4 bytes aligned. De individuele blokken die ik daarbinnen bewerk niet.
Een 4 bytes aligned pool is véél geheugenvriendelijker dan elke allocatie 4 bytes aligned te doen.
2. Kan exception 29 komen doordat er geen ruimte vrij is om bij een realloc een nieuw geheugengebied te vinden die voldoet aan de nieuwe grootte? Oftewel, het geheugen is te gefragmenteerd om mijn realloc te plaatsen. Wat ik wel typisch zou vinden aangezien er nog 5472 bytes beschikbaar heb. Welke andere oorzaak zou exception 29 kunnen hebben?
Er is jammer genoeg erg weinig hardcore informatie te vinden over het ESP8266 programmeren dus ik leg mijn hoop bij mijn mede tweakers.
Sinds de 2 dagen regel reageer ik hier niet meer
De volledige repo staat hier. De documentatie is trouwens wat verouderd:
