- apal blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Mert megakad a ciklus 3-nál?
- A hozzászóláshoz be kell jelentkezni
... mar az elsonel :)
- A hozzászóláshoz be kell jelentkezni
ez csak három!
írd le százszor:
a pontpontpont nem pótolja a hiányzó sorokat! a 3 pediglen nem 100! :))
- A hozzászóláshoz be kell jelentkezni
castolgatunk, castolgatunk .... :)
- A hozzászóláshoz be kell jelentkezni
Mi a probléma? Nem 4-es határon lévő címet kasztolsz uint3_t -re?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
MC68k-n sem. Igaz, az manapság ritkább.
- A hozzászóláshoz be kell jelentkezni
Csak a 6800x/6801x/683xx CPU-kon. A többin az unaligned access csak "büntetőciklust" eredményez, de hibát nem.
- A hozzászóláshoz be kell jelentkezni
Rég volt, elhiszem
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni