Beste antwoord
> 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
Pointersize hangt alleen af van het model waaronder u uw code compileert. Niet op het besturingssysteem. Dus ik heb een 64-bits Linux, maar als ik gcc dwing om 32-bits code te compileren, krijg ik 32-bits ELF- en i386-code met slechts 4 bytes pointergrootte.
Als je 4 bytes op je Windows krijgt, betekent dat dat je compileren nog steeds 32bit en je zou de switch moeten vinden om het volledige potentieel van je machine te ontketenen. Laat de Kraken los!
Ik heb zojuist gebenchmarkt dat tussen de prestaties van 32bit i386-code en x86\_64 bdver2 (Piledriver, Haswell en hoger) meer kan zijn dan een factor 5 op het gebied van snelheidswinst, niet alleen het gebruik van de groter geheugenmodel. Dat is meestal niet zo kritisch, 4GB geheugen is genoeg voor de meeste applicaties.
Maar met slechts 32bit-code verlies je de mogelijkheden van MMX, SSE, SSE2,3,4 en veel vooruitgang in assemblage ten opzichte van de laatste 35 jaar. Evenals de snellere toegang voor elke gegevensoverdracht, bitmanipulatie, stringbewerkingen, geavanceerde wiskundige functies, en, en, en, …
Hoewel in sommige gevallen originele x86-code een voordeel is: dat kan niet versla de strakheid van de code!
Bewerken: (en een kleine tirade, je mag negeren)
Oké, ik controleer altijd de waarde van dergelijke zinnen. Zojuist gecompileerde x86\_64 versus 8086 legacy-code. 53 bytes voor x88\_64 versus 74 bytes op 8086 legacy-code met een klein programma. Nou … Als je het op 8/16 bit houdt, kan dit waar zijn. Maar niet met moderne software en c-programmas en compilers. Dus geen tranen dat de oude erfenis voorbij is. Laten we eerlijk zijn: ze waren waardeloos. Het enige goede was dat ik toen nog sprankelend jong was. Maar dat had andere nadelen.
Punt is: onze moderne processors zijn echt gaaf. We hebben nu wat we alleen in onze dromen hadden in de jaren 80. We hebben eindelijk harde schijven die groot genoeg zijn en dat we ons niet druk maken om een byte of twee. We hebben voldoende geheugen als we geen Windows of andere bronnen gebruiken. We hebben vectorverwerking op onze CPU en totaal parallel computergebruik op onze GPUs. We hebben multicores, wiskundige FPUs, gespecialiseerde registers zoals in MMX, SSE, SSEx, we hebben FMA3 en FMA4 (nou ja, als je een AMD-processor hebt, moet je in ieder geval lang wachten om dat te bemachtigen), we kreeg zeer geavanceerde montage-opcodes die al het coole werk in microcode of zelfs in hardware voor ons doen, vaak wel dan niet, gewoon in één cyclus gedaan, we hebben een cachegeheugen dat groter is dan alles waar we in de jaren 80 van hadden durven dromen .
En het komende ding in de jaren 80 was de cd en het idee om verbijsterende gigabytes op een goedkope zilveren plaat op te slaan was gewoon ondenkbaar. En we hebben telefoons met computers die in staat zijn om de grootste mainframecomputers van 85 te simuleren met een factor 10.000 van hun snelheid of zoiets.
Nu hebben we alle coole dingen!
Maar wat doen we ermee? We twitteren 144 karakters. Niemand kent de wonderen van de montage opcodes van onze gloednieuwe processors meer. We klikken gewoon verdomde spam weg en rijden Windows-systemen, die werden beoordeeld als “binnenkort weg”, “shitty”, “wat doe je met die onzin” zelfs in 1985, toen ik begon te studeren.
Dat gebeurde niet Het is echt niet beter geworden met Windows. Het is nog steeds vol bugs en door malware gespamde rotzooi, die de wonderen van onze computerhardware overstijgt, die zo verbazingwekkend is, dat als je een iets beters passend besturingssysteem voor onze tijd installeert, je geest weg zal blazen. Vooral als ontwikkelaar.
De ontwikkeling van onze processors vertraagt nu er nog maar twee concurrenten op de markt zijn en het zou tijd moeten worden om echt te ontketenen wat we al hebben: zet die 32-bits shit uit, begin met het optimaliseren van onze bibliotheekcode in assemblage waar we kunnen. Optioneel, met altijd een terugval naar pure “C”.
En wat is Twitter in godsnaam? Dat is een grap, nietwaar? 144 tekens ?! Dat is niet serieus, of? Is het hen opgevallen wat voor soort hardware we hebben? Geen woord tegen Twitter, goede service, maar je begrijpt wat ik bedoel. Ze denken zo verdomd klein en falen zelfs dan.
Antwoord
Je gaat dit antwoord haten.
Klaar?
Het hangt ervan af.
Een pointer is de grootte van een adres op de machine waarvoor het C-programma wordt gecompileerd.
- Op de Z80-microprocessor, populair in de jaren 80, een pointer is 16 bits.
- Op de originele 8086 kan een pointer 16, 20 of 32 bits zijn, ook al was de adresruimte slechts 20 bits breed. Je moest de C-compiler een opdrachtregelargument geven dat zei hoe breed een pointer zou moeten zijn. Het was een nachtmerrie.Zoek “ geheugenmodel ” op Wikipedia voor een lange en gruwelijke introductie.
- Op de 68000-microprocessor waren de aanwijzers 32-bits.
- Op het x86-model dat tot ongeveer 5 jaar geleden voor Intel-processors werd gebruikt en nog steeds bruikbaar was, was een pointer 32 bits, waardoor deze ongeveer 4 GB kon adresseren. Deze beperking leidde tot het maken van 64-bits adressen.
- Op het x64-model dat wordt gebruikt voor Intel-processors van de laatste paar generaties, is een aanwijzer 64 bits.
Je kunt niet neem aan dat een pointer even groot is als een int, of even groot als een long. De integerconstante 0 kan worden geconverteerd naar een pointer, maar andere integerconstanten zijn mogelijk niet converteerbaar. Wanneer u 0 naar een pointer converteert, is er geen garantie dat de bits in de pointer allemaal nullen zijn, hoewel dit typisch is. Het kan van alles zijn. 0 is geconverteerd naar een aanwijzer die naar geen geldig adres verwijst. U kunt een geheel getal aan een aanwijzer toevoegen, wat een aanwijzer oplevert, of een geheel getal aftrekken van een aanwijzer, wat een aanwijzer oplevert. Al het andere heeft een ongedefinieerd effect.