Originally Posted by
GolezTrol
32 bit taal
Wel dat is dus niet zo, want dan zou
delphi Code:
<ietsvanint64>:=100000000000;
ook niet werken en gewrapped worden naar 32-bit. Want de compiler heeft daar ook een untyped rechter lid, maar neemt niet automatisch aan dat het daar 64-bit is.
We weten allemaal dat de Cardinal/dword/int64 implementatie in fases is gegaan, en in theorie zou dit ongefixed kunnen zijn om ergens geen compatibiliteit te breken.
Zelf denk ik echter eerder dat het simpelweg te veel werk was voor wat het opleverde (het fixed alleen het literal *literal*literal geval). Hetzelfde voor het feit dat Delphi nog altijd geen 64-bit unsigned heeft.
FPC is echter vrijwel totaal herschreven van v1 naar v2, en dus toen is het gewoon simpelweg direct goed gedaan, Qword incluis.
Verder vallen sommige van deze problemen eerder op omdat FPC in zichzelf geschreven is. Oftewel, de taal moet in FPC's geval de arithmetic kunnen doen die de implementatie nodig heeft. In Delphi, wat in C++ is geschreven hoeft dit niet.
Het feit dat Lazarus het anders ('beter') doet is misschien een voordeel voor Lazarus, maar aan de andere kant lijkt het me ook niet zo logisch dat de compiler maar even 128 bits gaat reserveren als ik de waarde 1024 in een constante zet.
Dat lijkt me niet zo efficient om mee te rekenen.
Dat is het ook niet. Maar in dit geval doet het er niet toe.
Jij als purist en verdediger van micromalistische optimalisaties, Marcov
Ik neem aan dat je daarmee impliciet "is kritisch" bedoelt, en zal het dan maar als compliment zien.
, zou het er toch niet mee eens moeten zijn dat de compiler kiest voor "arithmetische functies " die "redelijk doendelijk zijn" en niet voor de snelste manier, tenzij op expliciet verzoek (dmv bijvoorbeeld een typecast).
Jij snapt het dus niet?!? Het is in de compiler zelf, ALLEEN de arithmetic waar de compiler die compiletime constantes als die (1024*1024*2048) in het voorbeeld uitrekent. Van die 128-bitness komt dus niets in de uiteindelijke gegenereerde binary, en doorgaans zorgen early outs ervoor dat het effectief een 32 of 64-bit arithmetic is. De gegenereerde code wordt aangepast aan de breedte van de uiteindelijke constante.
En de tijd om een int64 vermenigvuldiging (of zelfs 128 bit) te doen in de compiler is nu eenmaal te verwaarlozen ten opzichte van al die string parsing (en al helemaal nu die met D2009 unicode wordt).
Let op dat dat 128-bittige het extreme geval is (zie eerder uitleg). Als je het goedvindt dat literals van 2^63-1 tot 2^64-1, het verschil in range tussen signed en unsigned 64-bit, alleen met een expliciete typecast werken, dan is int 64 + ingebouwde arithmetic genoeg.
(b.v.qword($FFFFFFFFFFFFFFFF) div sizeof(type) ipv $FFFFFFFFFFFFF div sizeof(type). De typecast is om te voorkomen dat de qword constante in een standaard arithemetiek (64-bit) wordt uitgerekend, waar het resultaat 0 zou zijn (-1 div sizeof(type)) Sommige mensen kennen dit soort problemen misschien nog met de oude dword en cardinal constanten van voor de int64 introductie (D3?). Het is in feite hetzelfde probleem )
Maar goed, ik zal het voorstellen als additie voor de "known problems" site zetten, want het is en blijft een afwijking.
Bookmarks