CP/M i 64kB

I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko tą zaletę że robisz to w cpu.

Zależy jaki duży masz ten obrazek. A jak nie wiesz jaki masz duży to i tak musisz sprawdzać za każdym razem. Znowu dupa z tyłu.

Bo teksty z definicji nie przekraczają 64kB ...

Oczywiście przy założeniu że nie będzie padać a i wiać też nie będzie to jakoś ta prowizorka wytrzyma ...

Jesli procesor ma MMU to nie wraca. Każdy proces ma własną przestrzeń wirtualną i nic nie wie o innych allokacjach.

Jak nie ma MMU to problem co najwyżej nie jest procesu tylko procesów. Tak jak w Amidze.

I pamięc się fragmentuje. Podobnie w ramach procesu allokacje przychodza, odchodzą a pamiec w kawałkach. Sorry, taki mamy podstawowy model programowania do dzisiaj.

Para segment:offest to jest dokłądnie to samo co pointer. dokładnością do kłopotów w relacjach. Nie ma tam nic "leszego" albo rozwiązującego problemy lepiej niż liniowy adres. Nic. Dorabianie filozofii do tego konceptu jest naprawdę bolesne dla logiki.

Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i wskaźnik jest iwalidowany. To się da zrobić i robią to niektóre maszyny wirtualne specjalizowane do poganiania Javi i C# w embedded. Ale tam jezyki nie mają pointerów.

Mylisz segmentacje z wirtualizacją pamięci.

Nie było zgodne z CP/M i w dodatku potem okazało się że było na tyle kiepsko zaprojektowane że nie było też wydajne.

Powiedz to kompilatorom. Obecnie tworzy się kod na procesor wirtualny z masą rejestrów a nastepnie kolejna warstwa stara się to translować na żałosną przestrzeń rejestrów x86. No, ale Turing-complete, więc o co chodzi.

Ich dane są gdzieś załadowane fizycznie w pamięć. Kod obsługujący albo ma na stałe offset i w gotowości relokator jak by trzeba było przenosić albo jest całkowicie relokowalny.

kod x86 ma na tyle duży narzut na całkowitą relokowalność że szbciej jest kod przerelokować automatycznie niż dodawać masę instrukcji wydłubujących z żywego kodu PC.

I dlatego Windows 32 bit zazwyczaj DLLki relokuje po każdym załadowaniu. Na Win 64 dllki mogą być już za darmo pisane względnie.

użytkownik Sebastian Biały napisał:

Dzięki Apple ma robotę, dzięki filmom ze słowami kluczowymi Apple/MacBok/IPhone też tłucze kesz. Nadmiernie stęka na swojego pracodawcę:) OT. Apple chyba zrezygnowało z wykończenia pcb złotem na rzecz tańszego OSP (selektywnie kładziony topnik czyli przemysłowe gówno zwiększające zawodność)

Mam te zalete, ze ten segment jest przesuwny i obejmuje prawie 64KB.

Nie sprawdzam - wyliczam adres pixela, jego trzy bajty sie w segmencie zmieszcza. Przy stronnicowaniu nie moge tego obiecac - musze sprawdzac przy kazdym bajcie.

Moze nawet wystarczy adres dla poczatku linii policzyc, ale to juz lepiej sprawdzic ... albo i nie, kto ma takie glupie obrazki, ten moze miec klopoty :-)

Nawiasem mowiac - gdzies w TIFF jest "chunk size", ktos przewidzial, ze moze byc dobrze podzielic obrazek na kawalki nie wieksze niz np

W CP/M byc moze, ale my tu o lepszym systemie :-)

Nie musi wiedziec, bo wskaznik sie nie zmienia.

Ale przede wszystkim rynek nie chcial. To co beda ulepszac :-)

Nawiasem mowiac - mimo niewatpliwych zalet, zobacz jak dlugo sie 68k przebijala. Za droga byla, czy zabraklo takiej lokomotywy jak IBM ... i CP/M? Tego CP/M to bym nie przecenial, bo niedawno wystartowal, a pisanie np kompilatora w assemblerze ... musialo byc ciekawe :-)

A moze jednak tak ogolnie 68k kiepska byla ? Albo unix byl za malo "user friendly" i za drogi ?

No i mowisz kompilatorom, one kompiluja, rezultat jest dobry i co cie to wiecej obchodzi ?

A i tak nie wiadomo, czy tak trzeba, czy tworcy kompilatorow poszli w takim kierunku, aby RISC obsluzyc. Borland kompilowal bezposrednio na x86.

Sa w bibliotece, razem z kodem procedury.

