rozmiar typu a przetwarzanie

Język C dla mikrokontrolerów Tensilic
Awatar użytkownika
squeez
Użytkownik
Posty: 76
Rejestracja: 16 paź 2017, 23:52

rozmiar typu a przetwarzanie

Post autor: squeez » 12 sty 2018, 9:29

Mam takie pytanie czy dla ESP ma jakieś znaczenie rozmiar typu? jak wiadomo dla 8 Bitowców (AVR) lepiej jest korzystać z typu 8bit (jeśli jest wystarczający ze względu na mneijsze zasoby przetwarzania, mniej taktów zajmuje niż obsługa 16bit).
Gdzieś kiedyś wyczytałem że w przypadku ARM lepiej jest stosować 16bitowe zamiast 8 bitowe nawet jeśli zakres wystarcza nam 8 bitów bo jest to lepiej optymalizowane przez kompilator. Choć nie wiem czy to prawda.

Czy w przypadku ESP też są tego typu zalecenia? w datasheet nie spotkałem choć może nie byłem zbyt uważny jak go czytałem :)

Awatar użytkownika
xbary
Użytkownik
Posty: 53
Rejestracja: 08 paź 2017, 19:59

Re: rozmiar typu a przetwarzanie

Post autor: xbary » 12 sty 2018, 9:56

W sumie to nie zastanawiałem się nad tym, ale można by sprawdzić w assemblerze jaki nakład jest na zajętość kodu. Czyli porównać przy zerowej optymalizacji w C operacje na 8 16 32 bitach, wygenerować podczas kompilacji sobie plik assemblera. To tak na szybko.
Chyba -S czy jakoś tak było trzeba podać w argumencie.

Awatar użytkownika
squeez
Użytkownik
Posty: 76
Rejestracja: 16 paź 2017, 23:52

Re: rozmiar typu a przetwarzanie

Post autor: squeez » 12 sty 2018, 12:12

no tak tylko by trochę było zabawy z szukaniem tego. bo kompilując nawet prosty kod dodawane są biblioteki do samego ESP jak choćby stos tcp obsługa wifi i wiele innych bibliotek :)

W przypadku normalnych mikrokontrolerów nie ma takiego kłopotu bo zrobisz czystą funkcję main z tym co chcesz sprawdzić i tylko to będzie generowanym kodzie asm.

mpo
Użytkownik
Posty: 9
Rejestracja: 11 sty 2018, 11:47

Re: rozmiar typu a przetwarzanie

Post autor: mpo » 12 sty 2018, 20:05

Można pisać kod bez tego całego balastu SDK.
Co ciekawe, można wtedy użyć wyższych częstotliwości taktowania rdzeni, bo 80/160MHz wymuszane są tylko przez taktowanie części odpowiedzialnej za wifi.
https://github.com/cnlohr/nosdk8266

Nie próbowałem tego osobiście, ale jak widać można "podsypać węgla pod kocioł".

Awatar użytkownika
squeez
Użytkownik
Posty: 76
Rejestracja: 16 paź 2017, 23:52

Re: rozmiar typu a przetwarzanie

Post autor: squeez » 12 sty 2018, 21:38

no dobra ale jak ma się to do mojego pytania? czy kod będzie kompilowany przez arduino, nonossdk czy nosdk to bez znaczenia bo kompilator raczej jest ten sam, a operacja maszynowe jaki jest generowany dla prostych operacji będzie pewnie identyczny np dla działania val++; będzie to rozbite na proste działania na rejestrach uc.

A jak zrezygnuję z SDK to co samemu pisać stos tcp albo wlasnorecznie portować lwip ... mija się z celem.
A pozbawianie ESP lacznośći ze światemi używanie go jako zwykłego uc to też mało interesujący pomysł, może w jakichś skrajnych przypadkach :)

mpo
Użytkownik
Posty: 9
Rejestracja: 11 sty 2018, 11:47

Re: rozmiar typu a przetwarzanie

Post autor: mpo » 12 sty 2018, 23:14

squeez pisze:
12 sty 2018, 21:38
no dobra ale jak ma się to do mojego pytania?
Nijak się ma :)
Ale zadałem sobie trud skompilowania kodu:
volatile uint64_t i;
for (i = 0; i < 255; i++);


