Autor Wątek: Co Programistom Gier Dają Nowe 64 bitowe Procesory ?  (Przeczytany 9291 razy)

Offline Złośliwiec

  • Użytkownik
    • Dark Cult

# Październik 31, 2006, 13:38:27
Tutaj nigdy nie było konkretnych wymagań i zawsze mogłeś indeksować i allokować tablice nawet char'ami. Jak to się będzie odbywało w samym kodzie to już nie wiem, ale kompilator na pewno szczegółowych wymagań tutaj nie narzuci. :)

Wymagań raczej nie, ale jeśli np. indeksujesz char-em, to zachodzi chyba jakaś niejawna konwersja, nie?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline shyha

  • Użytkownik
    • Shyha@Flickr

# Październik 31, 2006, 22:28:01
Tutaj nigdy nie było konkretnych wymagań i zawsze mogłeś indeksować i allokować tablice nawet char'ami. Jak to się będzie odbywało w samym kodzie to już nie wiem, ale kompilator na pewno szczegółowych wymagań tutaj nie narzuci. :)

Wymagań raczej nie, ale jeśli np. indeksujesz char-em, to zachodzi chyba jakaś niejawna konwersja, nie?
W tym kierunku to chyba nie ma problemu co nie? :]

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Listopad 01, 2006, 00:08:25
Cytuj
Wymagań raczej nie, ale jeśli np. indeksujesz char-em, to zachodzi chyba jakaś niejawna konwersja, nie?
Na upartego to jest jeszcze XLAT, ale generalnie chyba tak (chociaż wątpię, żeby jeden konwertujący MOV wiele zmieniał). :)

Offline Avinetiv

  • Użytkownik

# Listopad 06, 2006, 03:24:33
Z tego co słyszałem, to cieszą się głównie twórcy algorytmów szachowych. ;D

64 - liczba pól na szachownicy więc różne operacje na maskach bitowych (zasięgi ruchów, pola rażenia itd.) można wykonać dla całej szachownicy za jednym rzutem.

Programy szachowe w zasadzie sprowadzają się do alfa-bety + różne kruczki i patenty na ważenie, gotowe bazy końcówek, odpowiednie wycinanie drzewka itd. Wkiększa wydajność = głębsze przeszukanie = lepszy (mocniejszy) program.

Offline Megabyte

  • Użytkownik

# Listopad 06, 2006, 08:23:39
W wolnych chwilach bawie sie w poprawianie algorytmu do kartkowych piłkarzyków. Stosuje tam zmodyfikowany MIN MAX + ciecia alfa,beta + inne optymalizacje. Z tym że akurat nie wykorzystuje operacji na maskach 64bit :) Po skompilowaniu na 64bit program chodzi na moim A64 około 15% szybciej

Za to w innym programiku mam ponad 70% wzrostu wydajności. Jak widać czasem przejście na 64bit robi dużą różnice :)

Offline gamecreator

  • Użytkownik
    • Game C++reator - strona o tworzeniu gier w C++

# Listopad 26, 2006, 23:31:18
Przy okazji: Jak pisać programy, żeby poprawnie kompilowały się i działały także na 64 bitach? Są na ten temat jakieś artykuły albo tutoriale?

Skoro typ int ma teraz mieć 64b, char będzie miał 8b, short 16b, to jaki typ będzie miał 32b? W C++ nie ma nic więcej do dyspozycji.

Czy float i double zostaje w procesorach 64-bitowych taki jaki był?
Cytat: ayufan
long?

Typ long niestety nie mógłby być użyty, bo w obecnej postaci Standard C++ wymaga, by long był większy od int. Problem w tym, że przeważnie int i long int są równe, bo int odpowiada zawsze rozmiarowi słowa maszynowego, a więc także rozmiarowi rejestrów procesora i szyny adresowej, więc jest to IMHO trochę pogięte :P i mam nadzieję że nowy standard C++0x wprowadzi trochę porządku. Gadałem o tej sprawie raz ze Stroustrupem [przez maila ;D], jak znajdę jego odpowiedzi to może tutaj zacytuję...
Z tego co pamiętam, że mówił, to aktualnie typ int jest najbardziej odpowiednim kandydatem dla 64 bitów, jeśli ma być zachowana zgodność ze Standardem [Microsoft łamie tą zgodność stosując ten swój long long int, ale to pewnie jakieś kompleksy Billa ;D], bo typ int jest właśnie tym typem, który ma być najbardziej wygodny dla procesora. I tak jak mówi Bies, typ int powinien być stosowany w przypadku, gdy programista ma na myśli liczbę całkowitą i nie powinien wtedy zakładać, ile ona zajmie w pamięci [jak to mówią, "Presumption is a mother of all fuckups" :P]. Jednak Stroustrup przyznał że obecny standard wymaga dopracowania w tych kwestiach. Z tego co się orientuję, pracują nad nowym standardem C++0x, w którym wiele rzeczy mają uściślić, poprawić spójność języka itp. [BTW może ktoś tu coś wie na temat postępów prac nad nowym standardem?]

