Dnia Sun, 3 Mar 2019 18:26:38 +0100, Sebastian Biały napisał(a):
> 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.

Mowie o latwosci adresacji.

Na 8086 latwo i przyjemnie adresuje sie kawalki do 64KB.
Na 6502 - kawalki do 256B.

A jak mamy 1MB RAM, to znow znacznie latwiej sie to obrabia na 8086 w
malych kawalkach, niz na 6502 z dodatkowym stronnicowaniem.

To stronnicowanie sie zreszta w pecetach pojawilo, w postaci pamieci
EMS, jak juz 640KB przestalo wystarczac.
Ale przyznaje - to byl kanal :-)

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

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.

Albo np szukasz slowa w tekscie, i sie nie zastanawiasz czy
przypadkiem "owo" nie jest na nastepnej stronie.
Oczywiscie, przy rozsadnym zalozeniu ze normalizujesz wskaznik np co
linie, a linia nie ma ponad 64KB.

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

Jak pisalem - Z80 dalbym ze 12 bit.
Troche operacji 16-bit mial.
8086 byl w pelni 16 bitowym uP.

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

8086 byl calkiem zgrabny ... ale nie w maszynie z 1MB RAM.

No coz - ona nie miala miec 1MB, ani nawet 640K, a raczej 256KB :-)

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

Ale ciagle tak myslisz :-P

>> Mowisz pokraka ... a ja mowie "tworcze rozwiniecie".
>> I wez pod uwage, ze to byly lata 1976-78.
> To uniemożliwiało innowacyjność ;) ?

Nie, to byla innowacyjnosc na miare tych lat.
Gdy domowy Atari VCS mial 256B RAM, Apple II jakies 4KB,
a 68k jeszcze nie bylo - choc tez juz projektowali.

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

Ale widac byla to solidna podstawa do skoku :-)

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

Ja mowie szerzej. W 386 segmenty maja do 4GB - tylko juz ich chyba nie
uzywaja.

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

Ale jak wychodzimy z CP/M i zaczynamy robic wielozadaniowy system
operacyjny, to problem wraca.
Zadania przychodza, koncza sie ...

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

A jednak cos mi chodzi po glowie, ze jeszcze Odra miala relokacje,
tylko raczej na innej zasadzie - jeden rejestr, ktory byl dodawany do
wszystkich adresow ?

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

Bo program ma uzywac dla tej pamieci segmentu nr 3 np.

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

No wlasnie uzyc segmentow ... tylko w stylu 2/386.
Prosisz o duzo, to dostajesz dodatkowy nr segmentu,
a procesor ma gdzies tam zapisane gdzie sie segment zaczyna.

> samym językiem programowania C który daje do ręki pointery i pozwala na
> artytmetykę na nich.

IMO to raczej cecha uP .. zawsze bedzie ten problem.

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

No to jednak ponad te kompatybilnosc mocno wykroczyli.
Chocby ten rejestr BP i adresacja ramek stosu, swietnie pasujaca do
jezykow programowania jak C czy Pascal.

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

I nikt tego nie kupil :-)

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

W 1990 tez tak mowilem, ze dochodzimy granic technologii i duzo
szybciej nie te 40MHz to nie bedzie :-P

Ale ok, przekroczyc te 64-bit bedzie trudno .. chyba, ze znow cos
wymysla :-)

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

Ta ortogonalnosc nie jest tak znow niezbedna.

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

No widzisz - sam chwalisz :-)

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

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.

I całosc dynamicznie linkowana i nie wiadomo pod jakim adresem sie
znajdzie po załadowaniu.

J.