On 03/03/2019 17:44, J.F. wrote:
>> 6502 - Procesor mający 64kB liniwej przestrzeni widzący resztę pamieci
>> przez okna przemieszczane rejestrami sprzętowymi
>> Coś pomyliłem?
> O tak, 6502 - procesor majacy 256B przestrzeni liniowej,
> przemieszczane gdzies w 64KB przestrzenii adresowej.

Mówisz o indeksowaniu X,Y. Podobnie ograniczenia, np. odległości brancha
ma każdy współczesny CPU i to nie jest to samo.

> Poza tym masz np obrazek duzy.
> Ustawiac segment na pocztek n-tej linii masz w ramach 64KB dostep do
> tej linii (przy sensownym rozmiarze), moze nawet do kilku nastepnych.
> W stronnicowanym Atari musisz co chwila sprawdzac.

Nie, kod jest koncepcyjnie identyczny jeśli mówimy o 64kB. Sytuacja że
segmenty mają jakąś zaletę że na siebie zachodzą jest mało prawdopodobna
z powodów obliczeniowych.

>> Tak, detalicznie rzecz biorąc 8086 miał kilka okien
>> jednocześnie i możlwiość liczenia na parach rejestrów. Znaczy lepszy.
> Byl 16-bit, a nie bit. Znacznie lepszy :-)

Z80 łaczył rejestry w pary. Czy to oznacza że był 16 bit?

>>> no i troche pretensji do Intela za 286 - to juz nie byl czas, zeby tak
>>> komplikowac.
>> 386 to też nie był ten czas. 486 tym bardziej. Pentim to już 3x
>> przegięcie. A mimo to rewolucja przyszła dopiero z AMD kiedy po raz
>> pierwszy Intel posikał się w pieluchę i musiał dorabiać na kolanie AMD64.
>> Ta firma jest niereformowalna.
> O, bez przesady. W koncu jednak to oni wymyslili mikroprocesor.

Nie, oni tylko stowrzyli pierwszy komercyjnie osiągalny w mniej więcej
jednej obudowie, dodatkowo 4004 jak się patrzy w asm to był z zupełnie
innej beczki niż 80xx.

> 386 byl w miare dobry, i jak widac nie trzeba go bylo zmieniac ...
> dlugo.

Bo nareszcie zaczynał przypominać normalny procesor a nie workaround nad
8bitami.

>> Inne procki albo nie udawały że potrafią więcej albo od razu były
>> normalne. Intel zrobił pokrakę mającą za zadanie podstawowe utrzymać
>> model programistyczny z 8 bitów. Żadnej innowacji, żadnego wizonerstwa,
>> tylko utrzymanie kompatybilności z Zx Sp^M^M^M^M8086.
> Nie z ZX Spectrum tylko z CP/M na 8080.

Przecież skasowałem.

> Mowisz pokraka ... a ja mowie "tworcze rozwiniecie".
> I wez pod uwage, ze to byly lata 1976-78.

To uniemożliwiało innowacyjność ;) ?

> A przy okazji - widac ktos docenil rozwoj srodowiska CP/M, skoro
> zachowal kombatybilnosc, co uzasadnia przymiotnik "profesjonalny" :-)

To nie jest docenienie tylko wybicie się na ramionach CP/M.

>> nie miał zostać lub być dynamicznie przemieszczany to bez wiedzy
>> programu nie da się tego zrobić. Segmenty niczego tu nie naprawiają.
> A widzisz - nie.
> Ale musisz z 86 przeskoczyc do 286

Ale my rozmawiamy o 8086. Za chwile ktos wyskoczy że segmenty mają 4GB i
o czym mowa. No wiec mowa o 8086.

> System mogl przeniesc zawartosc pamieci, zmienic dane w tablicy i
> wznowic prace programu.

Kompaktacja pamięci pojawił się dopiero w językach w których nie ma
pointerów (z popularnych Java C# i inne). Wiedza o tym że ktoś
przemieszcza mi pointery w programie musi istnieć, program musi być na
to gotowy. Przestrzeń, nawet wirtualna, programu jest niestety stabilna
adresowo i samo się nic nie dzieje. A co robi MMU to nie ma żadanego
znaczenia bo to nie o tym mowa. Do dzisiaj nie da się automatycznie
kompaktować pamięci w programach pisanych w C i w milionie innych
języków. Nic tu segmentacja nie pomaga.

>> Segmentacja pamięci *NIE* ma żadnego praktycznego zastosowania które
>> jest lepsze od pamieci liniowo dostępnej.
> Wyobraz sobie tak - alokujesz 1 GB pamieci.
> System przydziela od adresu 0.2G, bo nizej juz zajete.
> Potem alokujemy drugi obszar, 100MB, wypada od adresu 1.2G.
> Teraz chcemy rozszerzyc ten pierwszy do 1.3G
> I tu juz system mowi, ze tak sie nie da - nie ma rozszerzania, bo nie.
> Moze przydzielic nowy obszar - ale to nie calkiem to samo.
> A z segmentami by sie dalo.

A jak? Żeby program nie wiedział i żebyś nie pomylił segmentacji z
translacją wirtualna->fizyczna MMU.

> No to przydzielmy nowy - od adresu 1.3 do 2.6G.
> Rozszerzmy go jeszcze raz do 1.5G ... i system mowi, ze sie nie da,
> bo mu przekroczy 4G (na 32 bit procku).
> 4GB pamieci, a nie mozna 1.5GB zaalokowac :-)

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.

