Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:q5jrg8$8sq$...@n...news.atman.pl...
On 03/03/2019 22:34, J.F. wrote:
>> A jak mamy 1MB RAM, to znow znacznie latwiej sie to obrabia na 8086
>> w
>> malych kawalkach, niz na 6502 z dodatkowym stronnicowaniem.

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

>> O co innego chodzi. Masz np obrazek 24b/pixel.
>> Obliczasz adres trzech bajtow pixela w pamieci seg:offset,
>> i masz w trzech kolejnych bajtach dane. I nie zastanawiasz sie czy
>> przypadkiem drugi lub trzeci bajt nie leza na innej stronie, i
>> trzeba
>> ja zmienic.

>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.
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
8KB.
I to nie tylko w 8086 sie sprawdza - np te "memory mapped" pliki w
unixie.

>> Albo np szukasz slowa w tekscie, i sie nie zastanawiasz czy
>> przypadkiem "owo" nie jest na nastepnej stronie.
>Bo teksty z definicji nie przekraczają 64kB ...

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

>>> A jak? Żeby program nie wiedział i żebyś nie pomylił segmentacji z
>>> translacją wirtualna->fizyczna MMU.
>> Bo program ma uzywac dla tej pamieci segmentu nr 3 np.

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

https://en.wikipedia.org/wiki/Memory_segmentation

I nie zaczyna sie od "8086 ..."

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

>> Nawiasem mowiac - chcieli lepiej
>> https://en.wikipedia.org/wiki/Intel_iAPX_432

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

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 ?

>>> żąłosną architekturą było nawet to 386 z kilkoma specjalizowanymi
>>> rejestrami, praktycznie zerową ortogonalnością itd itp.
>> Ta ortogonalnosc nie jest tak znow niezbedna.

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

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.

>>> Nie musi tego wiedzieć, skoro podałeś adres to pod nim spodziewadz
>>> się
>>> danych. Mówisz o offsecie. Ale nawet wtedy nie o to chodzi. Kod
>>> relokowalny ma TAKIE SAME pointery jak nierelokowalny. Róznica
>>> jest
>>> tylko w tym że KOD może być dowolnie umieszczony w RAM.
>> A tu jest kod i dane.
>> Np procedura rysowania znakow na ekranie, i dane z fontami.
>> Font moze byc dowolny, ale jest kilka predefiniowanych w
>> bibliotece.
>Ich dane są gdzieś załadowane fizycznie w pamięć.

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.