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ść)

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

8086 gdzie adres jest adresem fizycznym i fizycznej pamieci ram i nie ma żadnego OSa. Wirtualizacja pojawiła się później. Segmentacja do tego nie jest w ogóle potrzebna, np. 68k ma wirtualizację a nie ma segmentacji.

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ł.

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

-----