eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaCP/M i 64kBRe: CP/M i 64kB
  • Data: 2019-03-02 01:10:40
    Temat: Re: CP/M i 64kB
    Od: "J.F." <j...@p...onet.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    Dnia Fri, 1 Mar 2019 20:17:58 +0100, Sebastian Biały napisał(a):
    > On 01/03/2019 05:08, J.F. wrote:
    >>> Nie była liniowa. Była podzielona na okna po 64kB przemieszczane
    >>> rejestrami segmentowymi. Niewielikie usprawnienie względem Atari czy
    >>> Commodore które miały to zrobione w hardware. Atari obsługiwało 1MB po
    >>> kilku przeróbkach i kod wyglądał tylko troche bardziej strasznie niż x86.
    >> Bez przesady ... 1MB na 8 bit procesorze i stronnicowany 8 czy 4K ...
    >> to musialo byc straszne :-)
    >
    > No było straszne na 8086. 8-bit procesor wsadzony w udawane 16 bitów z
    > adresacją prawie z Atari :D
    >
    > Ultimate 1MB w Atari jest używane głównie przez demoscene, ale takie np.
    > Atari 130XE miało własnie przepinany dodatkowy RAM i było to niejako
    > wbudowane w hardware. Taka segmentacja, prawie jak w 8086 :D

    No nie, nie przesadzaj z porownaniami.

    >>> A kto im probił zrobić rejestry adresowe 20 bitowe? Reglamentacje mieli
    >>> w korpo? Jakoś 68k nie miał problemu z byciem 16 bitowym hardwareowo,
    >>> ale model programistyczny miał 32 bity.
    >> te 16 bit to chyba tylko szyna zewnetrzna i multiplikator.
    >> Reszta byla 32-bit.
    > Model programistyczny był 32 i to się liczyło. Jak już zaczynać jakąś
    > architekturę to wydaje się że idiotyzmem jest to robić od 8 bitów a tu
    > się okazuje że Intel dał radę ...

    Albo inaczej - bardzo zgrabnie zrobil ... 16-bitowy procesor.
    Zreszta mial dobry wzorzec :-)

    >> 20-bitowe rejestry bylyby raczej trudne w obsludze.
    > 12 bitów na górze mogło by być fake. Nie widzę problemu.

    No ale mial byc 16-bitowy procesor.
    Pretensje do IBM, ze go wybralo,
    no i troche pretensji do Intela za 286 - to juz nie byl czas, zeby tak
    komplikowac.

    >>>> Najdurniejszym pomysłem było to, że strony były zrobione po 16B, zamiast po
    prostu po 64kB.
    >>> Nic by to nie dało. Segmentacja bez względu na szerokość to idiotyzm w
    >>> czystej postaci.
    >> No, tak w ogolnosci ma pare zalet.
    >> Np. pozwala zmniejszyc fragmentacje przestrzenii adresowej.
    >> Wyobraz sobie, ze uzywasz w programie kilku duzych tablic,
    >> o zmiennym rozmiarze. Czyz nie byloby wygodnie, gdyby kazda z nich
    >> byla w osobnym segmencie, adresowanym od zera ?
    >
    > Nie ponieważ powoduje to powstawanie dziur na końcach obszarów i nic nie
    > daje bo procesory od wieków potrafią indeksować od dowolnego adresu. No,
    > oczywiście poza 8086 który niewiele potrafi w temacie liniowego dostępu.

    Ale ty patrzysz przez 86, a tu trzeba przez model 286, a nawet 386.

    > Innymi słowy segmentacja nie ma żadnej zalety. Ma za to absurdalny
    > overheat w kodzie i absurdalny wpływ na języki programowania takie jak
    > farptr i inne debilizmy wypływające w kodzie źrodłowym.

    Kiedy wlasnie IMHO u intela jest to prosto zrobione, a inne procki ...
    roznie bywa.

    >> Czy np problem C i innych podobnych jezykowi i unixow/innych systemow.
    >> Program ma swoj kod.
    >> I wymaga pamieci danych, stosu na adresy powrotow i zmienne funkcji,
    >> oraz sterty pamieci do alokacji.
    >> Gdzie je ustawic, jesli wstepnie nie wiadomo ile tego stosu i sterty
    >> trzeba ?
    > Segmentacja tego problemu nie rozwiąże, to jest fragmentacja typowa dla
    > nawet współczesnych procesorów tylko mniej bolesna z powodu warstwy
    > abstrakcji na pamięć.

    Ale te segmenty mozesz przesuwac (nie w 86).

    > Jak mówie każdy procesor potrafi adresować
    > względnie, względem byleczego i liniowo. Poza 8086. 8086 jak zwykle
    > dzielnie rozwiązywał problemy niespotykane nigdzie indziej.

    No to juz 286 mial ladnie zrobiona wzgledna adresacje ... tylko
    niestey 16-bitowa, no i bez wirtualnej pamieci.

    >> A do tego program uzywa kilku bibliotek, ktorych pewnie beda uzywac
    >> tez inne programy/procesy.
    >> Gdzie je zaladowac do pamieci, jesli procesor nie pozwala na kod w
    >> pelni relokowalny ?
    > A czemu nie pozwala? Przypomne że 8086 to taki g... że aby napisać
    > program z fetchem względnym trzeba robić wygibasy rodem z hackingu aby
    > odczytać PC.

    Ale po co chcesz odczytywac PC ? Dajesz przedrostek CS:
    No i raczej pisze o nastepcach niz o 8086.

    A 68k pozwalala na w pelni relokowalny kod, czy tez trzeba bylo
    wygibasy robic ?

    > Znowu walczymy z debilizmami architektury która
    > najzwyczajniej była jedną z najgorszych w historii informatyki. I
    > segmenty tego nie rozwiązują.

    Za to w innych ich troche brakowalo, i trzeba bylo sztucznie
    wprowadzac.

    J.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: