DARPA docenia wkład Nvidia w rozwój GPGPU

1. hmm (autor: MarcinN | data: 10/08/10 | godz.: 12:22)
   Panowie w USA nie liczą się z kosztami prądu?
   
   
2. wiedzą na co postawić (autor: Sony Vaio | data: 10/08/10 | godz.: 12:44)
   a wojsko zawsze ma nie wybrali amd, no tak, tam się walczy z wrogiem, nie że sterownikami. dostęp do najnowszej technologii halo pierwsze. Ciekawe czemu
   
   
3. W USa (autor: accerian | data: 10/08/10 | godz.: 12:50)
   Armia ma na wszystko , jak nvidia będzie potrzebować to wybudują im elektrownie atomową która będzie zasilać fermi i chłodzenie do nich :) A żeby greenpeace się nie czepiał to ciepłem z kart graficznych będą ogrzewać new york ;]
   
   
4. trzeba przyznać że GPGPU to wózek nVidii (autor: Qjanusz | data: 10/08/10 | godz.: 13:06)
   który to zawsze nVidia pchała do przodu jako pierwsza.
   
   AMD tylko kopiował koncepcje i usiłował dotrzymywać kroku - z dość mizernym skutkiem przeważnie.
   
   Inną sprawą jest "etyka" tematu. Czyli to że nVidia chce całość zagadnienia uzależnić od swoich gratów (CUDA), a AMD zapodaje temat na uniwersalny hardware.
   
   
5. @add - co do prądu... (autor: Qjanusz | data: 10/08/10 | godz.: 13:09)
   akurat pobór prądu jest kwestią chwilowej technologii, z którą nVidia ma w tej chwili ogromne problemy. Oczywiście jest to przejściowe.
   
   Natomiast koncepcja GPGPU jest raczej ponadczasowa, nie związana z aktualnym wykonaniem hardware.
   DLATEGO WCISKANIE NA SIŁĘ POBORU PRĄDU W TYM KONTEKŚCIE JEST GŁUPOTĄ.
   
   jeżeli ktoś chce swoje frustracje wylać, proponuję zrobić to w temacie temu przeznaczonym:
   http://twojepc.pl/news21951.html
   
   
6. tylko... (autor: sikador | data: 10/08/10 | godz.: 13:36)
   ...armie stać na płacenie tak wysokich rachunków za prąd :D :D :D coś w tej reklamie ATI jest :P
   
   
7. ciekawe (autor: Markizy | data: 10/08/10 | godz.: 13:46)
   ile z tego Nvidia przeznaczy na spłatę rambusa, chociaż ciekawy taki trochę zbieg okoliczności, czyżby USA obawiało się układów Kanadyjczyków tak bardzo ?
   
   Co do rozwoju GPGPU to mogą mieć racje, Nvidia starała się to wypromować i to bardzo, jednak zastosowanie znalazło to tylko w określonych dziedzinach przemysłu, zwykły użytkownik do dziś za wiele z tego nie ma.
   
   
8. AMD nie dostanie nagrody (autor: pomidor | data: 10/08/10 | godz.: 14:00)
   bo głupie filmiki oraz niedorozwinięta technologia nic nie są warte w poważnych zastosowaniach
   
   
9. pomidor (autor: Markizy | data: 10/08/10 | godz.: 14:06)
   tyko że nvidia ta nagrodę wyda na spłatę pewnie rambusa. wiec tylko tyle że nie będą mieli złego bilansu.
   
   
10. myślicie że zapomoga dla nVidii zbilansuje odszkodowanie dla Rambusa??? (autor: Qjanusz | data: 10/08/10 | godz.: 14:27)
    Otrząśnijcie się!
    
    Samsung zapłacił odszkodowanie dla Rambusa po podobnym procesie w wysokości 900 mln dolarów.
    Analitycy i obserwatorzy są zgodni jak jeden mur, że kwota jaką zapłaci nVidia, będzie z pewnością wyższa i to znacznie.
    
    te 25 mln $ zapomogi od DARPA, to co najwyżej pójdzie na chusteczki dla pana ze świecącym czołem na otarcie potu i łez.
    
    
    swoją drogą, to mamy mały chichot historii w temacie. nVidia dostanie 25 baniek zielonych za technologię, która jest podwaliną ewentualnego sukcesu produktów Fusion od AMD.
    
    Panu ze świecącym czołem właśnie wypadła z ręki atrapa kolejnej karty... :-/
    
    
11. Ale zasilek (autor: morgi | data: 10/08/10 | godz.: 17:46)
    normalnie to oni setki billionow wydaja w rok w koksy a tu Nvidia dostala zapomoge, zeby symulator guantanamo stworzyc.
    
    
12. AD 4 (autor: Jarek84 | data: 10/08/10 | godz.: 18:30)
    Z tym jako pierwsza to pozwolę się nie zgodzić, z tym że lepiej i przyjaźniej teraz już nie będę polemizował ;)
    
    
13. ... (autor: pawel.xxx | data: 10/08/10 | godz.: 20:10)
    Osoby komentujące które podważają słuszność wyboru wojska USA, oraz przejmujące się kosztami zużycia prądu zdaje się zapominają o następujących kwestiach:
    1. wojsko nie jest zainteresowane rozrywkowymi zastosowaniami kart graficznych
    2. Wydajności kart nvidii w zastosowaniach gpgpu
    http://fwd4.me/G7y
    W świetle oferowanej wydajności zużycie energii u nv wypada jednak lepiej.
    Układy amd najlepiej wypadają w grach i tych zastosowaniach GPGPU w których trzeba przetworzyć mnóstwo danych niezbyt skomplikowanym algorytmem. Grami wojsko nie jest zainteresowane. A do przetworzenia mnóstwa danych niezbyt skomplikowanym algorytmem prawdopodobnie lepiej nadają się odpowiednio zaprogramowane układy FPGA
    3. Kosztach stworzenia i utrzymania oprogramowania. Komputer jest tyle wart ile soft na niego dostępny.
    Koszty tworzenia softu dla nv są zdecydowanie niższe niż u AMD. Przy projektach związanych z obronnością możecie z dużym prawdopodobieństwem przyjąć że nie jest to kwestia zatrudnienia dodatkowych 5 programistów - raczej dodatkowych 500. Tym ludziom trzeba by zapewnić pensje i stanowiska pracy co pochłonie i mnóstwo pieniędzy i energii.
    
    
14. @pawel.xxx (autor: Promilus | data: 10/08/10 | godz.: 20:44)
    Hueh, To ja ci pokażę testy z OCLGPUBencha gdzie 4890 gniecie Fermi, a co to będzie mieć wspólnego z rzeczywistością to już inna sprawa. To samo zresztą dotyczy Sandry, a jeśli chodzi o folding to jest to manipulacja bo w momencie premiery kart i jakiś czas później NIE BYŁO działającego jądra dla Fermi - dopiero po skompilowaniu z nowym SDK to działało i realne porównanie PD wypadało niezupełnie tak różowo jak to pokazano w powyższym linku. Co do wydajności to Tilera tile-GX, PowerXCell i8 czy nawet propozycje intela w formie Knights Ferry są bardzo ciekawą alternatywą do rozwiązań NV, wszystko nie rozbija się o energię czy wydajność, ale to z jaką siłą promuje się dane rozwiązanie (no dobra, czyli ile dla reklamy i popularyzacji jest w stanie firma obniżyć cenę dla hurtowych zamówień).
    "Grami wojsko nie jest zainteresowane"
    Więc nie potrzebuje TMU, ROP, rasteryzatorów i tesselatorów...
    "A do przetworzenia mnóstwa danych niezbyt skomplikowanym algorytmem prawdopodobnie lepiej nadają się odpowiednio zaprogramowane układy FPGA"
    Albo sztuczne sieci neuronowe w krzemie (i pokrewne np. ZISC).
    "Przy projektach związanych z obronnością możecie z dużym prawdopodobieństwem przyjąć że nie jest to kwestia zatrudnienia dodatkowych 5 programistów - raczej dodatkowych 500. Tym ludziom trzeba by zapewnić pensje i stanowiska pracy co pochłonie i mnóstwo pieniędzy i energii."
    Ale nv nie dostała kasy za prace dla wojska tylko rozwój i propagację rozwiązań GPGPU.
    
    
15. te 25 milionow USD (autor: Mario2k | data: 10/08/10 | godz.: 22:57)
    To styknie NVidi na 2 lata na cukierki kawe i muffinki . that's it ;)
    
    
16. ... (autor: pawel.xxx | data: 10/08/10 | godz.: 23:00)
    nie bardzo widzę sens pokazywania benchmarka który ma niewiele wspólnego z rzeczywistością. Swoja drogą jak bardzo niedopracowany jest ten benchmark powinien obrazować fakt że po premierze kolejnej wersji ktos z tego forum osiągnął 100000 na 4850 :)
    Również uważam wyniki folding za mało miarodajne. Gdy nie ilosć PD zależy od tego co obliczenia wykonuje to cos tu jest nie tak. W linku jednak znalazły się też testy jak najbardziej miarodajne gdy było trzeba wykonać konkretną pracę i było można zmierzyć ile sekund ona zajmuje czy ile fps jest generowanych.
    Co do wspomnainych przez Ciebie alternatywnych do nv procesorów to owszem maja znaczna moc obliczeniową, niektóre mają lepsze parametry termiczne tyle że znacznie trudniej je zaprogramować od gpu nv, przez co ta moc obliczeniowa staje sie trudno dostępna, a przez to droższa.
    Oczywiście że nv nie dostała kasy za konkretną prace na rzecz wojska, a na rozwój ich gpgpu. Ale trzeba pamiętać że armia to nie dobry wujek który rozdaje kase bezinteresownie. Wojsko dostrzegło potencjał tkwiący z rozwiązaniach nv,który mógłby być wykorzystywany w zastosowaniach militarnych. Dlatego wsparło finansowo rozwój technologii w tej dziedzinie.
    
    
17. @16 (autor: Jarek84 | data: 11/08/10 | godz.: 00:12)
    Bardzo mało tych testów GPGPU linku do ananda - juz w benchmarku.pl (ktory od pierwszego odstaje "jakosciowo") był chyba ostatnio test Fermii kontra Evergreen w zast. GPGPU - i ogólnie rzecz biorąc obecna arch. kart NV i ATI ma jakby inne "specjalizacje" - raz jedna raz druga jest wydajniejsza - zależanie od specyfiki algorytmu.
    
    
18. @Jarek84 (autor: pawel.xxx | data: 11/08/10 | godz.: 08:45)
    Za to na benchmarku testów jest bardzo dużo. Przy czym testy tesselacji raczej nie pokazują wydajności gpgpu. Testów physx także nie można wykorzystać do porównania wydajności gpgpu. Syntetyczne testy sandry także nie odzwierciedlają rzeczywistości - one raczej pokazują jaka jest szczytowa moc obliczeniowa. To że jedynymi warunkami w których tę szczytową moc obliczeniowa się osiągnie jest uruchomienie benchmarku sandry powstałego przy współpracy AMD benchmark przemilcza.
    Z pozostałych benchmarków użytych na benchmark.pl podważyć jeszcze należy SmallLuxGPU.
    http://fwd4.me/Ii2
    Przy tak niewielkim rozrzucie wyników kart tak znacząco różniących się konfiguracją można stwierdzić że tylko niewielka część obliczeń jest wykonywana przez GPU.
    Pozostałe testy można uznać za mniej więcej wiarygodne i na podstawie ich wyników wyciągać wnioski.
    
    
19. @up (autor: Promilus | data: 11/08/10 | godz.: 09:06)
    można by się pokusić o igrargpu ale on śmiga na STREAM/CUDA a nie wspólnym OpenCL i jak najbardziej ze względu na specyfikę obliczeń preferuje AMD (mimo że Ivan sam pisze, że problemów masa a wsparcia zero), zresztą dotyczy to wszelkich łamaczy haseł (ighashgpu, łamacz office czy wreszcie ewsa elcomsoftu). Można by badaboom do avivo convertera porównać...ale... też nie bardzo bo wyjściowa jakość nie jest taka sama. A od siebie dodam - ati fanboye, wsadźcie nieobsługiwany przez konwerter format rmvb jako źródło i spróbujcie skonwertować do h.264 ^^ 9/10 prób kończy się "vpu recovery" - dzięki bardzo. Zresztą "vpu recovery" zdarza się ogółem w przypadku używania GPGPU (np. folding@home swego czasu na dość pokaźnej liczbie sterów po prostu zabijał obraz...obliczenia szły dalej, obraz nie wracał do restartu). I co, że ten bolid AMD ma niezły silnik, jak skrzynia biegów do dupy? Prawdę mówiąc teraz jestem niemal przekonany, że gdyby nawiązali współpracę z nv i przyjęli CUDA to zamiast być w lesie mieliby się całkiem nieźle.
    
    
20. @Promilus (autor: Qjanusz | data: 11/08/10 | godz.: 10:22)
    gdyby przejęli, to:
    - płaciliby moto,
    - mieliby przegraną pozycję w benchmarkach porównujących CUDA AMD vs CUDA nV
    - byliby w temacie całkowicie zależni od konkurencji (patrz na Fusion)
    
    Jest tak że później wystartowali i mnie łożą. Zanim dogonią lidera GPGPU, trochę jeszcze czasu minie. Ale jak dogonią, to będą panem na własnym podwórku.
    
    
21. @Qjanusz (autor: pawel.xxx | data: 11/08/10 | godz.: 11:35)
    "Jest tak że później wystartowali i mnie łożą. "
    
    Fakt wystartowali o jakieś pół roku później.
    
    "Zanim dogonią lidera GPGPU, trochę jeszcze czasu minie. Ale jak dogonią, to będą panem na własnym podwórku."
    
    Skoro mniej łożą to dystans się powiększa. Jeśli nadal będą mniej inwestować w tę technologie to dystans nadal będzie się powiększał i nie dogonią. A komentowany news wskazuje że potencjalni klienci raczej już dokonali oceny i zdecydowali się wesprzeć technologie która ich zdaniem jest bardziej perspektywiczna.
    
    
22. @pawel.xxx (autor: Qjanusz | data: 11/08/10 | godz.: 12:14)
    Inaczej...
    nVidia więcej łoży bo wykonuje dla siebie to, co dla AMD robi khronos.org
    
    Dodatkowo nVIdia przekonuje wszystkich dookoła do koncepcji GPGPU, co kosztuje oczywiście, natomiast AMD wchodzi z produktem na udeptaną już ścieżkę.
    
    nVidia wystartowała pierwsza, więc musiała spore koszty poświęcić na przetarcie szlaków. Jak pewne wiesz, kolejna osoba idąc przetartym szlakiem nie musi już torować sobie drogi, więc mniejszym nakładem pracy jest w stanie dogonić torującego.
    
    
23. @Qjanusz (autor: Promilus | data: 11/08/10 | godz.: 12:22)
    OpenBrook nie potrafi dogonić najstarszego SDK CUDA więc akurat jasne jest że AMD leci w kulki. Nawet ich narzędzia dla OpenCL pozostawiają wiele do życzenia, a support żaden bo siedzę na forum i jest może 2 pomagających z czego tylko 1 z AMD.
    
    
24. @Promilus (autor: Qjanusz | data: 11/08/10 | godz.: 12:28)
    soft i wsparcie. Tylko to zostało do poprawy. Tylko albo aż tyle.
    To jest przestrzeń dzieląca AMD do nVidii w tej materii, czyli wspomniane wcześniej gonienie lidera.
    
    Nie są sądzę żeby nie zostało załatane to w ciągu najbliższego roku.
    
    
25. @Qjanusz (autor: Promilus | data: 11/08/10 | godz.: 12:47)
    Aż tyle. Czy wyobrażasz sobie wprowadzenie przez dajmy na to Atmela MCU o niesamowitej wydajności, z zintegrowanymi fajnymi peryferiami typu 16bit ADC i DAC, 10 niezależnych timerów, tyle samo kanałów pwm 16bit z możliwością obsługi H-bridge (i uwzględnianie czasu martwego) a w nocie katalogowej udostępniło tylko rejestry i listę rozkazów? Jako narzędzia zamiast AVR Studio byłby jakiś assembler + słabo wydajny kompilator C-like? Przecież to by nie miało racji bytu! Jasne że by się znaleźli chętni i sami dorobili potrzebne narzędzia, informacje, sample programowe itp. itd. Ale gdzie takiemu czemuś do profesjonalnych systemów jak IAR Workbench + dev. boards? Tutaj chodzi nie o to że AMD słabo dba o rozwój ich GPGPU, tu chodzi o to że AMD WCALE nie dba o rozwój GPGPU.
    
    
26. up... (autor: Marek1981 | data: 11/08/10 | godz.: 13:02)
    Jak na razie AMD nie może się popisać na polu pro.... no i co z tego??? Nie pamiętacie chyba, że AMD stosunkowo od niedawna weszło na rynek kart graficznych i opracowuje APU do zastosować multimedialnych i podejrzewam pro (servery, stacje robocze). Dajmy im trochę czasu, bo i tak nieźle się potrafili podnieś w kwestii sprzętu, więc powinni mieć powoli kasę na soft.
    
    
27. @Qjanusz (autor: pawel.xxx | data: 11/08/10 | godz.: 13:05)
    Kolejne brednie.
    
    "natomiast AMD wchodzi z produktem na udeptaną już ścieżkę."
    
    Wypadało by napisać że przed ową udeptaną ścieżką stoi znak "tylko dla nv".
    
    "Jak pewne wiesz, kolejna osoba idąc przetartym szlakiem nie musi już torować sobie drogi, więc mniejszym nakładem pracy jest w stanie dogonić torującego."
    
    W poście #20 pisałeś o zaletach tego iż AMD nie poszło ścieżką udeptana przez nvidie. Teraz twierdzisz że czerpie korzyści z tego że poszło tą udeptaną ścieżką.
    Prawda jest tak ze AMD jest w sytuacji każdej firmy która wchodzi na rynek opanowany/prawie zmonopolizowany przez jednego lidera.
    Co do języka brook to amd chyba wycięło numer którego nikt się nie spodziewał porzucając go uzasadniając decyzje tym że brook nie bardzo nadaje się do zadań które chcą realizować. Kilka lat pracy, sporo kasy i pewna liczba użytkowników którym mówi się: jak chcecie to bawcie sie w to dalej sami my zabieramy swoje zabawki i idziemy do domu. To niechybnie te ułatwienie płynące z chadzania przetartymi szlakami ;-/
    
    
28. @Up All (autor: Jarek84 | data: 11/08/10 | godz.: 13:14)
    Prawda jest taka że GPGPU rozwija się mało dynamicznie - brak przygniatającej ilości softu z wykorzystniem któregokolwiek natywnego SDK od obu producentów - jak widać zrównoleglenie sekwencyjnych algorytmów pod GPU nie jest łatwe jak i malo na razie oplacalne (wiecej pracy, oprogramowanie na rynek konsumencki opoznione w stosunku do konkurencji etc). Do tego czesto w przypadku SDK od AMD trzeba samemu duuuzo szukac ewentulnie grzebac w zrodlach - stad nie neguje ze CUDA jest bardziej wygodne niz Stream (sprawdzone empirycznie) - co do OpenCl to jest to technologia ktora obecnie AMD jako producentowi CPU, GPU i niedlugo APU najbardziej odpowiada i podejrzewam ze zarowno sterowniki jak i całe SDK bedzie rozwijane pod kątem tegoz.
    
    
29. @Promilus (autor: pawel.xxx | data: 11/08/10 | godz.: 13:38)
    Odbiegając od tematu i a propos #25 i Atmela. Co jako specjalista w dziedzinie uc sądzisz o przyszłości rodziny AVR w kontekście konkurencji ze strony ARM cortex Mx?
    Bo w moim odczuciu o ile AVR32 nigdy jakoś specjalnie ciekawą propozycją nie było, to teraz za sprawą m0 i takich produktów jak LPC11xx z ich niewielkimi cenami AVR8 znacznie straciło na konkurencyjności. AVR-om pozostało teraz zaledwie kilka bajerów i lepsza dokumentacja.
    
    
30. @pawel.xxx (autor: Promilus | data: 11/08/10 | godz.: 13:45)
    Nie przesadzaj. Brook zasadniczo nie był na początku zabawką AMD. BrookGPU leciał na GLSL/HLSL i był dostępny zarówno do radków jak i geforce. AMD dodało support do CtM (backend CAL) i w dalszej kolejności Brook+
    Dopóki nie pojawił się OpenCL to nie było dla duetu Brook&CAL żadnej alternatywy, a brook ani nie jest wydajny, ani nie jest wygodny. Nic dziwnego że wybrali OpenCL. Tylko co z tego skoro ich SDK kolejna wersja z OCL1.1 powinna wyjść w tym miesiącu, a wątpię by zasadniczo zmieniła rozkład sił. SDK to sobie można wydać, ale bez konkretnego wspierania inicjatyw to nikt się tym nie zainteresuje i AMD może co najwyżej żerować na osiągnięciach nvidii oraz tym co wymusi Apple.
    
    
31. @pawel.xxx (autor: Promilus | data: 11/08/10 | godz.: 13:50)
    Widziałem małe ARMy i się nawet przymierzam do przejścia na nie. M0 i M3 jak mnie pamięć nie myli. 10x ciekawsze niż drogie gówno atmela (xmega...hahahaha!). No i 32 bit (dobra, AVR32 też są ale ceny...) . Jeśli zaś chodzi o małe zastosowania to wierz mi że i tanie jak barszcz PIC, i tanie jak barszcz klony '51 sobie znakomicie radzą (szczególnie te z clock/6, clock/2 i single cycle). A ostatnio wpadł mi w łapki znakomity ADuC841 za 15zł... fakt, za 20zł więcej miałbym dużo więcej z jakimś MPS czy LPC, ale... akurat nie potrzebowałem więcej (szybki ADC i dobry DAC, do tego sprzętowy PWM - w sam raz do porządnego elektronicznego zasilacza laboratoryjnego).
    
    
32. @Promilus (autor: pawel.xxx | data: 11/08/10 | godz.: 14:44)
    Właśnie spojrzałem na obecne ceny AVR8 i oczom nie wierzę!
    Gdy ja wybierałem uc do zastosowań amatorskich to wybrałem atmega88. Była to wtedy najlepsza propozycja. Programowanie w C, mnóstwo interfejsów, porządna dokumentacja. Nie był może najtańszy z AVR ale za takie możliwości coś koło 5-6zł było najlepszym wyborem.
    W tym czasie rozważałem również pic i bardzo poważnie zastanawiałem się nad '51. najtańsze z tych rodzin były po około 2zł ale za to była bida z nędzą jeśli idzie o interfejsy, i możliwości cpu. Być może gdyby szło o masowa produkcje i zakup hurtowy 1000000 sztuk to pic czy '51 byłoby sensowne. Ale w detalu za podobną cenę do najtańszych pic i 51 były attiny z jakimiś tam interfejsami i z cpu deklasującym rywali.
    A dziś patrzę na ceny i widzę
    najtańszy pic 2zł, najtańszy '51 z sensowną ilością nóg 5zł, najtańsze tiny 7zł atmega88 12.50zł. Czyżby ludzie juz zaczęli przerzucać zie na lpc1113 za 7-10zł i przez to avr stały się produktami niszowymi obarczanymi gigantyczną marżą?
    
    
33. @pawel.xxx (autor: Promilus | data: 11/08/10 | godz.: 14:59)
    Kupowałem niedawno w LISPOLu AT89S52 za 3.65zł jeśli dobrze pamiętam za sztukę. Fakt, natywnie nie wspiera ani 1w, ani i2c, ani spi - ale to akurat można programowo zrobić. Nie ma ADC co akurat jest poważną wadą. Natomiast jest pełne 32 pinów I/O, tymczasem w ATTiny z połowa tego. Nawet SMD Atmega8 i 88 ma mniej bo iirc 2 pełne porty (D i B) oraz 6 z C (i 7 reset jeśli się SPI wyłączy) - za to znacznie lepsze zasilanie portów (tj. więcej sink i source current) - z drugiej strony wymagana jest konfiguracja input/output. Na allegro znajdziesz tylko PIC, atmegi, '51 a z ARM to niestety tylko te droższe modele. Tańszych brak i to mnie boli, bo mam parę zaufanych sklepów i często tam korzystam, a nie mogę dostać LPC1xxx ani 2xxx. Co do AVR z tego co się orientuję mieli problemy, wszystkie Atmegi 8 i podobne są jakiś czas temu z produkcji wycofane i zastąpione 48/88/168 itp. Teraz Xmega wchodzi, ale widać straszne braki na magazynach wszystkich AVR bo ceny są kosmiczne, ale... zasadniczo tych najtańszych modeli. Bo za ~15zł dostaniesz i Atmegę32 która wiadomo jest lepsza niż 7.85zł Atmega8 czy 12zł Atmega88 :P Na elektrodzie też wszędzie LPC zaczęli polecać, muszę spróbować jak znajdę stałego i dobrego dystrybutora. Przy okazji 1,5r temu A8 (nie cortex ^^) kupowałem po 3.80zł, a Atmega48 PDIP (droższe choć bez ADC6 i 7) za 4,50zł. Strasznie denerwujące. Swoją drogą czy ARM ma jak np. H8/3048 czy x86-64 rejestry takie że np. 32bit rejestr i osobne nazwy dla starszej i młodszej 16 bitowej części? tj. czy są rozkazy bazujące na wydzielonej 8 i 16 bitowej części rejestru? Jeśli tak to git majonez, jeśli nie... no prawdę mówiąc lekki zawód.
    
    
34. @ Promilus (autor: pawel.xxx | data: 12/08/10 | godz.: 01:10)
    "...czy ARM ma jak np. H8/3048 czy x86-64 rejestry takie że np. 32bit rejestr i osobne nazwy dla starszej i młodszej 16 bitowej części?"
    
    Takiego rozróżnienia w sensie nazw rejestrów nie ma
    
    
    
    
    " tj. czy są rozkazy bazujące na wydzielonej 8 i 16 bitowej części rejestru? Jeśli tak to git majonez, jeśli nie... no prawdę mówiąc lekki zawód."
    
    A takie rozkazy to są, np.
    
    Extract halfword [15:0] from register, move to register, and zero-extend to 32 bits
    Load memory byte [7:0] from register address + register offset
    Extract byte [7:0] from register, move to register, and sign-extend to 32 bits
    
    
35. @pawel.xxx (autor: Promilus | data: 12/08/10 | godz.: 09:09)
    Pytam bo H8 ma ciekawe rozwiązanie. Np. rejestr 32 bitowy ER0 dzieli się na dwa rejestry 16 bitowe R0 oraz R1 a te zaś na rejestry 8 bitowe R0H, R0L, R1H, R1L...wiadomo, trzeba z tym uważać, żeby nie nadpisywać danych, ale daje to naprawdę dużą elastyczność i lepsze wykorzystanie rejestrów.