Windows nie będzie działać na platformie Moorestown

1. pierwszy! 8) od 7:58am (autor: infinity | data: 6/06/10 | godz.: 21:23)
   News'y w niedziele?
   LOL
   za duzo czekania do poniedzialku
   LOL
   
   
2. ??? (autor: nudek | data: 7/06/10 | godz.: 12:43)
   "Pierwsze procesory zbudowane w oparciu o architekturę x86 pojawiły się na rynku kilka lat temu"
   Kilka lat? Wydawało mi się, że arch. x86 jest znacznie starsza...
   
   
3. @nudek (autor: Takeya | data: 7/06/10 | godz.: 13:00)
   tak, x86 zaczelo sie od procesora 8086, czyli rok 1978.
   kilka lat, jakby nie patrzec :)
   
   
4. czepiacei się (autor: pit808 | data: 7/06/10 | godz.: 14:17)
   ten sektor rynku jest tak samo rozwijany jak lotnictwo, czyli idea z lat 40-50 jest udoskonalana i nie pozwala na kreowanie nowych technologii.
   
   Liczę na to że wreszcie zauważy się konkurencyjne rozwiązania RISC i ARM.
   
   To że x86 zaczyna być kulą u nogi pokazuje to, że GPU są kilka razy bardziej wydajne w obliczeniach od CPU.
   To że GPU musi wspierać CPU w obliczeniach a nie na odwrót, jest porażką x86.
   
   Już po woli widać schyłek monopolistycznego tandemu WINDOWS i x86. Teraz będzie czas na znalezienie następcy. Zobaczymy co nowego przyniesie 5-10 lat.
   
   
5. o... (autor: Aamitoza | data: 7/06/10 | godz.: 14:26)
   To jedyna wątpliwa zaleta jaką miał mieć ten procesor (czyli możliwość odpalenia windowsa i dostęp do ogromnej bazy aplikacji) została właśnie jemu odebrana. Innymi słowy w tej chwili procesor w stosunku do cortexa A9 nie ma żadnych zalet.
   
   
6. No proszę... (autor: Sandacz | data: 7/06/10 | godz.: 14:43)
   Ciekawe co na to forumowi trolle - Intel powoli porzuca standard który sam stworzył i który według niektórych tu obecnych jest ostatecznym intelektualnym tryumfem ludzkości, tylko to 'wstrętne' AMD ciągle przy tym cudzie coś majstruje - a to rozszerza na 64-bit, a to zaczyna łączyć z GPU...
   
   
7. Czy ja tam dobrze widzę? (autor: Teriusz | data: 7/06/10 | godz.: 14:44)
   Solid State Disk Controller? Czyli natywne wsparcie dla SSD. To może być spory atut dla intelowskich układów.
   
   
8. Wedelek! Tradycji musiało stać się zadość... (autor: marekl | data: 7/06/10 | godz.: 15:05)
   ... co post to błąd :P
   
   "przeszły liczne zmiany w, ale nadal można". Po co "w", w tym poście?
   
   
9. @Sandacz (autor: kubaswielgus | data: 7/06/10 | godz.: 15:15)
   No właśnie, że nie. Będzie można odpalić aplikacje w Windowsa:
   http://pda.pl/...orestown_jednak_ma_asa_w_rekawie/
   
   
10. Do redakcji (autor: Teriusz | data: 7/06/10 | godz.: 15:15)
    Krzywo, prosto, byle ostro? A wystarczyło by tylko 5 minut na przeczytanie tego co się napisało i szybkie poprawienie.
    
    
11. @Kuba (autor: Sandacz | data: 7/06/10 | godz.: 15:20)
    No cóż fakt jednak pozostanie faktem, że powoli nadchodzi zmierzch x86.
    
    
12. @Sandacz (autor: Teriusz | data: 7/06/10 | godz.: 15:29)
    Ano czasami następuje ten zmierzch tytanów. Nastaje nowa era. Era RISC, ARM, SoC i APU. x86 z czasem z niknie z rynku, albo już nie będzie tym samym czym było wcześniej.
    
    
13. x86 będzie mniej uniwersalne (autor: Qjanusz | data: 7/06/10 | godz.: 15:58)
    ale z rynku na pewno nie zniknie.
    
    
14. @Teriusz (autor: Remek | data: 7/06/10 | godz.: 16:14)
    Najpierw popraw swoją wypowiedź. Widzę w niej co najmniej dwa błędy.
    
    
15. haha (autor: morgi | data: 7/06/10 | godz.: 17:08)
    cortex a8 robi w gatki przy Atomie, a oni jakies bajki o a9 opowiadaja. Oczywiscie arm to stare dzieje, oczywiscie x86 to tez bardzo dluga historia i mowa o duzych zmianach to wariactwo, a raczej utopia. Po pierwsze arm to golec softwarowy i niechlujstwo architektury, a x86 oczywiscie nastawione na high perf., ale co szybciej sie zmieni, oczywiscie wierze i juz to widac, ze x86 w ultra low power niz arm w wydajnego potwora, juz inne risc padly w boju bo tez mialy takie zamiary.
    
    
16. Przestań palić te zioła... (autor: Kenjiro | data: 7/06/10 | godz.: 17:19)
    Bo niestety X86 to jedna z najgorszych i najbardziej niechlujnych architektur. Nie ośmieszaj się już bardziej, panie Utopia.
    
    
17. @Remek (autor: Teriusz | data: 7/06/10 | godz.: 18:57)
    Ok, poprawię, tylko powiedz mi gdzie jest ten przycisk "Edytuj" :D W przeciwieństwie do redakcji nie widzę tutaj możliwości korekcji wypowiedzi.
    Rozumiesz do czego piję?
    
    
18. @Up (autor: AmigaPPC | data: 7/06/10 | godz.: 19:00)
    dobrze prawisz :)
    
    
19. @morgi (autor: Teriusz | data: 7/06/10 | godz.: 19:01)
    Lepiej powiedz skąd bierzesz to zioło, bo musi być naprawdę dobre, skoro można tak świetnie oderwać się od rzeczywistości.
    
    
20. HAHA! :D (autor: Blazakov | data: 7/06/10 | godz.: 19:14)
    Tak jest! Wesoło wracamy do ery wojen międzyplatformowych! Jeszcze brakuje reaktywacji i powrotu w wielkim stylu Amigi (na co szanse są małe ale są) i znowu zacznie się zabawa! :D
    
    ARM vs x86 vs RISC vs Soc vs konsole vs Apple vs kto wie co jeszcze. Na każdym inne systemy, na każdym inne oprogramowanie, sprzętu znowu nie będą kompatybilne, "domowi informatycy" po erze spokoju kiedy ludzie jako-tako obeznali się za sprzętem znowu staną się niezastąpieni, znowu dzieciaki-nerdy w podstawówkach i gimnazjach będą miały tematy do wojenek, znowu nie jedna firma wybije się na przepisywaniu oprogramowania z jednej platformy na inną.
    
    A laptopy za 400zł na ARMach obsługiwanych przez Androidy do kupienia na allegro są pierwszymi jaskółkami. Wracamy do starego dobrego bagienka. :)
    
    FUCK YEAH! :D
    
    
21. morguś (autor: Aamitoza | data: 7/06/10 | godz.: 19:16)
    Power7 8core
    264.96 GFLOPS w zaokrągleniu 33GFLOPS na rdzeń.
    
    core i7 X6
    107.55 GFLOPS - w zaokrągleniu 18 GFLOPS na rdzeń. (mniej więcej taką wydajność per core posiada najmocniejszy Power6)
    
    Tak wygląda konfrontacja RISC z x86 ;)
    
    W przypadku Atoma i cortexa a9 (2rdzeniowym) wygląda podobnie.
    
    Cortex A9 2 rdzenie 2Ghz - 10.000 DMIPS - TDP 1,9W
    na 800Mhz wydajność 4,000 DMIPS i TDP 0,5W.
    
    Atom 1,6Ghz jeden rdzeń, 3.300 DMIPS TDP 2W. Na 800MHz 1660 DMIPS 0,65W.
    
    A jak to będzie wyglądało w Moorestownie to dopiero się przekonamy, jednak wzrostu wydajności spodziewać się nie można, a jedynie spadek TDP).
    
    
22. @Blazakov (autor: Teriusz | data: 7/06/10 | godz.: 19:24)
    Bo to wszystko rozbija się o głupią rywalizację. Kto lepszy, kto ładniejszy, kto szybszy. Tylko ludzie nie potrafią zrozumieć, że każda inność sprawdza się w różnych dziedzinach. To takie udowodnianie wyższości widelca nad łyżką.
    
    
23. @Teriusz (autor: Remek | data: 7/06/10 | godz.: 19:37)
    Rozumiem.
    
    A wystarczyłoby tylko 10 sekund na przeczytanie tego, co się napisało.
    
    ... przed wysłaniem :P
    
    
24. @Remek (autor: Teriusz | data: 7/06/10 | godz.: 19:57)
    W tym aspekcie nie będę się kłócił. Popieram w 100%, bo masz rację. Nie zastosowałem się do swojej własnej wypowiedzi. Potrafię się przyznać do błędu. Jednak to, że go popełniłem nie znaczy, moje zdanie traci na aktualności.
    
    
25. @Teriusz (autor: Blazakov | data: 7/06/10 | godz.: 20:03)
    Myslisz się. Tu rozchodzi się o kasę.
    
    Wszystko było fajnie podczas ery dominacji x86, Intel & M$ przywłaszczyli sobie większość rynku i mieliśmy spokojną stagnację.
    
    Teraz weszły cztery kwestie.
    
    1)Intel zaprzestał praktyk monopolistycznych. Musi się teraz liczyć z AMD nie tylko na papierze.
    2)Moda na sprzęty mobilne. Teraz nie liczy się już moc, bo nawet telefon komórkowy pozawala na przeglądanie internetu, a moc ma wystarczającą na większość zastosowań typu office)
    3)Pojawiła się konkurencja ze strony małych sprzętów mobilnych. iPad jest przykładem że tego typu sprzęt może zagrozić - teoretycznie - sprzętom na x86
    4)AMD ze swoim CPU+GPU który może okazać się niezłym przełomem.
    
    I co ma intel teraz zrobić? Czasy się zmieniły, nie są głupi. Muszą nadąrzać żeby nie wypaść z rynku.
    
    BTW, co za idiota wymyślił przycisk kasuj?! Piszę to już drugi raz...
    
    
26. Aamitoza (autor: morgi | data: 7/06/10 | godz.: 20:14)
    ibm tez moze sie pochwalic nawet wiekszymi 'mocami', ktore da sie puscic na normalnych syntestykach, a na czym zapuscic arm?
    arm chwali sie DMIPS, bo tylko tam maja cos wspolnego z realna wydajnoscia, cala reszta to po prostu dno.
    'An issue to watch out for when comparing ARM CPUs against x86 microprocessors is the size of binary files. In the past, RISC machines have produced larger executables because more instructions are often necessary than with CISC-derived systems. If binary sizes differ significantly, this places greater pressure on cache sizes, RAM size and memory bandwidth. With today’s terabyte-scale mass storage devices, increased binary bloat is not significant since the vast majority of drive space is consumed by video and other multimedia data.'
    http://www.brightsideofnews.com/...6.aspx?pageid=3
    
    
27. @Blazakov (autor: Teriusz | data: 7/06/10 | godz.: 20:24)
    Może jednak powiesz do jakiej mojej wypowiedzi, lub jej części, się odnosisz.
    
    
28. Morgi (autor: Aamitoza | data: 7/06/10 | godz.: 20:27)
    Wg wyników z Twojego linka, gdyby znalazł się tam 2 rdzeniowy 1Ghz cortex A9 atom by przegrał w większości testów. - raz że dodatkowy rdzeń, dwa, że A9 jest 25% szybszy od A8 i trzy - dodatkowe 20% z wyższego zegara. No i aby było zabawniej - taki A9 nadal pobierał by mniej od atoma.
    
    
29. ... (autor: Aamitoza | data: 7/06/10 | godz.: 20:31)
    Nie mówiąc o tym, że można by dać do testu 2Ghz A9 który ma podobne TDP do atoma. - Gdzie wtedy jest atom, skoro w większości testów jest od 1,5 do 3 razy szybszy od niżej taktowanego A8? Takie małe podliczenie. - 20% z wyższego zegara, 25% z wyższej wydajności samego rdzenia i jeszcze to x2 bo mamy dodatkowy rdzeń. Tym sposobem wszędzie gdzie wynik A8 na wykresach wynosił 1 (czyli punkt odniesienie) dla takiego A9 wynosił by 3x więcej. A dla 2Ghz modelu może nawet 6x więcej.
    
    
30. @Blazakov (autor: Teriusz | data: 7/06/10 | godz.: 20:44)
    W czym takim się mylę?
    
    Co do twojej wypowiedzi #25.
    ad 1.
    Co mają praktyki monopolistyczne intela w stosunku do amd do pogarszającej się wydajności architektury x86 względem arch. RISC?
    ad 2.
    O jakim sprzęcie mobilnym konkretnie mowa? Jeżeli chodzi o laptopy to wydajność zawsze grała rolę. Co do komórek to wymień mi telefony oparte na x86. W komórka na starcie x86 nie miało racji bytu i to od bardzo dawna.
    ad 4.
    APU jeszcze nie wyszło, ale już jest mowa, że obliczenia zmiennoprzecinkowe będą wykonywane przez wewnętrzne GPU. Brak wykorzystania x86 go tych obliczeń jest już oznaką jej pewnego upadku i rezygnacji w części z tej architektury.
    
    
31. Teriusz (autor: Aamitoza | data: 7/06/10 | godz.: 21:03)
    "APU jeszcze nie wyszło, ale już jest mowa, że obliczenia zmiennoprzecinkowe będą wykonywane przez wewnętrzne GPU."
    
    Jak ktoś napisze program w openCL ;)
    
    
32. Aamitoza (autor: morgi | data: 7/06/10 | godz.: 21:05)
    Oczywiscie, mozna tam wstawic rowniez 2c/4t Atom i bedzie to samo, przeciez a9 to piesn przyszlosci, bo szukaja dobrych fabow i niskich procesow. Tak wlasnie wypadaja risc, wychodza z podziemi, ale spojrzmy na to jak wypada perf/watt
    i co najwazniejsze jaki jest support, bo gdyby bylo tak rozowo to Intel spokojnie mialby na to swoj sposob a w konsekwencji swoje czysto riscowe propozycje.
    
    
33. morgi (autor: Aamitoza | data: 7/06/10 | godz.: 21:23)
    Więc tegra2 to także pieśń przyszłości, co? ;)
    
    Jasne, że można. Tylko taki atom ma już ogromne TDP. A 2Ghz 2rdzeniowy A9 pobiera 1,9W i jest około 6x szybszy od 800mhz A8 (800mhz A8 pobiera 0,5W i jest około 2,5x szybszy od A8 o tym samym zegarze) - i to wszystko w 40nm, a mamy przed sobą 28nm z high-k od globala.
    
    
34. ... (autor: Aamitoza | data: 7/06/10 | godz.: 21:24)
    **800mhz A9 pobiera 0,5W i jest około 2,5x szybszy od A8 o tym samym zegarze)
    
    
35. arm golec software'owy? (autor: XTC | data: 7/06/10 | godz.: 21:47)
    chyba tylko win ma takie problemy, linuks i macos jakoś nie mają takich problemów.
    
    
36. Aamitoza (autor: morgi | data: 8/06/10 | godz.: 09:57)
    Ale ktora wersja na ktorym procesie, bo ta docelowa jest w planach.
    Skalowanie o ile mi wiadomo a8 jest 2,5x jak podniesiesz zegarek do 2Ghz, ale znowu wowczas to nalezaloby zmierzyc tdp i wydajnosc, bo w tej chwili Atom rozbiera a8, a od a9 cudow i nowych superrozszerzen nikt nie oczekuje.
    
    
37. XTC (autor: morgi | data: 8/06/10 | godz.: 10:04)
    Taaa, linux i jabol maja problem platform multimedialnych z naciskiem na rozrywkowe z glowy, akceleracje 3d z glowy to moga sie skupic na otoczce.
    
    
38. morgi (autor: Aamitoza | data: 8/06/10 | godz.: 10:48)
    Już Ci napisałem - 2 rdzeniowy A9 w 40nm ma TDP 1,9W. Poza tym A9 jest dodatkowo szybszy zegar w zegar od A8 o 25%. Na 1Ghz taki 2 rdzeniowy A9 pobiera 0,5W i dokładnie taki układ jest w tegrze2. Atom na 800mhz ma TDP 0.65W - i taki układ na pewno był by słabszy o tegry2.
    
    