bies

  • Gość
# Listopad 26, 2006, 23:46:29
Na szybko bo idę spać. Pleciesz kolego trzy po trzy.  long long int  jest standardem (tyle ze dla C). Został dodany w C99, ca C++ się nie załapał i tyle. Teoria spiskowa z MS-em legła w gruzach ;p.  Pierwsze słyszę żeby standard *wymuszał* aby long był większy od int. Standard definiuje minimalne i maksymalne *gwarantowane* zakresy, jakie musi spełnić implementacja, zaznaczając równocześnie, że mogą być one większe.  Do tego celu definiuje makra - np INT_MIN INT_MAX, LONG_MIN LONG_MAX itp.   
Można je znaleść w :

C  :   <limits.h>
C++: <climits>

Pozdr.

//Edit - a i nie sugerowałbym się kolejnymi dziwnymi wizjami Regedita jakoby int miał mieć 64 bity. Od tego jest właśnie long long int.  Główna zmiana to size_t z 32 na 64 bity (bo tak narzuca standard) i oczywiście wskaźniki. Mówię naturalnie o WIN64. Na innych OS-ach/platformach należy sprawdzić pliki nagłówkowe/makra/sizeof-y (zresztą zawsze należy to robić ;) - int nie musi mieć 32 bit nawet na 32-bit OS-ku ).
« Ostatnia zmiana: Listopad 27, 2006, 00:01:53 wysłana przez st3tc »

Offline cienio

  • Użytkownik

# Listopad 27, 2006, 22:24:20
A trzeba mieć kompilator 64 bitowy czy system juz sam będzie wiedział  co zrobić?
Czy na procku 64 bitowym double będą liczone dwa razy szybciej w porównaniu z 32 bitowym? Wydaje mi się , że tak bo całą liczbę procek "łyknie" za jednym razem a na 32 bitowym brał ją na dwa razy.
Pozdrawiam.

bies

  • Gość
# Listopad 27, 2006, 22:42:58
Trzeba miec. Zreszta - jezeli uzywasz VC++EE + PSDK to juz masz 64-ro bitowy kompilator na pokladzie. Co do double - sama arytmetyke procesor robi na wewnetrznych (duzych) rejestrach FPU (do 128 bitow dla SIMD), ale samo ladowanie/zapisywanie danych powinno byc szybsze dla double niz na 32 bit CPU.

Offline gamecreator

  • Użytkownik
    • Game C++reator - strona o tworzeniu gier w C++

# Listopad 27, 2006, 23:02:19
Cytat: st3tc
Pleciesz kolego trzy po trzy.
Jeśli już chcesz mnie obrażać, to:
1. Weź pod uwagę, że ja tego nie robiłem w stosunku do nikogo.
2. Udowodnij mi że "plotę trzy po trzy". Bo jak narazie to same puste słowa.

Cytat: st3tc
long long int  jest standardem (tyle ze dla C). Został dodany w C99
Owszem, jest, ale:
1. Co ma C do C++? Ja mówiłem o tym drugim.
2. nawet ów standard nie mówi ani słowa, że long long int ma mieć 64 bity. A oto co mówi:

"6.2.5. Types
(...)
4 There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.(28) The standard and extended signed integer types are collectively called signed integer types.(29)"


Nie tylko nie precyzuje rozmiarów, ale też nie precyzuje co jest większe od czego [jak robi to Standard C++].

Cytat: st3tc
a C++ się nie załapał i tyle
Może taki był plan ;-)
A tak serio: Z tego co wiem, Standard ISO C++98 został ustanowiony w roku 1998, a standard C99 w roku 1999, więc na co C++ miał sie załapać jak został ustanowiony wcześniej? 15 października 2003 roku komisja standaryzacyjna wydała drugą edycję standardu z kilkoma poprawkami, i tam także nikt widocznie nie uznał wprowadzenia typu long long ing za dobry pomysł. Nowy standard C++0x ma ponoć precyzować tą kwestię, niestety na ten temat narazie nic nie wiem, jeśli ty wiesz to szaśnij wiedzą ;)

Cytat: st3tc
Teoria spiskowa z MS-em legła w gruzach ;-p
Hę? Ja piłem do tego, że pomału dojdzie tego, że będziemy pisać fucking unbelievable long long long long long int ;-J A manii wielkości Billa też chyba nikt nie zaprzeczy ;)

Cytat: st3tc
Pierwsze słyszę żeby standard *wymuszał* aby long był większy od int.
Nom, standard C99 rzeczywiście niczego nie wymusza, więc tam to wogóle już nic nie wiadomo i każdy producent kompilatora może robić jak chce. ISO C++ jednak conieco wymusza:

"3.9.1. Fundamental types.
(...)
2. There are four signed integer types: "signed char", "short int", "int", "long int". In this list, each type provides at least as much storage, as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment(39); the other signed integer types are provided to meet special needs.
(...)
39) That is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>."


A więc wymaga, by każdy następny typ z tej listy był conajmniej tak duży, jak jego poprzednik. Dlatego na pewno nie może być tak, by long long int czy long int były mniejsze niż czysty int.

Cytat: st3tc
Standard definiuje minimalne i maksymalne *gwarantowane* zakresy, jakie musi spełnić implementacja, zaznaczając równocześnie, że mogą być one większe.  Do tego celu definiuje makra - np INT_MIN INT_MAX, LONG_MIN LONG_MAX itp.
Z tym się zgodzę. Stroustrup o tym pisze tak:

"This is what is guaranteed about sizes of fundamental types:
 sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
In addition, it is guaranteed that a char has at least 8 bits, a short at least 16 bits, and a long at least 32 bits."


Przestrzega też przed tworzeniem niepotrzebnych założeń co do rozmiarów tych typów w pamięci ponad to, co zostało podane w Standardzie.

Cytat: st3tc
nie sugerowałbym się kolejnymi dziwnymi wizjami Regedita jakoby int miał mieć 64 bity
A ile twoim zdaniem miałby mieć, by być zgodnym ze standardem? Jeśli czysty int miałby być wierny zasadzie, że jego rozmiar  "jest naturalnym rozmiarem podyktowanym przez środowisko wykonania" [czyli dla procków 64-bitowych: 64 bity], to żaden z poprzednio wymienionych typów nie mógłby być przeznaczony na wartości 32-bitowe [chyba że short int]. Jeśli zaś int miałby być 32-bitowy, to wtedy złamałby tą zasadę o użyciu rozmiaru najbardziej wygodnego dla procesora [czyli rozmiaru jego rejestrów i szyny danych].

Cytat: st3tc
Od tego jest właśnie long long int.
W Standardzie C++ nie ma long long int, a w Standardzie C99 nic takiego nie pisze ;-J

Cytat: st3tc
Mówię naturalnie o WIN64. Na innych OS-ach/platformach należy sprawdzić pliki nagłówkowe/makra/sizeof-y (zresztą zawsze należy to robić ;) - int nie musi mieć 32 bit nawet na 32-bit OS-ku).

A to my rozmawiamy o platformie systemowej czy sprzętowej? AFAIK rozmiary typów podstawowych w pamięci zależą raczej od tej drugiej [oraz częściowo od kompilatora, jeśli robimy cross-compiling na inny sprzęt, ale to inna bajka]. Poza tym świat nie kończy się na Windows...

Cytat: cienio
A trzeba mieć kompilator 64 bitowy czy system juz sam będzie wiedział  co zrobić?
Oczywiście, kompilator musi wiedzieć, pod jaki dokładnie procesor tworzy kod [32-bitowy czy 64-bitowy]. Podobnie było kiedyś, gdy stare kompilatory tworzyły kod 16-bitowy dla np. MS-DOS, a nowe 32-bitowe dla trybu chronionego procków od 386 w górę [32-bit]. No i oczywiście musisz mieć na czym uruchomić taki program, czyli odpowiedni sprzęt ;)

Cytat: cienio
Czy na procku 64 bitowym double będą liczone dwa razy szybciej w porównaniu z 32 bitowym? Wydaje mi się , że tak bo całą liczbę procek "łyknie" za jednym razem a na 32 bitowym brał ją na dwa razy.