Zmieniałem typ zmiennej i kolejno na uint8_t, uint16_t, uint32t, uint64t
Wyniki odpowiednio:
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.66 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.85 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.70 secs)
Program Sketch1 size: 222 079 bytes (used 21% of a 1 044 464 byte maximum) (1.67 secs)

Awatar użytkownika
squeez
Użytkownik
Posty: 76
Rejestracja: 16 paź 2017, 23:52

Re: rozmiar typu a przetwarzanie

Post autor: squeez » 13 sty 2018, 1:00

mpo pisze:
12 sty 2018, 23:14
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.66 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.85 secs)
Program Sketch1 size: 222 047 bytes (used 21% of a 1 044 464 byte maximum) (1.70 secs)
Program Sketch1 size: 222 079 bytes (used 21% of a 1 044 464 byte maximum) (1.67 secs)
czyli można by to zinterpretować tak że zmienna jest traktowana jako 32bit no chyba że przekroczy zakres wówczas widać nieznaczny narzut.

Awatar użytkownika
SunRiver
Administrator
Posty: 345
Rejestracja: 08 paź 2017, 11:27
Lokalizacja: Opole
Kontakt:

Re: rozmiar typu a przetwarzanie

Post autor: SunRiver » 13 sty 2018, 9:30

Otóż to panowie każda zmienna 8bit i 16bit jest traktowana jako 32bit i rezerwowana jest dla niej odpowiednia ilość pamięci
jest to poniekąd wygodne i dobre rozwiązanie. Zresztą sam KOLBAN gdzieś opisuje to zjawisko :)
.... z każdym bitem serca ....
💫SunDUINO
💦Google+
💦Kanał Youtube
💦Sotton

mpo
Użytkownik
Posty: 9
Rejestracja: 11 sty 2018, 11:47

Re: rozmiar typu a przetwarzanie

Post autor: mpo » 15 sty 2018, 13:23

SunRiver pisze:
13 sty 2018, 9:30
Otóż to panowie każda zmienna 8bit i 16bit jest traktowana jako 32bit i rezerwowana jest dla niej odpowiednia ilość pamięci
jest to poniekąd wygodne i dobre rozwiązanie. Zresztą sam KOLBAN gdzieś opisuje to zjawisko :)
To jak wytłumaczyć poniższe?

typedef struct /*__attribute__((__packed__))*/
{
uint8_t a;
uint8_t b;
uint16_t c;
} spakowana_t;

volatile spakowana_t liczniki;
void setup()
{
Serial.begin(115200);
Serial.printf("Rozmiar: %d\n", sizeof(spakowana_t));
for (liczniki.a = 0; liczniki.a < 10; liczniki.a++, liczniki.b++, liczniki.c++, Serial.printf(" %d", liczniki.a)); //cokolwiek...
}



Rozmiar struktury wynosi 4, niezależnie od tego czy struktura jest zadeklarowana normalnie czy jako packed.
Przy zmianie typów pól struktury na uint32_t, rozmiar to 12.

Awatar użytkownika
SunRiver
Administrator
Posty: 345
Rejestracja: 08 paź 2017, 11:27
Lokalizacja: Opole
Kontakt:

Re: rozmiar typu a przetwarzanie

Post autor: SunRiver » 15 sty 2018, 13:33

I to jest właśnie ciekawostka na którą odpowiedziec potrafią Tfu-rcy SDK dla Tensilica z esspresife ... osobiście czasem sam nie
łapię co autor miał na myśli i dlaczego tak .... ale działa :)

dodatkowo wiele dziwactw jest na nieoficjalnym sdk i pod toolchainem dla arduino ,
tu mi się wydaje ze jest nieco za mocno poprzesadzane od strony powiazania Tolchaina z SDK na pomoście core dla arduino

najprościej ... zrób to samo na SDK NonOS i SDK z RTOS dopiero się zdziwisz :)
.... z każdym bitem serca ....
💫SunDUINO
💦Google+
💦Kanał Youtube
💦Sotton

ODPOWIEDZ

Wróć do „C dla Tensilic”