I teraz trzeba podzielic biblioteke na dwie czesci, zaladowac osobno do pamieci, zrelokowac wskazniki w kodzie programu ... albo uzywac w programie adresowania wzgledem PC i po zaladowaniu absolutnie nie przesuwac.

J.

Algorymika kopiąca w tyłek rejestr segmentowy jak sie nie mieścisz jest bardzo podobna. Dupa zawsze z tyłu.

Adres jest na 67kB. I co teraz? Masz szklaną kulę kiedy to robić bądź kiedy tego nie robić? Nie, masz if. Czyli cykle. Czyli dupa z tyłu jak zwykle. Rozmiar segmentu ma tylko znaczenie kiedy znasz rozmiar danych, wtedy można robić jakieśtam optymalizacje. Jak masz user input to nie.

Stronicowanie niczego nie rozwiązuje, jest tak samo durne jak przepinanie RAMu w Atari czy Commodore.

Memory mapped pliki mają jakiś związek z ogranizacją danych w pliku ;)? Coś nowego :D

Intel tego nie wymyślił, oni to tylko użyli. Oczywiście bez sensu może poza fake kompatybilnością z 8080.

To mówisz o pamięci wirtualnej z translacją adresów. Ma się to nijak do

Trudno oceniać co to znaczy przebijała. 68k to cholerne popularna architektura, niezliczona ilosć komputerów i urządzeń poganiana była tym procesorem z powodu tego że zaprojektowano go nie po pijaku, jak 386, był znacząco łatwiejszy.

CP/M na 68k był ale w roku 85 Commodore Amiga pokazała że nawet na 68000 można zrobić system z preemptive multitaskingiem, okienkami i całkiem współczesnym OSem. Patrzenie na mozliwosci Amigi i na CP/M powoduje kłopot jak porównywanie samochodu z gwoździem.

Dzielnie do 68060 walczyła z 486 czy wczesnymi Pentium.

Co może być mniej user friendly niż gówniany CP/M? Chyba że chodziło o to słynne "uproszczenie" co zazwyczaj oznacza prostactwo.

Cykle obchodzą. Jak musisz co dwie instrukcje poświęcać cykle na przerzucanie rejestrów na stos i z powrotem to nie jest to zupełnie nie Twoja sprawa.

Gdzie by nie poszli w przypadku x86 dupa zawsze z tyłu.

To że można nie oznacza niczego.

I tutaj x86 pokazuje swoją moc niemożności posiadania wydajnego i relokowalnego kodu na raz. Znowu ... a już się nie będę powtarzał.

Nie, skoro juz sie spodziewam duzych obrazkow, to wylicze sobie adres S:O, gdzie O bedzie nie wieksze niz 15.

Tu akurat mam - obrazki duze z natury, wiec zawsze :-)

W pewnym okresie moze i nie mialy, ale - jest w mmap parametr dlugosci okna. Czyli masz dostep tylko do kawalka. I

- dokumentacja sugeruje skromne rozmiary, np 4KB, to nawet gorzej niz na 86 :-)

- teraz dyski duze i pliki duze - jakbys chcial sobie kilka plikow po

Sensowny ruch dla 16-bitowego uP. Tylko czy powinni robic 16-bitowy uP ...

O segmentacji mowie, a jeszcze nie o pamieci wirtualnej. Ale segmentacji nie takiej jak w 8086.

Bo to dwa niezalezne mechanizmy, choc moga wystepowac razem.

Pamiec wirtualna pojawila sie wczesniej, ale w duzych komputerach.

Ale jakos tak latwiej bylo o peceta na 8086 niz na 68k. I "profesjonalne programy" byly na CP/M :-)

Choc np programy do projektowania plytek i schematow elektronicznych byly na unixowe workstation.

Ale tez popatrz na lata - kto jeszcze uzywal CP/M ? Jakas biedota :-)

Ale to juz 6-ta wersja, a gdyby byla taka dobra, to by Intel 386 nie dozyl :-)

Przyjemnie sie korzystalo z TurboPascala.

A jak patrzylem na znajomego bieglego w Unixie, ktory naprawde biegle wpisywal te komendy po 40-80 znakow, zeby kompilacje uruchomic ...

Z rzadka, czesto wystarczaja te rejestry co sa. Za to jak musisz co przerwanie odkladac tych 30 rejestrow na stos ... i potem sciagac ...

Przeciez prawie na jedno wychodzi, skoro i tak trzeba zaladowac, poprawic adresy, i juz nie ruszac.

J.

Próbowałeś choć z jednego zrobić Frankenpada?

-----