Paras vastaus
> 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
Osoittimen koko riippuu vain mallista, jolla koot koodia. Ei käyttöjärjestelmässä. Joten minulla on 64-bittinen Linux, mutta jos pakotan gcc: n kääntämään 32-bittisen koodin, saan 32-bittisen ELF- ja i386-koodin vain 4 tavun osoitinkoolla.
Jos saat 4 tavua Windowsissa, se tarkoittaa sinua kääntävät edelleen 32-bittistä tietoa ja sinun pitäisi löytää kytkin, joka vapauttaa koneesi koko potentiaalin. Vapauta Kraken!
Olen juuri vertaillut sitä, että eilen 32-bittisen i386-koodin ja x86\_64 bdver2: n (Piledriver, Haswell ja uudemmat) suorituskyvyn välillä voi olla enemmän kuin tekijä 5 nopeuden vahvistuksessa, ei vain suurempi muistimalli. Se ei ole enimmäkseen niin kriittistä, että 4 Gt muistia riittää useimpiin sovelluksiin.
Mutta vain 32-bittisellä koodilla menetät MMX: n, SSE: n, SSE2,3,4: n kyvyt ja monen edistyksen kokoonpanossa. viimeiset 35 vuotta. Sekä nopeampi pääsy mihin tahansa tiedonsiirtoon, bittikäsittelyyn, merkkijonooperaatioihin, matemaattisiin lisätoimintoihin ja, ja, ja,…
Vaikka joissakin tapauksissa alkuperäinen x86-koodi on etu: et voi voittaa koodin tiukkuuden!
Muokkaa: (ja pieni huhu, voit jättää huomiotta)
Selvä, tarkistan aina tällaisten lauseiden arvon. Juuri koottu x86\_64 vs. 8086 -perintökoodi. 53 tavua x88\_64 vs. 74 tavua 8086 vanhalla koodilla pienellä ohjelmalla. No … Jos pidät sen 8/16 bittisenä, se voi olla totta. Mutta ei nykyaikaisilla ohjelmistoilla, c-ohjelmilla ja kääntäjillä. Joten, ei kyyneleitä siitä, että vanhat perintöajat ovat menneet. Olkaamme rehellisiä: he olivat paskaa. Ainoa hyvä asia oli, että olin tuohon aikaan kuohuviiniä. Mutta sillä oli muita haittoja.
Asia on: nykyaikaiset prosessorimme ovat todella hienoja. Meillä on nyt se, mitä unelmissamme oli vasta 80-luvulla. Meillä on vihdoin tarpeeksi suuria kiintolevyjä, joista emme välitä tavusta tai kahdesta. Meillä on tarpeeksi suuri muisti, jos emme aja Windowsia tai muita resursseja. Meillä on vektorinkäsittely prosessorissamme ja rinnakkaislaskenta GPU: lla. Meillä on monisydämisiä, matemaattisia FPU: ita, erikoistuneita rekistereitä, kuten MMX, SSE, SSEx, saimme FMA3 ja FMA4 (no jos sinulla on ainakin AMD-prosessori, joudut odottamaan kauan, jotta pääset käsiksi siihen), me saimme erittäin hienostuneet kokoonpano-opkoodit, jotka tekevät kaikki hienot asiat mikrokoodissa tai jopa laitteistossa meille, usein kuin vain, vain yhden jakson aikana, saimme välimuistin, joka on suurempi kuin mikään, josta uskaltaisimme uneksia 80-luvulla .
Ja 80-luvulla ”tuleva” asia oli CD-levy, ja ajatus mielenterveyden gigatavujen tallentamisesta halpaan hopealevyyn oli vain kuvittelematon. Ja meillä on puhelimia, joissa on tietokoneita, jotka pystyvät simuloimaan 85: n suurimmat keskusyksiköt nopeudella 10000 tai enemmän.
Nyt meillä on kaikki hienot asiat!
Mutta mitä me teemme sen kanssa? Me viserrämme 144 merkkiä. Kukaan ei enää tiedä upouusien prosessoriemme kokoonpanopikoodien ihmeitä. Napsautamme vain roskapostia pois ja ajamme Windows-järjestelmiä, jotka arvioitiin ”mennyt pian”, ”paska”, ”mitä teet sillä paskaalla” jopa vuonna 1985, kun aloitin opiskelun.
Se ei onnistunut ei todellakaan parane Windowsissa. Se on edelleen virheenvaraisia ja haittaohjelmia sisältäviä roskapostia, joka on niin hämmästyttävää tietokonelaitteistomme ihmeiden yli, että jos asennat jotain paremmin sopivaa käyttöjärjestelmää meidän aikamme varten, räjäyttää mielesi. Varsinkin kehittäjänä.
Suorittimiemme kehitys hidastuu, kun markkinoilla on vain kaksi kilpailijaa, ja pitäisi olla aika todella vapauttaa jo olemassa oleva: sammuttaa 32-bittinen paska, alkaa optimoida kirjastokoodi kokoonpanossa, missä voimme. Valinnainen, aina varalla puhtaaseen ”C”: ään. Se on vitsi, eikö olekin? 144 merkkiä ?! Se ei ole vakavaa, vai? Huomasivatko he, millainen laitteisto meillä on? Ei sanaakaan Twitteriä vastaan, mukava palvelu, mutta tiedät mitä tarkoitan. He ajattelevat niin vitun pieniksi ja epäonnistuvat silloinkin.
Vastaus
Vihaat tätä vastausta.
Valmiina?
Se riippuu.
Osoitin on osoitteen koko koneella, jolle C-ohjelma kootaan.
- 1980-luvulla suositussa Z80-mikroprosessorissa osoitin on 16 bittiä.
- Alkuperäisellä 8086: lla osoitin voi olla 16, 20 tai 32 bittiä, vaikka osoitetila olisi vain 20 bittiä. Sinun oli annettava C-kääntäjälle komentoriviargumentti, joka kertoi kuinka leveän osoittimen tulisi olla. Se oli painajainen.Etsi wikipediasta ” muistimalli ” pitkä ja kauhistuttava esittely.
- 68000 mikroprosessorissa osoittimet olivat 32-bittisiä.
- Noin 5 vuotta sitten Intel-prosessoreille käytetyssä x86-mallissa, joka oli edelleen käyttökelpoinen, osoitin oli 32 bittiä, jolloin se osoitti noin 4 Gt. Tämä rajoitus johtaa 64-bittisten osoitteiden luomiseen.
- Viimeisten sukupolvien Intel-prosessoreissa käytetyssä x64-mallissa osoitin on 64 bittiä.
Et voi Oletetaan, että osoitin on saman kokoinen kuin int tai sama kuin pitkä. Kokonaisluvuvakio 0 voidaan muuntaa osoittimeksi, mutta muut kokonaisluvuvakiot eivät välttämättä ole muunnettavissa. Kun muunnat 0 osoittimeksi, ei voida taata, että osoittimen kaikki bitit ovat nollia, vaikka tämä on tyypillistä. Se voi olla mitä tahansa. 0 on muunnettu osoittimeksi, joka ei osoita kelvollista osoitetta. Voit lisätä osoittimeen kokonaisluvun tuottamalla osoittimen tai vähentää kokonaisluvun osoittimesta, jolloin saat osoittimen. Kaikella muulla on määrittelemätön vaikutus.