On 05/03/2019 11:21, J.F. wrote:
>> I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko tą
>> zaletę że robisz to w cpu.
> Mam te zalete, ze ten segment jest przesuwny i obejmuje prawie 64KB.

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

>> 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.
> Nie sprawdzam - wyliczam adres pixela, jego trzy bajty sie w segmencie
> zmieszcza.

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.

> 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 :-)

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

> Nawiasem mowiac - gdzies w TIFF jest "chunk size", ktos przewidzial, ze
> moze byc dobrze podzielic obrazek na kawalki nie wieksze niz np 8KB.
> I to nie tylko w 8086 sie sprawdza - np te "memory mapped" pliki w unixie.

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

> https://en.wikipedia.org/wiki/Memory_segmentation
> I nie zaczyna sie od "8086 ..."

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

>>>> Bo to problem segmentacji pamięci i jest obecy w każdej współczesnej
>>>> sytuacji kiedy nie ma kompaktacji pamięci. Segmenty nic nie zmieniają
>>>> ani nie ułatwiają.
>>>>> Z segmentami (ale nie takimi jak w 86) by sie dalo.
>> Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i wskaźnik
>> jest iwalidowany.
> Nie musi wiedziec, bo wskaznik sie nie zmienia.
> 3:1500  pozostaje, i tylko system wie, ze segment 3 jest teraz polozony
> gdzie indziej.

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.

> Nawiasem mowiac - mimo niewatpliwych zalet, zobacz jak dlugo sie 68k
> przebijala.

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.

> 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 :-)

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.

> A moze jednak tak ogolnie 68k kiepska byla ?

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

> Albo unix byl za malo "user friendly" i za drogi ?

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.

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

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.

> A i tak nie wiadomo, czy tak trzeba, czy tworcy kompilatorow poszli w
> takim kierunku, aby RISC obsluzyc.

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

> Borland kompilowal bezposrednio na x86.

To że można nie oznacza niczego.

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

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