Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:q5mjqq$qnm$...@n...news.atman.pl...
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?

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

> Masz szklaną kulę kiedy to robić bądź kiedy tego nie robić?

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

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

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
1GB otworzyc, to sie 32-bitowa przestrzen skonczy :-)

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

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

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

O segmentacji mowie, a jeszcze nie o pamieci wirtualnej.
Ale segmentacji nie takiej jak w 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.

Bo to dwa niezalezne mechanizmy, choc moga wystepowac razem.

Pamiec wirtualna pojawila sie wczesniej, ale w duzych komputerach.

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

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.

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

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

>> A moze jednak tak ogolnie 68k kiepska byla ?
>Dzielnie do 68060 walczyła z 486 czy wczesnymi Pentium.

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

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

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

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

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

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

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

J.