Es akkor ird le szazszor...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

... 

Hozzászólások

ez csak három!
írd le százszor:

a pontpontpont nem pótolja a hiányzó sorokat! a 3 pediglen nem 100! :))

Mi a probléma? Nem 4-es határon lévő címet kasztolsz uint3_t -re?

Pontosan... unaligned access. Raadasul a -munaligned-access opcio sem segit. Kicsit katyvaszos a gcc lelkivilaga mertha strukturan beluli elemeket akarnank elerni akkor automatikusan feltetelezi hogy non-aligned access van. Viszont egy ilyen direkt cast-olasnal meg csak siman ldr/ldrh/str/strh-ra fordit, fuggetlenul attol hogy mi a cim. Az meg ugye dob egy hátast, ha nem 00 ill 0 a cim utolso ket v. egy bit.

x86-nál próbáld meg az AVX regiszterbe hasonló cast-olással betölteni a float *vec-ből az i. elemtől az értéket.
GCC-vel olyan szép segfault-okat kapsz, hogy elsőre azt se tudod, mitől van. Helyette _mm256_loadu_ps() és minden jó lesz.
CLANG eleve unaligned-ként kezeli.

Szerkesztve: 2021. 04. 03., szo – 11:41

Na de nem lenne egyszerűbb azt a buffert 4-re align-olni? Még ha le is fordítaná, s utána itt a piros, hol a piros játszana a felolvasott értékekből shiftelgetve, maszkolgatva byte-onként, akkor sem lennél boldog, mert iszonyú sok ideig tartana a végrehajtás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE