Literka S oznacza tylko "synthesizable" i sprowadza się do tego, że rdzeń ARM-a jest w jakiś sposób dostosowany do reszty mikrokontrolera przez producenta tegoż mikrokontrolera, ale ARM wyraźnie stwierdza, że: "Code written for ARM7TDMI-S is binary-compatible with other members of the ARM7 Family and forwards compatible with ARM9, ARM9E and ARM10 families". IMHO ARM to "miodzo" w programowaniu (szczególnie jak się niedawno pisało na ADSP21xx ;-) Ma parę b. ciekawych pomysłów wziętych z procków DSP i możliwość efektywnego używania rozkazów 16-bitowych (tzw. thumb mode).
Tej to nie wiem, ale np. małe ARM-y z Atmela AT91 są w miarę dostepne. Niestey nie mają wbudowango FLASH-a.
Wed, 12 Nov 2003 18:47:38 +0100 jednostka biologiczna o nazwie Michal Baszynski snipped-for-privacy@ga.ze.ta.pl.> wyslala do portu 119 jednego z serwerow news nastepujace dane:
A nie, nie widzialem jak bede mial czas to poogladam. Faktycznie taka rewelacyjna ?
Wed, 12 Nov 2003 18:24:04 +0000 (UTC) jednostka biologiczna o nazwie "Jacek R. Radzikowski" snipped-for-privacy@piranet.org wyslala do portu 119 jednego z serwerow news nastepujace dane:
[...]
No fajne, fajne tylko ze i tak poza naszym zasiegiem :-(
do programowania w assemblerze świetna. Na studiach dłubałem programy na M68K i 80(2)86 i było to niczym niebo i ziemia. Rejestry "do wszystkiego", nie trzeba się było wściekać z jakimś mapowaniem, segmentami i podobnym badziewiem. Jak coś zapisałeś pod adres 4711 to tam było, czy kod, czy program. A było co robić: mały system operacyjny multi tasking z loaderem, obsługą drukarki, terminala, czytnika i dziurkarki kart i taśmy (hehe, wirtualnych, bo prawdziwych już nie mieliśmy) na zaliczenie. No i wszystko w assemblerze.
Thu, 13 Nov 2003 10:41:27 +0100 jednostka biologiczna o nazwie Waldemar Krzok snipped-for-privacy@ukbf.fu-berlin.de> wyslala do portu 119 jednego z serwerow news nastepujace dane:
[...]
Wow. Nie no wiesz ja generalnie wole assemblera unikac, ale czesto jest taka sytuacja ze trzeba pisac w assemblerze chocby z tego powodu ze uC ma 2KB FLASHa i program w C to ie tam zbyt rozbudowany nie miesci :-( Ale nawet jak mam w C pisac to wole znac architekture i assembler procka chociazby na wypadek debugowania.
rewelacja to nie jest, bo swoje lata ma ;-) Typowa Motorola, czyli prosta i logiczna, bez cyrkow typu segmentacja pamieci jak w x86. Ale na bazie MC68000 powstalo wiele jednoukladowcow, do niedawna powszechnie stosowanych np. w telefonach komorkowych.
Malo uzyteczne w jezykach wyzszego poziomu. Nie napiszesz zrodla zeby takowe wykorzystac. Przy 8 bitach mozna zastapic tablica.
Do motek dalo sie dolozyc w zewnetrznej kosci.
Co sp* ? Na pierwszy rzut oka nie zauwazylem wad.
Segmentami nie trzeba sie przejmowac - plaski tryb 32-bit i po segmentach. Ale _mozna_ je wykorzystac. O ile pamietam unixy na motorolkach robily segmentacje sztucznie - wykorzystujac najstarsze bity adresu.
Hm, polemizowalbym. Jawne segmenty maja swoje zalety.
Szczegolnie jak pomyslisz o nowych zastosowaniach - np zamapowanie kilku plikow do pamieci, o reszte niech sie martwi driver pamieci wirtualnej ..
Na pewno Goryszewski z trybuny sejmowej, ale byc moze faktycznie cytowal Mlynarskiego, tego juz niestety nie wiem. :-)
W GCC jest dostepny wspanialy mechanizm wstawek asemblerowych, wiec z wykorzystaniem nie ma problemu. Za pomoca wstawienia BSF w kodzie w C++ zrobilem kolejke priorytetowa, uzyskujac kod o olbrzymiej wydajnosci, nieosiagalnej za pomoca jakakolwiek innej metody. To bylo dokladnie to, czego potrzebowalem -- za pomoca pojedynczego zapytania od razu wiedzialem skad pobierac nowe dane. Nie trzeba bylo lookup-tabelek ani drzewek decyzyjnych; cud instrukcja. :-)
I stracic duzo niezwykle cennej pamieci podrecznej na jej pamietanie. Poza tym ja mialem priorytety ustalane przez zawartosc 32-bitowego slowa bez znaku, wiec tu lookup-tabelka bylaby cokolwiek duza... ;-)
Elementy asocjacyjnej pamieci podrecznej translacji adresu wirtualnego TLB sa indeksowane wylacznie adresem wirtualnym. Dziala to dobrze, gdy procesor wykonuje jeden program, ale w srodowisku wielozadaniowym to jest kula u nogi. Aby uniknac interferencji z innymi procesami podczas przelaczania CPU do innego procesu TLB musi zostac oproznione i nastepnie ponownie wypelnione, co jest _bardzo_ kosztownym zadaniem. Monolitycznym mamutom w rodzaju systemow uniksowych albo Windows to malo przeszkadza, bo przelaczaja one zadania ~100 razy na sekunde. Dla moich ulubionych nowoczesnych systemow operacyjnych opartych na mikrojadrze jest to jednak gigantyczny problem. One w wiekszosci przypadkow sa niezwykle stabilne, bo wszystkie sterowniki zostaly przeniesione do trybu uzytkownika, wiec w zasadzie nic nie jest w stanie uszkodzic jadra. Ta forma obslugi sprzetu wymaga jednak _bardzo czestego_ przelaczania CPU miedzy roznymi zadaniami; w zasadzie podczas kazdego przerwania. Dokladajac do tego wspoldzialanie calosci oparte na przekazywaniu komunikatow, a nie wywolywaniu funkcji systemowych czestotliwosc zmian kontekstu rzedu 50.000 na sekunde nie jest niczym dziwnym.
Nowoczesniejsze procesory uzupelniaja elementy TLB o identyfikator procesu, do ktorego naleza i dzieki temu absolutnie niczego nie trzeba uniewazniac, wiec zmiana przestrzeni adresowej jest darmowa. Podsystem translacji adresu po prostu sprawdza, czy znaleziony element moze byc uzyty przez biezacy proces.
Proces translacji adresu wirtualnego odbywa sie na zasadzie przegladania tablic odwzorowan (tj. tablic i katalogu stron w trybie
32-bitowym oraz dodatkowo katalogu katalogow stron w trybie
36-bitowej pamieci fizycznej). Stad:
a) algorytm wyboru odwzorowania jest okreslony przez projektanta, wiec ja nie mam mozliwosci scislego dopasowania go do konkretnego zastosowania ani implementacji technik adaptacyjnych.
b) tablice odwzorowan musza rezydowac w pamieci fizycznej, a jednyny dostep do nich jest mozliwy jedynie przez pamiec wirtualna. Z tego powodu na poziomie jadra trzeba robic takie wygibasy z ich odwzorowaniami, ze glowa mala; w przypadku systemow wieloprocesorowych krotko mowiac jest horror. :-(
c) bardzo duze zuzycie pamieci fizycznej, jesli wykorzystywany obszar pamieci wirtualnej jest bardzo rozproszony.
d) prosty, dwupoziomowy mechanizm ochrony typu system
-uzytkownik. To jest wielki problem dla systemow SAS (Single Address Space OS), bo uniemozliwia implementacje wydajnego mechanizmu bezpiecznego dzielenia pamieci miedzy procesami.
e) w systemach wieloprocesorowych bardzo trudno zrealizowac prywatne obszary pamieci fizycznej dla poszczegolnych procesorow, odwzorowane pod tym samym adresem wirtualnym (aby uzyskac pelna symetrie systemu). W praktyce kazdemu procesowi trzeba wiec przydzielic kilka katalogow stron, opisujacych _prawie to samo_, po jednym dla kazdego aktywnego procesora. To prowadzi do koniecznosci zapewnienia synchronizacji ich zawartosci, co jest bardzo niemile widziane, zarowno pod wzgledem kosztu, jak i mozliwosci wprowadzenia nowych, bardzo trudnych do wykrycia bledow.
Dziela madrzejszych projektantow nie korzystaja ze sprzetowych tablic stron, sa wiec pozbawione powyzszych wad (poza (d)). Jezeli nie maja potrzebnego odwzorowania w TLB, generuja wyjatek, kazac policzyc potrzebny wynik systemowi i nastepnie umiescic go w TLB. Te najlepsze CPU korzystaja z poprzedniej metody, ale uzupelniaja ja o dodatkowe mechanizmy. Po pierwsze, mechanizm ochrony stron jest nie jedno-, lecz 16--24 bitowy (tzw. protection keys) i mozna wydajnie bez ryzyka dzielic pamiec. Proces dostaje pewien zbior kluczy i moze w jego ramach korzystac nawet (lub scislej: zwlaszcza...) z pamieci innych procesow. Po drugie wiedza, ze translacja via tablica stron jest szybsza niz tlumaczenie programowe, wiec pozwalaja systemowi wybrac, czy dany kawalek ma byc tlumaczony przez tablice, czy przez podystsem VMM. Tak ma m.in. Itanium. Jesli Cie ta tematyka interesuje, to duzo informacji znajdziesz m.in. w doktoracie Kevina Elpinstone'a; powinienem gdzies miec kopie, w razie potrzeby moge udostepnic.
Alez ja sie nimi nie przejmuje, wprost przeciwnie, zamierzam bardzo intensywnie z nich korzystac. Tylko chce by to byly normalne, przezroczyste dla uzytkownika segmenty, a nie wynalazek na ksztalt IA-32... Niejawne segmenty to wspaniale narzedzie podczas przekazywania komunikatow miedzy procesami; przypomina to pamiec wirtualna "drugiego poziomu".
Co prawda nic nie wiem o takich szczegolach implementacji VMM na Motorolkach, ale tak to wlasnie sie robi na Alphie i Itanium oraz IIRC na MIPSie. Tzn. tam nie ma sztucznej symulacji, najstarsze
3 bity adresu wirtualnego to selektor segmentu, nie ma osobnych rejestrow selektorow, jak na IA-32.
Chetnie podyskutuje, bo ta dzialka to hobby w ramach zawodu :-)
Wymien je wiec. :-)
Przeciez to sie praktycznie od zawsze robi w pamieci _wirtualnej_, a nie _logicznej_, a wiec nie ma nic wspolnego z segmentacja. Plik A jest odwzorowany pod adresami (4096,8191), plik B pod adresami (16384,65535) itd. -- tu _nie ma_ segmentacji.
Myslalem ze to moze jakis teksciarz Mlynarskiego, ale jak z trybuny, to cytowal :-)
[...]
No, musialbym odswiezyc wiadomosci, bo szczegoly czytalem jak 386 wchodzilo :-)
[...]
Ale to jest kamyczek w to co lubisz - przerywamy proces na dlugi czas. Hardware w Intelu robi to szybciej.
Chyba wszystkie Unixy. Zauwaz ze tam wiele procesow uzywa tych samych adresow logicznych, a obszary danych sa dynamicznie zmienne w dlugosci. Musi byc jakas segmentacja.
A co zrobic jak plik A sie rozrosnie z 4KB do 20KB ? Trzeba zmienic adres bazowy, bo obszar od 16K jest juz zajety.
Zobacz jakie liczby wymieniles. Male. A jak bede chcial miec 200MB ? i np 20 plikow ? Przestrzen logiczna 32-bit sie zuzyla. I co teraz zrobic jak trzeba powiekszyc jeden z obszarow - zadanie przeorganizowania robi sie trudne ..
Oczywiscie mozna uzyc procka 64 bit, podzielic sobie przestrzen w miare dowolnie - na pare lat starczy. 32-bit obecnie jest za malo.
A to co oferuje intel [nie napisze "rozwiazanie Intela", bo to zaszlosc historyczna a nie rozwiazanie :-)] jest stopniem posrednim - adres logiczny robi sie 48 bitow, program jest efektywniejszy bo uzywa danych 32bit, dostep do innych segmentow jest dosc efektywny [szczegolnie w jakis nowszych Pentium, gdzie instrukcje zmieniajace segment i adresy sa liczone rownolegle i wyprzedzeniem].
No, niestety nie ma niczego za darmo. :-( Powszechnie uzywane algorytmy sa bardzo szybkie w srednim przypadku , wiec wiekszosc kosztu zalezy od czasu wygenerowania i obslugi wyjatku. Jesli calosc zmiesci sie, powiedzmy, w 200 cyklach, to problemu nie ma.
Oczywiscie, jak to hardware. Z tak szybkoscia to jednak tez nie jest tak rozowo, ze wzgledu na nietrzymanie tablic odwzorowan w pamieci podrecznej to cos okolo IIRC 30 cykli.
Hm, dobrze znam budowe wewnetrzna systemow uniksowych, ale nie bardzo rozumiem co masz na mysli. Czy chodzi o to, ze pod tym samym adresem kazdy proces moze widziec rozne dane? To sie robi za pomoca pamieci wirtualnej. Na przyklad ani Linuks ani NT nie korzystaja z segmentacji (w stopniu wiekszym, niz wymaga tego budowa procesora). No, w NT4 TLS bylo implementowane za pomoca osobnego segmentu, ale w tym kontekscie to sie nie liczy.
Ale adres bazowy odwzorowania _pliku_ (tj. offset od poczatku), a nie bloku pamieci wirtualnej. Po prostu przesuwa sie strony w pamieci, NT ma do tego funkcje IIRC ZwMapViewOfSection(). Ze wzgledu na ograniczenia adresu wirtualnego odwzorowuje sie okienko, a nie caly plik.
To byl przyklad, w rzeczywistosci zostawia sie troche miejsca na wzrost pliku (pare MiB jesli dobrze pamietam lekture "Inside Windows NT", ale glowy nie dam).
To bedziesz musial suwac strony. :-) Plik zawsze musi rezydowac w pamieci wirtualnej, nawet jesli uzywasz segmentacji (bo translacja adresu logicznego to w koncu jest glownie dodanie bazy). Jak Ci sie nie zmiesci w pamieci wirtualnej, to tym bardziej w logicznej. "Praw fizyki Pan nie zmienisz". :-)
Bo jest dosc trudne, ale od ukrycia tego smutnego faktu jest API. :-)
Tak, o wiele za malo... Itanium ma adres wirtualny 64 bity, logiczny
Sat, 15 Nov 2003 18:45:15 +0100 jednostka biologiczna o nazwie "Piotr Wyderski" snipped-for-privacy@wp.pl wyslala do portu 119 jednego z serwerow news nastepujace dane:
Racja, ja sie wlasnie zaczalem ostatnio bawic assemblerem i AVR i wniosek mam jeden - bez kompilatora C nie podchodzic :-))))
Nie - chodzi o to ze masz logiczne segmenty pamieci: kod programu, stos, dane, ewentualnie biblioteki dzielone, pamiec jadra itp. I do de facto powinny byc wlasnie segmenty, tylko czesto sie je po partyzancku zalatwia stalymi obszarami adresowymi.
O cos innego mi chodzi - chcesz powiekszyc okienko. Nie miec na raz
4KB, tylko 10, no niech bedzie 12KB. Niby nic trudnego .. ale wtedy to okienko bedzie pod adresem logicznym powiedzmy od 0 do
12cos. I tu maly pech - obszar od 8192 przydzielilismy innemu okienku. Teraz trzeba jedno z okienek przestawic pod inny adres, co nie jest wielkim problemem, ale w programie trzeba zmienic adresy okienka we wszystkich wystapieniach - a to juz moze byc wiekszy problem. Uzycie segmentacji IA32 problem by rozwiazalo.
Nastepny problem - fragmentacja przestrzenii adresowej [logicznej]. Moze nie przy okienkach plikow, bardziej przy przydziale pamieci. Alokujemy 100MB, alokujemy 1MB, zwalniamy 100MB, alokujemy 102MB. I tak 10 razy, biorac coraz wiekszy blok - ale w sumie to 120MB nie przekroczymy. I bryndza - pamieci rzeczywistej jest powiedzmy 512MB, a przydzielic nie ma gdzie, bo dany system na dane procesu przeznacza obszar logiczny od 40000000 do 7fffffffh. Zreszta niech nie ma tego ograniczenia, a i tak szybko sie wyczerpie.
18 Nov 2003 10:27:13 +0100 jednostka biologiczna o nazwie snipped-for-privacy@poczta.onet.pl (ziel) wyslala do portu 119 jednego z serwerow news nastepujace dane:
Pozyjemy, zobaczymy ;-)
Aaa tak sobie ... :-/ A co znowu jakies chlani^H^H^H^H^H^Hspotkanie planujecie ?
Ja przepraszam, że tak między wódkę i zakąskę ;-), ale z tym nie wyjściem, to letka przesada. Mam kolegę, który tłucze oprogramowanie do terminali (gry, L***OMATY :-), zakłady na odległość itp.). I to wszystko na 68k...
Ostatnio ciężko go było od ściany odróżnić - z DES-em walczył ;-))
Pozdrawiam
Marcin Stanisz, kończący właśnie projekt na mega32 ;-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.