Legjobb válasz
> cat pointersize.c
#include
int main(){
int *ip;
printf(“pointer size: \%zu\n”, sizeof(ip));
}
> cc -o pointersize pointersize.c
> ./pointersize
pointer size: 8
> cc -m32 -o pointersize pointersize.c
> ./pointersize
pointer size: 4
A mutatóméret csak attól a modelltől függ, amely alatt összeállítja a kódot. Az operációs rendszeren nem. Tehát van 64 bites Linuxom, de ha arra kényszerítem a gcc-t, hogy 32 bites kódot fordítson, akkor 32 bites ELF és i386 kódot kapok, mindössze 4 bájtos mutatómérettel.
Ha 4 bájtot kap a Windows-on, ez azt jelenti, hogy még mindig 32 bites fordítást hajtanak végre, és meg kell találnia a kapcsolót a gép teljes potenciáljának felszabadításához. Engedje szabadjára a Kraken-t!
Éppen azt értékeltem, hogy tegnap a 32 bites i386 kód és az x86\_64 bdver2 (Piledriver, Haswell és újabb) teljesítménye között több lehet az 5-ös tényező a sebesség erősítésében, nem csak a nagyobb memória modell. Ez többnyire nem annyira kritikus, a legtöbb alkalmazáshoz 4 GB memória elegendő.
De csak 32 bites kóddal elveszíti az MMX, az SSE, az SSE2,3,4 képességeit és számos előrelépést jelent az összeszerelés során. az elmúlt 35 évben. A gyorsabb hozzáférés bármilyen adatátvitelhez, bitmanipuláció, karakterlánc-műveletek, fejlett matematikai függvények, és, és, és,…
Noha egyes esetekben az eredeti x86 kód előny: nem lehet legyőzze a kód tömörségét!
Szerkesztés: (és egy aprócska rángatás, figyelmen kívül hagyhatja)
Rendben, mindig ellenőrizem az ilyen mondatok értékét. Csak összeállított x86\_64 vs 8086 régi kódot. 53 bájt x88\_64 és 74 bájt 8086 régi kódon egy kis programmal. Nos … Ha 8/16 bites értéken tartja, akkor ez igaz lehet. De nem a modern szoftverekkel, c-programokkal és fordítókkal. Szóval, nincs könny afelől, hogy elmúltak a régi örökségi idők. Legyünk őszinték: szarok voltak. Az egyetlen jó dolog az volt, hogy akkoriban fiatalon csillogtam. De ennek más hátrányai is voltak.
A lényeg: modern processzoraink nagyon klasszak. Most megvan, ami csak a 80-as években volt álmunkban. Végül elég nagy merevlemezünk van, amelyek nem érdekelnek egy-két bájtot. Elég nagy memóriánk van, ha nem a Windows vagy más erőforrás-disznókat hajtjuk. A processzorunkon van vektorfeldolgozás, a GPU-nkon pedig a teljes párhuzamos számítás. Van többmagos, matematikai FPU-jaink, speciális regisztereink, mint például az MMX, SSE, SSEx, megvan az FMA3 és az FMA4 (nos, ha van AMD processzora, legalábbis sokáig kell várni, hogy kézbe vegye ezt), akkor rendkívül kifinomult összeszerelési opkódokat kaptak, amelyek mikrokódban vagy akár hardverben elvégzik az összes jó dolgot számunkra, gyakran, csak egy ciklus alatt, olyan gyorsítótár-memóriát kaptunk, amely nagyobb, mint bármi, amiről még a 80-as években álmodni mertünk volna .
És a 80-as években a „jön” a CD volt, és csak elképzelhetetlen volt az ötlet, hogy elgondolkodóan gigabájtokat tároljon egy olcsó ezüstlemezen. Vannak olyan számítógépeinkkel ellátott telefonjaink, amelyek képesek a 85-ös legnagyobb nagyszámítógépek sebességének 10000-szorosával, vagy ilyesmivel szimulálni.
Most minden fantasztikus dolog megvan!
De mit csinálunk vele? 144 karaktert twitterezünk. Már senki sem ismeri a vadonatúj processzorok összeszerelési opkódjainak csodáit. Csak kibaszott spam-re kattintunk, és olyan Windows rendszereket vezetünk, amelyek „hamarosan eltűnt”, „szar”, „mit csinálsz ezzel a vacakkal” minősítést kaptak még 1985-ben is, amikor elkezdtem tanulni.
Nem sikerült A Windows-val nem lett jobb. Ez még mindig hibajavított és rosszindulatú programokkal spamelt gagyi, amely olyan számítógépes hardverünk csodáin csap át, amelyek olyan csodálatosak, hogy ha valami jobban illeszkedő operációs rendszert telepítenek a mi időnkre, elrobbantják az elmédet. Különösen fejlesztőként.
A processzorok fejlődése lelassul, mivel csak két versenytárs maradt a piacon, és ideje lenne valóban felszabadítani azt, ami már megvan: kapcsolja ki azt a 32 bites szart, kezdje el optimalizálni könyvtár kód összeállításban, ahol tudjuk. Opcionális, mindig a tiszta „C” tartalommal.
És mi a fasz a Twitter? Ez vicc, nem? 144 karakter ?! Ez nem komoly, vagy? Észrevették, hogy milyen hardverünk van? Nincs szó a Twitter ellen, kedves kiszolgálás, de tudod, mire gondolok. Olyan kibaszottul gondolkodnak, és akkor is kudarcot vallanak.
Válasz
Utálni fogja ezt a választ.
Készen áll?
Ez attól függ.
A mutató annak a gépnek a címe, amelyre a C programot összeállítják.
- Az 1980-as években népszerű Z80 mikroprocesszoron a mutató 16 bites.
- Az eredeti 8086-ban egy mutató 16, 20 vagy 32 bit lehet, annak ellenére, hogy a címterület csak 20 bit volt. Meg kellett adnia a C fordítónak egy parancssori argumentumot, amely megmondta, milyen szélesnek kell lennie a mutatónak. Rémálom volt.Hosszú és rémisztő bevezetés céljából keresse meg a „ memória modellt ” a wikipédián.
- A 68000 mikroprocesszoron a mutatók 32 bitesek voltak.
- Az Intel processzorokhoz kb. 5 évvel ezelőtt használt x86 modellen, amely még mindig használható, a mutató 32 bites volt, így körülbelül 4 GB-ot tudott megcélozni. Ez a korlátozás 64 bites címek létrehozásához vezet.
- Az utóbbi néhány generáció Intel processzoraihoz használt x64 modellnél a mutató 64 bites.
Nem lehet tegyük fel, hogy a mutató ugyanolyan méretű, mint egy int, vagy ugyanolyan méretű, mint egy hosszú. A 0 egész állandó konvertálható mutatóvá, de más egész konstansok nem konvertálhatók. Ha a 0 értéket mutatóra konvertálja, nincs garancia arra, hogy a mutatóban található bitek nullaak lesznek, bár ez jellemző. Egyáltalán bármi lehet. A 0 konvertálva egy mutatóra, amely nem érvényes címre mutat. Hozzáadhat egy egész számot egy mutatóhoz, így mutatót hozhat létre, vagy kivonhat egy egész számot egy mutatóból, így mutatót hozhat létre. Minden másnak nincs meghatározva hatása.