39. @Teriusz (autor: Blazakov | data: 8/06/10 | godz.: 10:55)
    Odnosiłem się do słów "Bo to wszystko rozbija się o głupią rywalizację.". Przepraszam za niedomówienie.
    
    1)To, że intel nie może dłużej bezkarnie brnąc i promować jedynie x86 olewając wszystko inne, bo może zostać w skrajnym wypadku nawet wygryziony. Wcześniej mógł.
    2)No właśnie. :) Pojawia się konkurencja w postaci telefonów opartych NIE na x86 i hybryd (przykład tabletów internetowych) które mogą przewrócić cały rynek mało wydajnych energooszczędnych komputerów do góry nogami. Atom w takim wypadku traci rację bytu, bo kto kupi 2x droższy sprzęt jeżeli funkcjonalność której potrzebuje jest dostępna w niższej cenie?
    4)Nawet jeżeli nic z tego nie będzie, to szlaki powoli zostają przecierane. Mogę dać inny przykład - CUDAczna nV.
    
    
40. x86 (autor: Nohrabia | data: 8/06/10 | godz.: 11:55)
    może i jest troszkę przestarzałe, ale zastanawia mnie, jak wyglądała by...konkurencja? Zastanówmy, wybierzemy sprzęt na architekturze A czy B? Na tej lepiej się pracuje bo stabilniej, na tej ponoć lepiej się gra...ale znów tego Bardzo Ważnego Programu nie mam na A a tylko na B...
    Poza tym ta nowa architektura, która miała by pokonać x86 musiała by pozwolić na odpalanie softu ze swojego poprzednika.
    Ktoś mi to naświetli, bo się gubię :D
    
    
41. @Nohrabia (autor: Blazakov | data: 8/06/10 | godz.: 12:26)
    To nic nowego. Jak nie pamiętasz tych czasów, zapytaj się geeków ~25+ letnich o wojny Amiga vs PC vs Atari vs C64. :)
    
    
42. ... (autor: pawel.xxx | data: 8/06/10 | godz.: 12:42)
    Z tego co czytałem na innym serwisie to ta ten brak wsparcia dla windows ma się sprowadzać do tego że:
    1. Nie będzie BIOS-u
    2. Intel nie wyda sterowników dla windows
    
    Obydwa problemy są do obejścia. Zadaniem sterowników jest stworzenie HAL dla systemu. Jeśli MS uzna że chce by na z600 działał windows może stworzyć bibliotekę hal.dll dla systemów Z600.
    Implementacja biosu także powinna być możliwa - przecież wywołania przerwań biosu można traktować jako interfejsy programistyczne. Więc specyfikacja i implementacja są rozdzielone.
    
    Problemem nie do przejścia będą natomiast bezpośrednie odwołania do zasobów sprzętowych które nie będą fizycznie obecne w langwell. Na cale szczęście aplikacje bezpośrednio operujące na kontrolerach to już zamierzchła przeszłość (20-30lat) lub ćwiczenia programistyczne na zajęciach z informatyki
    
    
    Co do dyskusji związanej z architekturą RISC/ARM vs x86 to jest w niej sporo przekłamań lub niedopowiedzeń. Piszecie o ARM-ach jako niesamowicie wydajnych i energooszczędnych, a póki co to najwydajniejszym SOC ARM jest chyba Tegra 2 - cortex A9 2 rdzenie 1GHz. Od atoma n270 będzie ona wydajniejsza, ale od atoma 330 już nie. Przy tym działający układ pobiera znacznie więcej energii niż wynikałoby ze specyfikacji na ARM.com. A co z pozostałymi CPU x86 jakie układy ARM mają szansę z nimi konkurować?
    Szansą na odejście od przestarzałej i kłopotliwej listy instrukcji x86 było wprowadzenie rozszerzeń 64 bitowych bo po raz pierwszy od kilkunastu lat nie było konieczne zachowanie wstecznej kompatybilności. Niestety AMD zaproponowało a Intel podchwycił pomysł by ta zmiana była kolejnym sztukowaniem x86.
    
    
43. pawel.xxx (autor: Aamitoza | data: 8/06/10 | godz.: 13:41)
    "póki co to najwydajniejszym SOC ARM jest chyba Tegra 2 - cortex A9 2 rdzenie 1GHz. Od atoma n270 będzie ona wydajniejsza, ale od atoma 330 już nie"
    
    Dobrze, a teraz jakie TDP ma jednordzeniowy atom, a jakie dwurdzeniowy? Punkt nastepny - ta tegra2 trafi do tabletów i telefonów - czy 2 rdzeniowy atom ma na to jakiekolwiek szanse? No chyba nie bardzo (nawet w netbookahc bywa rzadko) - a czy jednordzeniowy atom 1,6Ghz ma? prawdopodobnie także nie ma, bo układy w telefonach i tabletach muszą mieć niskie TDP, a 5W dla atoma z gpu, to trochę dużo. Konkurentem dla takiego atoma mogła by być tegra2 ale podkręcona do 2 Ghz.
    
    
44. @pawel.xxx (autor: Promilus | data: 8/06/10 | godz.: 13:58)
    "Szansą na odejście od przestarzałej i kłopotliwej listy instrukcji x86 było wprowadzenie rozszerzeń 64 bitowych bo po raz pierwszy od kilkunastu lat nie było konieczne zachowanie wstecznej kompatybilności" Skoro rozszerzenie to zgodność musiała być, choćby po to by można było sprzętowo na 64 bitowym systemie obsługiwać 32 bitowy kod. Intel nie ukrywał, że 64 bit dla desktop wcale go nie interesowało i spokojnie 32 bit do 2010 by trzaskał. AMD niejako wymusiło zmianę jego podejścia. Nawet PPC łagodnie przeszło na 64 bit, a ty byś chciał radykalnych zmian. Trzeba było napisać do intela z pomysłem na własne rozszerzenie, a nie narzekać teraz.
    
    
45. Aamitoza (autor: morgi | data: 8/06/10 | godz.: 14:39)
    Mowie ci sprawdz sobie ten test, w nim ten arm bierze juz wiecej niz wynika tdp, a wydajnosc jest znaaaacznie nizsza od x86, nie mowiac juz o przeliczeniu tego wydajnosc/watt.
    
    
46. Nohrabia (autor: morgi | data: 8/06/10 | godz.: 14:58)
    Tam to wyglada w arm, totalny miszmasz, roznorakie rozszerzenia, zmiany w obrebie simd, roznej dlugosci potoki wykonawcze, doczepianie bez glebokich przemyslen i problemy ze wsteczna kompatybilnoscia. U x86 to jest sila, ze pakiety rozszerzen zawsze odwoluja sie do przeszlych osiagniec i to warunkowo musi byc zachowana ciaglosc, a zmiany sa wolne z racji pozycji, zastosowania i popularnosci, ale zasadne.
    
    
47. @morgi (autor: Promilus | data: 8/06/10 | godz.: 15:23)
    "zmiany w obrebie simd, roznej dlugosci potoki wykonawcze"
    Aha, a w x86 to tego nie ma? Weź nie pierdol bez sensu.
    
    
48. Promilus (autor: morgi | data: 8/06/10 | godz.: 18:05)
    Nie ma i nie bedzie, bo taka ruletka po rusku czy angielsku to raz przejdzie a raz padnie, tu trzeba solidnosci i nowoczesnosci.
    
    
49. @morgi (autor: Promilus | data: 8/06/10 | godz.: 20:59)
    To seria pytań za 100pkt
    1. Ile potoków miał Pentium III, ile Pentium 4 (poszczególne rdzenie), a ile ma Core 2?
    2. Czy skoro AVX to SIMD to nie powinien być kompatybilny z SSE? ;) Bo nie jest.
    3. ile int, load&store operacji mogą w jednym takcie wykonać P III, P4, Core 2? Czy to są jednakowe wartości?
    
    Noo...odpowiedzi na te pytania świadczą też o tym czy morguś jest zakłamanym hipokrytą czy nie ;)
    
    
50. @Promilus (autor: pawel.xxx | data: 8/06/10 | godz.: 21:04)
    Choć procesory AMD64 mogą pracować w trybach 32bitowych to to w druga stronę nie jest to możliwe.
    Wprowadzając AMD64 zmieniono model programowy który był wykorzystywany od 1983r.
    Wprowadzono nową listę instrukcji dla trybu 64bitowego która nie może być wykonywana na starszych CPU.
    I właśnie o tę nową listę instrukcji mi chodzi.
    Skoro te nowe instrukcje i tak nie sa wstecznie kompatybilne to nie było powodu by zostawiać w instrukcje operujące na lokacjach w pamięci, nie było potrzeby by zachowywać wyróżniony rejestr akumulatora. Cuż złego by sie stało gdyby z instrukcji
    Add reg, reg
    Add reg, mem
    Add mem, reg
    Add reg, const
    Add mem const
    gdzie reg jest rejestrem 64 bitowym
    pozbyto się instrukcji operujących na lokacjach w pamięci? Cóż złego by się stało gdyby zredukowano listę instrukcji tak jak to zrobiono w prapoczątkach RISC?
    Nie było żadnych przeciwwskazań by nowa lista instrukcji nie mogła być klasy RISC. A układ dekodera byłby zdecydowanie prostszy.
    Te zmiany wcale nie byłyby większe niż przy obecnej formie AMD64.
    
    
51. @ Aamitoza (autor: pawel.xxx | data: 8/06/10 | godz.: 21:15)
    Póki co to tegra2 nie trafiła jeszcze do żadnego telefonu. Czy trafi i w jakiej konfiguracji to zobaczymy. To nic pewnego ale obiło mi się o uszy ze tegra2 ma TDP 5W czyli atomy wcale nie wypadałyby tak blado z530 + US15W ma 4.3W
    Tyle że atomy sa dostępne od 2 lat
    
    
52. @pawel.xxx (autor: Promilus | data: 8/06/10 | godz.: 21:25)
    No i co z tego? Przecież mowa o kompatybilności WSTECZNEJ więc jakoś mnie nie dziwi, że K7 nie wykona kodu K8 ;) Tak samo K7 nie wykona kodu optymalizowanego pod 32 bitowego P4 z SSE2. A to już niezgodność w obrębie 32 bitowych maszyn :]
    Poza tym powiedziałbym że ta zmiana modelu programowego była dosyć prosta i naturalna, ot więcej rejestrów i szerszych z 'starymi' rejestrami w młodszej części nowych. To rozwiązanie jest zupełnie kopią tego co intel zrobił wchodząc w 32 bity. Co do listy rozkazów - nie mam pojęcia dlaczego zrobiono to w ten sposób, może chodziło o proste dostosowanie kompilatorów do AMD64, a może o coś innego, nie wnikam - w firmie pracują znacznie bardziej obeznani ode mnie ludzie i nie mam zamiaru dedukować czemu zrobili to tak a nie inaczej. Pozostaje jedynie to co robisz Ty - propozycja jak można by to zrobić inaczej.
    Może chodziło o mikro i makro fuzje, a może o coś zupełnie innego, nie interesuje mnie to. Nikt w ASMie specjalnie nie dłubie na x86 czy x86-64 więc dla programisty jest to zasadniczo niezbyt ważne. Bardziej radykalne zmiany mogłyby się spotkać z bojkotem ze strony intela i kto wtedy by używał rozszerzenia AMD?
    
    
53. Promilus (autor: morgi | data: 9/06/10 | godz.: 11:12)
    Co do AVX to zostalo to dawno wytlumaczone, bez tekstow fanowskich, ze 'nie ma FMA, bez swobodnego przejscia SSE/AVX':
    '
    http://software.intel.com/...ed-vector-extensions/
    'Those functions that have not been hand-optimized have been compiler-optimized using the Intel Compiler /QxG switch (enable AVX optimization) to take advantage of the AVX "3rd operand" feature. Further performance improvements are achieved by virtue of an AVX ABI (application binary interface) feature that inserts the special AVX "vzeroupper" instruction after any function with AVX code to eliminate AVX->SSE transition penalties.'
    
    
54. @morgi (autor: Promilus | data: 9/06/10 | godz.: 11:18)
    Czy AVX to forma SIMD czy dupablada? Są zmiany w SIMD i niekompatybilności ;) Niekompatybilności które szumnie rozgłaszasz w przypadku ARM a ukrywasz w przypadku x86 ;)
    Rekompilacja kodu źródłowego zazwyczaj usuwa sporo niedogodności bo już całą zabawa jest w samym kompilerze, ale czy jakakolwiek aplikacja bez rekompilacji wykorzysta w jakimkolwiek stopniu AVX? No właśnie...nie. Tak samo z neonem w ARM :)
    
    
55. Promilus (autor: morgi | data: 9/06/10 | godz.: 11:30)
    AVX to kolejne rozszerzenie simd, a wlasciwie update ponad 100 istniejacych sse do wektora 256bit, bez fma i z taka kompatybilnoscia, aby roznica miedzy wzrostem wydajnosci flops a kosztem wbudowania do sprzetu byl najkorzystniejszy. Niekompatybilnosci zawsze beda, ale AVX to zmiana duza po wielu latach potrzebna, u arm masz takie czesto i na wieksza skale.
    
    
56. @morgi (autor: Promilus | data: 9/06/10 | godz.: 12:40)
    "u arm masz takie czesto i na wieksza skale."
    Serio? Konkrety proszę ;)