Liczenie zmiennoprzecinkowe to już osobna sprawa, zupełnie niezależna od "głównych" rejestrów procesora. Dlatego właśnie dla liczb całkowitych jest typ int, a dla rzeczywistych są typy float i (long) double ;) bo arytmetyką zmiennoprzecinkową zajmuje się osobny "koprocesor matematyczny" wbudowany w procki intela [dawniej był osobnym procesorem] oraz wszystkie te mechanizmy typu SSE.
To, że procesor jest 64-bitowy, ma wpływ tylko na arytmetykę liczb całkowitych [int].
« Ostatnia zmiana: Listopad 27, 2006, 23:08:05 wysłana przez gamecreator »

bies

  • Gość
# Listopad 27, 2006, 23:45:51
Jeśli już chcesz mnie obrażać, to:
Nikogo nie obrazam.

Cytat: st3tc
long long int  jest standardem (tyle ze dla C). Został dodany w C99
Owszem, jest, ale:
1. Co ma C do C++? Ja mówiłem o tym drugim.
2. nawet ów standard nie mówi ani słowa, że long long int ma mieć 64 bity. A oto co mówi:
Duzo. Ad 2 - standard nie moze narzucac ilosci bitow. Jezeli chcesz to wyjasnie Ci dlaczego.

"6.2.5. Types
(...)
4 There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.(28) The standard and extended signed integer types are collectively called signed integer types.(29)"

Nie tylko nie precyzuje rozmiarów, ale też nie precyzuje co jest większe od czego [jak robi to Standard C++].

Jaaaaassssnneee... Zeby bylo jasne - kolega cytuje ISO C. Hm ...
A wedlug Ciebie CO TO JEST ?
Cytuj
&#169;ISO/IEC ISO/IEC 9899:1999 (E)
5.2.4.2 Numerical limits
1 An implementation is required to document all the limits specified in this subclause,
which are specified in the headers <limits.h> and <float.h>. Additional limits are
specified in <stdint.h>.
Forward references: integer types <stdint.h> (7.18).
5.2.4.2.1 Sizes of integer types <limits.h>
1 The values given below shall be replaced by constant expressions suitable for use in #if
preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the
following shall be replaced by expressions that have the same type as would an
expression that is an object of the corresponding type converted according to the integer
promotions. Their implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.

— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // (27 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // (215 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 215 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216 1
— minimum value for an object of type int
INT_MIN -32767 // (215 1)
— maximum value for an object of type int
INT_MAX +32767 // 215 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 216 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // (231 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 1
— minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // (263 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 264 1

Z podkresleniem na shall be equal or greater

Cytat: st3tc
a C++ się nie załapał i tyle
Może taki był plan ;-)
A tak serio: Z tego co wiem, Standard ISO C++98 został ustanowiony w roku 1998, a standard C99 w roku 1999, więc na co C++ miał sie załapać jak został ustanowiony wcześniej?
A wlasnie to ze byl wczesniej ...

Cytat: st3tc
Teoria spiskowa z MS-em legła w gruzach ;-p
Hę? Ja piłem do tego, że pomału dojdzie tego, że będziemy pisać fucking unbelievable long long long long long int ;-J A manii wielkości Billa też chyba nikt nie zaprzeczy ;)
Nie. Nie piles do tego. Pozwol ze Cie zacytuje:

Cytuj
[Microsoft łamie tą zgodność stosując ten swój long long int

To nie jest "jego" long long int.

Cytat: st3tc
Pierwsze słyszę żeby standard *wymuszał* aby long był większy od int.
Nom, standard C99 rzeczywiście niczego nie wymusza, więc tam to wogóle już nic nie wiadomo i każdy producent kompilatora może robić jak chce. ISO C++ jednak conieco wymusza:
Bzdura. Patrz wklejke wyzej z ISO C99

"3.9.1. Fundamental types.
(...)
2. There are four signed integer types: "signed char", "short int", "int", "long int". In this list, each type provides at least as much storage, as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment(39); the other signed integer types are provided to meet special needs.
(...)
39) That is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>."
A gdybys doczytal C99 to bys znalazl o <limits.h>

A więc wymaga, by każdy następny typ z tej listy był conajmniej tak duży, jak jego poprzednik. Dlatego na pewno nie może być tak, by long long int czy long int były mniejsze niż czysty int.
Czy ja tak gdzies napisalem ???

Cytat: st3tc
nie sugerowałbym się kolejnymi dziwnymi wizjami Regedita jakoby int miał mieć 64 bity
A ile twoim zdaniem miałby mieć, by być zgodnym ze standardem? Jeśli czysty int miałby być wierny zasadzie, że jego rozmiar  "jest naturalnym rozmiarem podyktowanym przez środowisko wykonania" [czyli dla procków 64-bitowych: 64 bity], to żaden z poprzednio wymienionych typów nie mógłby być przeznaczony na wartości 32-bitowe [chyba że short int]. Jeśli zaś int miałby być 32-bitowy, to wtedy złamałby tą zasadę o użyciu rozmiaru najbardziej wygodnego dla procesora [czyli rozmiaru jego rejestrów i szyny danych].

Cytat: st3tc
Mówię naturalnie o WIN64. Na innych OS-ach/platformach należy sprawdzić pliki nagłówkowe/makra/sizeof-y (zresztą zawsze należy to robić ;) - int nie musi mieć 32 bit nawet na 32-bit OS-ku).
A to my rozmawiamy o platformie systemowej czy sprzętowej? AFAIK rozmiary typów podstawowych w pamięci zależą raczej od tej drugiej [oraz częściowo od kompilatora, jeśli robimy cross-compiling na inny sprzęt, ale to inna bajka].
Zapedziles sie. Standard precyzuje minimalne rozmiary. Nie narzuca rozmiaru bo nie moze. Mieszasz pojecie bitow do standardu. Od implementacji zalezy czy sobie zwiekszy i ile wiecej bitow przeznaczy. Tak wiec od tego momentu nalezy rozpatrywac go pod katem okreslonego OS-u

I tak:

Cytat: MSDN Library
When you use Visual C++ to create applications to run on a 64-bit Windows operating system, you should be aware of the following issues:

An int and a long are 32-bit values on 64-bit Windows operating systems. For programs that you plan to compile for 64-bit platforms, you should be careful not to assign pointers to 32-bit variables. Pointers are 64-bit on 64-bit platforms, and you will truncate the pointer value if you assign it to a 32-bit variable.

size_t, time_t, and ptrdiff_t are 64-bit values on 64-bit Windows operating systems.

time_t is a 32-bit value on 32-bit Windows operating systems in Visual C++ versions before Visual C++ 2005. In Visual C++ 2005 and later, time_t is a 64-bit integer by default. For more information, see Time Management.

You should be aware of where your code takes an int value and processes it as a size_t or time_t value. It is possible that the number could grow to be larger than a 32-bit number and data will be truncated when it is passed back to the int storage.

The %x (hex int format) printf modifier will not work as expected on a 64-bit Windows operating system. It will only operate on the first 32 bits of the value that is passed to it.

Use %I32x to display an integer on a Windows 32-bit operating system.

Use %I64x to display an integer on a Windows 64-bit operating system.

The %p (hex format for a pointer) will work as expected on a 64-bit Windows operating system.

Poza tym świat nie kończy się na Windows...
Serio ? Toz napisalem ze nalezy to sprawdzac.

To, że procesor jest 64-bitowy, ma wpływ tylko na arytmetykę liczb całkowitych [int].
Nie prawda. Ma rowniez olbrzymi wplyw na szybkosc dostepu do pamieci.


Offline gamecreator

  • Użytkownik
    • Game C++reator - strona o tworzeniu gier w C++

# Listopad 28, 2006, 02:17:35
Cytat: st3tc
Cytat: gamecreator
Jeśli już chcesz mnie obrażać, to:
Nikogo nie obrazam.
Znaczy twoim zdaniem określenie "pieprzysz głupoty" nie jest obraźliwe? To pewnie nie obrazisz się, gdy powiem, że ty pieprzysz głupoty ;)

Cytat: st3tc
Cytat: gamecreator
Cytat: st3tc
long long int  jest standardem (tyle ze dla C). Został dodany w C99
Owszem, jest, ale:
1. Co ma C do C++? Ja mówiłem o tym drugim.
Duzo.
Nie ma to jak rzeczowa konwersacja... -_-

Cytat: st3tc
Cytat: gamecreator
2. nawet ów standard nie mówi ani słowa, że long long int ma mieć 64 bity.
Standard nie moze narzucac ilosci bitow. Jezeli chcesz to wyjasnie Ci dlaczego.
Nie musisz, bo doskonale wiem dlaczego nie może, i to właśnie cały czas powtarzam, jako argument, że standard nie mówi, ile bitów mają mieć poszczególne typy. Zakłada jednak dolne granice, oraz który ma być większy od którego [lub równy]. Mówi też, że jedynie czystego typu int używa się dla podstawowego rozmiaru dyktowanego platformą sprzętową [rozmiarem rejestrów arytmetycznych procesora], najwygodniejszego do obliczeń dla procesora, a pozostałe typy są "do specjalnych celów".

Cytat: st3tc
Cytat: gamecreator
Nie tylko nie precyzuje rozmiarów, ale też nie precyzuje co jest większe od czego [jak robi to Standard C++].
Jaaaaassssnneee... Zeby bylo jasne - kolega cytuje ISO C.
A i owszem. Przecież sam wyjechałeś z tym ISO C99, to i cytuję z niego. W innym miejscu cytuję z ISO C++98, oraz z książki Stroustrupa "C++ programming language, 3rd eddition", bo ja z kolei mówię o C++.

Cytat: st3tc
A wedlug Ciebie CO TO JEST?
Cytuj
(...)Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.
To przecież nie oznacza, że int nie może mieć więcej niż 32 bity.

Cytat: st3tc
Z podkresleniem na shall be equal or greater
Nadal wszystko gra, bo jeśli by int miał 64 bity [a może, bo może mieć więcej niż tam podali], to nadal sizeof(long long int) >= sizeof(long int) >= sizeof(int). Niemożliwe byłoby jednak, by long zajmował mniej niż int, jak sugerował ayufan.

Cytat: st3tc
Cytat: gamecreator
Cytat: st3tc
Teoria spiskowa z MS-em legła w gruzach ;-p
Hę? Ja piłem do tego, że pomału dojdzie tego, że będziemy pisać fucking unbelievable long long long long long int ;-J A manii wielkości Billa też chyba nikt nie zaprzeczy ;)
Nie. Nie piles do tego.
Heh... kurna, następny telepata sie znalazł... znaczy lepiej ode mnie wiesz, do czego ja piłem? :P

Cytat: st3tc
Pozwol ze Cie zacytuje:
Cytuj
Microsoft łamie tą zgodność stosując ten swój long long int
To nie jest "jego" long long int.
No tak, sama nazwa typu nie jest "jego", ale przecież nie chodziło mi o nazwę, tylko o jego pomysł z niekonsekwencją wobec standardu. Poza tym albo C, albo C++. Jeśli ich kompilator ma maglować kod w C, to wtedy long long int przejdzie, ale nie może przejść w C++, jeśli nadal chcą się chwalić zgodnością ze standardem :P

Cytat: st3tc
Cytat: gamecreator
Cytat: st3tc
Pierwsze słyszę żeby standard *wymuszał* aby long był większy od int.
Nom, standard C99 rzeczywiście niczego nie wymusza, więc tam to wogóle już nic nie wiadomo i każdy producent kompilatora może robić jak chce. ISO C++ jednak conieco wymusza:
Bzdura. Patrz wklejke wyzej z ISO C99
Tu akurat masz trochę racji, nie doczytałem jakie są te graniczne wartości. Tylko nie wiem co to zmienia w kwestii 64 bitów, oraz tego, że każdy producent może sobie arbitralnie wybrać te wartości, byle były większe lub równe z podanymi. Mogę co najwyżej zwrócić honor, że jednak jest jakaś kolejność tych typów, choć nie podana bezpośrednio tak jak w ISO C++98.

Cytat: st3tc
Cytat: gamecreator
A więc wymaga, by każdy następny typ z tej listy był conajmniej tak duży, jak jego poprzednik. Dlatego na pewno nie może być tak, by long long int czy long int były mniejsze niż czysty int.
Czy ja tak gdzies napisalem???
A czy ja tylko z tobą tutaj gadam? [no w sumie ostatnio tak właśnie jest :P a wolałbym żeby jeszcze ktoś inny zabrał głos]. Akurat to z tym long to sugerował ayufan.

Cytat: st3tc
Cytat: gamecreator
A to my rozmawiamy o platformie systemowej czy sprzętowej? AFAIK rozmiary typów podstawowych w pamięci zależą raczej od tej drugiej [oraz częściowo od kompilatora, jeśli robimy cross-compiling na inny sprzęt, ale to inna bajka].
Zapedziles sie. Standard precyzuje minimalne rozmiary. Nie narzuca rozmiaru bo nie moze.
Przestań sugerować, że nie wiem takich rzeczy.

Cytat: st3tc
Mieszasz pojecie bitow do standardu.
Ja mieszam? :D  Przecież to nie ja wymyśliłem 32-bitowy int na 64-bitowym sprzęcie :P  Sam standard mówi o bitach, lecz w sensie podawania dolnych granic. I wiem doskonale, że nie wymaga, by dany typ miał tyle-a-tyle bitów, lecz mówi wyraźnie, do czego powinien typ int być stosowany, a to implikuje rozmiar w bitach dla programu wykonującego się na danej platformie sprzętowej, co jednak nie powinno zbytnio interesować programisty i nie powinien on robić zbędnych założeń co do ilości bitów ponad to, co gwarantuje mu standard.

