On 04/03/2019 09:02, Marek wrote:
>> przypadek, bo coraz bardziej nawiedzeni. Są zabawni kiedy sprawadza
>> się ich ideologie do poziomu podłogi bądź pokazuje elementarne
>> problemy w logice.
> Chętnie tak (w ramach dygresji) bym poczytał o tych ich problemach w
> logice i w czym są zabawni.

W tym samym co wszystkie religie i ideologie. Jednak nie zamierzam o tym
rozmawiać na grupie technicznej bo to poniżające nawet jako dygresja.

do góry

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.

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

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

> Oczywiscie, przy rozsadnym zalozeniu ze normalizujesz wskaznik np co
> linie, a linia nie ma ponad 64KB.

Oczywiście przy założeniu że nie będzie padać a i wiać też nie będzie to
jakoś ta prowizorka wytrzyma ...

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

Jesli procesor ma MMU to nie wraca. Każdy proces ma własną przestrzeń
wirtualną i nic nie wie o innych allokacjach.

Jak nie ma MMU to problem co najwyżej nie jest procesu tylko procesów.
Tak jak w Amidze.

> Zadania przychodza, koncza sie ...

I pamięc się fragmentuje. Podobnie w ramach procesu allokacje
przychodza, odchodzą a pamiec w kawałkach. Sorry, taki mamy podstawowy
model programowania do dzisiaj.

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

>> 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. To się da zrobić i robią to niektóre maszyny wirtualne
specjalizowane do poganiania Javi i C# w embedded. Ale tam jezyki nie
mają pointerów.

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

Mylisz segmentacje z wirtualizacją pamięci.

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

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

>> 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ęć. Kod obsługujący albo
ma na stałe offset i w gotowości relokator jak by trzeba było przenosić
albo jest całkowicie relokowalny.

kod x86 ma na tyle duży narzut na całkowitą relokowalność że szbciej
jest kod przerelokować automatycznie niż dodawać masę instrukcji
wydłubujących z żywego kodu PC.

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

I dlatego Windows 32 bit zazwyczaj DLLki relokuje po każdym załadowaniu.
Na Win 64 dllki mogą być już za darmo pisane względnie.

do góry

użytkownik Sebastian Biały napisał:

> Jeszcze takie podumowanie przerażająco dobrej jakości Apple:
>
> https://www.youtube.com/watch?v=AUaJ8pDlxi8
>
> Think Different!



Dzięki Apple ma robotę, dzięki filmom ze słowami kluczowymi Apple/MacBok/IPhone
też tłucze kesz. Nadmiernie stęka na swojego pracodawcę:)
OT. Apple chyba zrezygnowało z wykończenia pcb złotem na rzecz tańszego OSP
(selektywnie kładziony topnik czyli przemysłowe gówno zwiększające zawodność)

do góry

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.

do góry

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

do góry

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.

do góry

Próbowałeś choć z jednego zrobić Frankenpada?


-----
> A ja mam 3x t61.

do góry