Dalej nie rozumiem jak chcesz między adres A i B wcisnąć więcej niż
wynika z ich różnicy i bez wiedzy programu. Nie da się i najlepszym
dowodem na to jest fakt że 32 bitowe programy cierpią na fragmentację do
dzisiaj i nic z tym nie da się zrobić bo to fundamentalny problem z
samym językiem programowania C który daje do ręki pointery i pozwala na
artytmetykę na nich.

> Oczywiscie idealne to nie jest - trzeba dodatkowo ten nr segmemtu
> zapamietywac, zazwyczaj jest ich ograniczona ilosc - wiec wychodzac z
> jednej pulapki pakujemu sie w druga :-)

Segmenty niczego nie rozwiązywały i niczego nie rozwiązują. Oni
potrzebowali tylko i wyacznie kompatybilności koncepcyjnej z 8080 i jak
najmniejszych kosztów. Dorabianie filozofii do tego jest kiepskim pomysłem.

> Rozwiazaniem moze byc przejscie na system 64-bit ... na jak dlugo
> starczy ? :-)

Na znacznie dłużej niż 2x dłużej. Jakieś 4mld razy dłużej, nawet mając
temp wzrosu z okolic e^x to powoli osiągamy limity sensu w grafice wiec
to przyśpieszczenie nie jest aż takie duże jak na początku.

>> Jak się nie obrócisz dupa z tyłu. To motto Intela i ich profesjonalnych
>> produktów.
> Powiem tak: jakos im to dzialalo i to bez wiekszych narzekan ze strony
> programistow. Widac tak sie profesjonalnie rozwiazuje problemy :-)

Narzekań? Narzekałeś kiedyś na słońce że w dzień świeci? Do wyboru nic
innego nie było. Święte wojny między 68k a 386 ujawniły jednak jak
żąłosną architekturą było nawet to 386 z kilkoma specjalizowanymi
rejestrami, praktycznie zerową ortogonalnością itd itp. Tylko że wtedy
było się z czym równać. W przypadku 8086 zapewne każdy założyl że lepiej
być nie może.

>> PC był niedostepny z kodu i dalej jest niedostępny, dopiero AMD64 coś
>> tutaj zrobiło.
> Nie pamietam ... ale nie pamietam tez jak sie czytalo, to mozesz miec
> racje.
> Ale ... nie wystarczy udostepnic PC, bo co bedzie, jak miedzy
> obliczeniem adresu a uzyciem danych przyjdzie przerwanie, a w nim
> system zechce przesunac obszary ?

System nigdy nic nie przesuwa. Poza kompaktującymi GC ale wtedy Twoje
problemy są zupełnie gdzie indziej niż czytanie PC.

>>> Za to w innych ich troche brakowalo, i trzeba bylo sztucznie
>>> wprowadzac.
>> A gdzie.
> Cos mi tak chodzi po glowie, ze wlasnie w MC68k w unixach uzywano
> starszych bitow adresu, jako swego rodzaju identyfikacje segmentu.

Nie ma segmentów w 68k, nie można wykluczyć że hardware traktowało
niektóre bity adresowe do swoich celów ale to nie było typowe.

> Albo cos takiego - jest funkcja, ktora wymaga tablicy
> danych/parametrow.
> I mozna ja wywolac z tablicą uzytkownika, lub jedną z predefiniowanych
> w bibliotece.

I co broni podać normalny pointer do tej tablicy?

> Tylko funkcja nie wie, ktora jej przekazujesz, skoro to jest po prostu
> adres. Nie wie, czy ma sie odwolywac relatywnie do PC, czy nie.

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. Wiele procesorów
nie ma z tym problemu do momentu kiedy ktoś zaczyna wstawiać zbiory
danych do kodu. Trzeba jakoś poinformować "czytamy hurtowo dane o 40
bajtów dalej" i wtedy wychodzi problem z brakiem lub obecnością PC bo
jakoś adres tego "dalej" trzeba jednak policzyć. Podobnie kiedy trzeba
skoczyć dalej niż ograniczenie branchowania, bez PC nic nie zdziałasz
bez hackerstwa.

> Wiec te predefiniowane tablice trzeba jakos inaczej zapamietac - kod
> programu funkcji jest relokowalny, a dane stałe nie..

Oba sa relokowalne z definicji jesli CPU ma wsparcie dla relokowalnego
kodu. Wyjątek jest wtedy kiedy dane mają pointery. Wtedy używano
powszechnie automatów relokujących kod. Tak czy inaczej dostępnośc PC
ułatwia życie bo kod jest od razu gotowy i może być współdzielony między
procesami.

> No wlasnie - jak sobie z tym wspolczesne systemy radza ?
> Mam np bilbioteke, funkcja w bibliotece ma troche stalych danych.
> Biblioteka ladowana dynamicznie, w dodatku np wspoldzielona, i wzorem
> linuxa - w kazdym procesie dostepna pod innym adresem.

Jest kompilowana z -fpic co generuje kod relokowalny. Dodatkowo ponieważ
każda instancja pechowo trafia pod inny adres to jest kolonowana jeśli
zawiera dane wymagające relokacji jak pointery. Ponadto wiele biblitek
zawiera dane niewspółdzielone, jak zmiennie globalne w procesie i one
muszą miec własne instancje.

Ale jeśli wszystkie procesy mają wolną tą samą przestrzeń pamięci to kod
jest współdzielony i nie które dane też. Jeśli mają tą samą biblitekę w
innych obszarach pamięci to albo kod też można współdzielić (bo jest
względny) albo trzeba klonować i relokować.

Windows bardzo dużo kodu klonuje. Nie bez powodu w Win jes tcoś takiego
jak domyślny adres dll, pozwala to czasami nieco zoptymalizować
aplikacje mające kilka procesów.