Cytat: st3tc
Od implementacji zalezy czy sobie zwiekszy i ile wiecej bitow przeznaczy. Tak wiec od tego momentu nalezy rozpatrywac go pod katem okreslonego OS-u

Raczej konkretnej architektury procesora. Owszem, na 32-bitowych prockach intela możesz odpalać 16-bitowy system [np. MS-DOS] i kompilować sobie dla niego programy 16-bitowe w 16-bitowym kompilatorze, i mieć 16-bitowy int, jednak wtedy procek pracuje w trybie 16-bitowym [real mode] lub emuluje 16 bitów [virtual mode] i to ON dyktuje rozmiar słowa w systemie operacyjnym i jakiego słowa powinien używać kompilator.

Cytat: st3tc
Cytat: MSDN Library
When you use Visual C++
A when you don't use? :P Mówimy ogólnie o języku C/C++? czy o konkretnej implementacji? :P

Cytat: st3tc
Cytat: MSDN Library
An int and a long are 32-bit values on 64-bit Windows operating systems.
No i właśnie TU Microsoft nie spełnia standardu ISO C++98. Bo jeśli pracujemy w 64-bitowym Windows i na 64-bitowym procku, to skąd pomysł, że najwygodniejszym dla procka rozmiarem jest nadal 32 bity dla int? :P Dam głowę, że po prostu nie chciało im się przepisywać źle napisanego kodu Windowsa, w którym olewali standard i zakładali rozmiar 32 bitów dla int [a olewali równo, bo świadczą o tym wcześniejsze wersje ich kompilatorów]. A jeśli używają typu long long int dla tych 64 bitów w kompilatorze C++ [bo o nim tu mowa], to już na 100% łamią standard, bo nie ma w nim jak narazie takiego typu.

Cytat: st3tc
Cytat: MSDN Library
You should be aware of where your code takes an int value and processes it as a size_t or time_t value.
A pewnie że powinien być aware, bo takie przypisywanie to kręcenie bata na siebie samego :P

Cytat: st3tc
Cytat: MSDN Library
It is possible that the number could grow to be larger than a 32-bit number and data will be truncated when it is passed back to the int storage.
A to też mONdre :P Wyjąć 32-bitową wartość, wsadzić do 64-bitowego rejestru, podliczyć, obciąć do 32 bitów i wsadzić spowrotem. A gdyby od razu dali że int ma tyle ile ma mieć, to by nie trzeba było tyle się przy tym nakombinować. AFAIK instrukcje wymuszające użycie części rejestrów procesora, zamiast całości, wymagają zwykle dorzucania prefixów przed instrukcjami. Czy przez takie kombinacje kompilator Microsoftu nie spowolni operacji na intach?

Cytat: st3tc
Cytat: MSDN Library
The %x (hex int format) printf modifier will not work as expected on a 64-bit Windows operating system. It will only operate on the first 32 bits of the value that is passed to it.
Czyli tego też im sie nie chciało przepisać na 64 bity ;-J

Cytat: st3tc
Cytat: MSDN Library
Use %I32x to display an integer on a Windows 32-bit operating system. Use %I64x to display an integer on a Windows 64-bit operating system.
Hmm... a co na to standard C? :)

Ogólnie to zaczynam czaić o czym mówił Bies, mówiąc że Windows sobie radzi z 64-ma bitami "tak sobie"...

Cytat: st3tc
Cytat: gamecreator
Poza tym świat nie kończy się na Windows...
Serio ? Toz napisalem ze nalezy to sprawdzac.
Ano napisałeś, tylko dalej nie wiem co to sprawdzanie ma wspólnego z Windows ;)  Już prędzej z implementacją kompilatora i architekturą maszyny, dla jakiej jest on przeznaczony.

Cytat: st3tc
Cytat: gamecreator
To, że procesor jest 64-bitowy, ma wpływ tylko na arytmetykę liczb całkowitych [int].
Nie prawda. Ma rowniez olbrzymi wplyw na szybkosc dostepu do pamieci.
OK, zgodzę się, ale przyjrzyj się na co odpowiadałem, i moje "tylko" oznaczało tam, że nie ma wpływu na arytmetykę zmiennoprzecinkową.

Ogólnie ja to wszystko widzę tak: Typ int został stworzony tak, by ZAWSZE odzwierciedlał naturalny rozmiar rejestrów arytmetyki liczb całkowitych w procesorze [czyli słowa maszynowego]. Na prockach, które miały 16-bitowe słowo, int miał 16 bitów. Na prockach z 32-bitowym słowem maszynowym [np. IA-32] typ int miał 32 bity. Według tej zasady na maszynach 64-bitowych typ int powinien mieć 64 bity i Regedit miał rację, zanim zbiłeś go z tropu. Nie ma jej natomiast Microsoft, dając 32-bitowe inty, chyba że chce to jakoś emulować, a nie używać sprzętowych rejestrów. Bo możliwe jest zaimplementowanie kompilatora w taki sposób na procku 32-bitowym, żeby int miał 32 bity [jako najbardziej wygodny rozmiar dla tego procka], ale aby umożliwić obliczenia na większych liczbach [mniej wygodne dla procka], użyć do tego celu typu long int i mapować go jako dwa słowa maszynowe. Podobną technikę stosowały niektóre stare kompilatory 16-bitowe, by na 16-bitowym procku móć liczyć sobie 32-bitowe liczby. Było to mniej wygodne dla procka, bo musiał pobierać i liczyć każde słowo osobno i uwzględniać flagę przeniesienia, ale możliwe do wykonania, a także zgodne ze standardem. Właśnie po to zostały stworzone typy takie jak long int i short int: do specjalnych celów [a liczenie 32-bitowych liczb na 16-bitowej architekturze to BYŁO specjalne zastosowanie ;)].
Tak więc programista gdy chce wykonywać obliczenia na słowach maszynowych oferowanych przez daną architekturę [bez wzlędu na to jaki te słowa mają rozmiar], używa typu int. A gdy ma jakieś specjalne kaprysy co do rozmiaru, może np. użyć short int by dać kompilatorowi sygnał, że nie potrzebuje całego rejestru procesora i chce oszczędzić na rozmiarze - ma wtedy zagwarantowane 16 bitów, ale nie ma zagwarantowane że short int rzeczywiście zajmie mniej niż int ;)  To coś jak użycie register: dajesz sygnał że o ile to możliwe, kompilator powinien użyć rejestru zamiast komórki pamięci, choć wcale nie musi ;)

Podsumowując: jeśli Microsoft na platformie 64-bitowej definiuje int jako 32-bitową wartość a long int czy long long int jako 64-bitową, to znaczy że jego zdaniem naturalne dla 64-bitowego procka są nadal 32 bity, a 64 bity to "specjalne zastosowania" ;-J
« Ostatnia zmiana: Listopad 28, 2006, 02:26:59 wysłana przez gamecreator »

bies

  • Gość
# Listopad 28, 2006, 12:50:47
Odpowiedni wpis w standardzie:
Cytat: ISO/IEC 14882:1998(E) 3.9.1.2
There are four signed integer types: "signed char", "short int", "int", and "long int." In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment 39) ; the other signed integer types are provided to meet special needs.

Teraz popatrzmy na przypis 39:
Cytat: ISO/IEC 14882:1998(E) 3.9.1.2
39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.

Czyli implementacja Windows64 jest głupia ale nie explicite niezgodna. Po prostu natural size suggested by the architecture of the execution environment (podkreślam środowisko a nie CPU) dla Win64 to 32-bity.
« Ostatnia zmiana: Listopad 28, 2006, 12:56:00 wysłana przez bies »

Offline _Flak

  • Użytkownik

# Listopad 29, 2006, 11:18:37
Cytat: bies
Czyli implementacja Windows64 jest głupia ale nie explicite niezgodna. Po prostu natural size suggested by the architecture of the execution environment (podkre&para;lam &para;rodowisko a nie CPU) dla Win64 to 32-bity.

w Software Optimization Guide od AMD  - mozna znaleźć sugestie, aby w przypadku korzystania z arytmetyki 32-bitowej uzywać jednak starych rejestrów 32-bitowych. W samym systemie poza adresowaniem/indeksowaniem 64-bitowymi rejestrami, konieczność stosowania arytmetyki 64-bitowej to raczej przypadki szczególne a nie ogólne -> stąd można zaryzykować i wyprowadzić nieco naciąganą tezę, że MS współpracując z AMD takie własnie rozwiązanie przyjął, stąd niekoniecznie implementacja jest "głupia".

Offline Megabyte

  • Użytkownik

# Listopad 29, 2006, 16:52:22
Ja tylko dodam że kompilując program w g++ pod 64bit Linuksem int też ma rozmiar 32bit