Dzieki intel? [Re: Dzi ki, IBM (Bylo: Re: Dzi ki, Gates)]

Autor: Gregorio Kus (Grego_at_RMnet.it)
Data: Wed 29 Jan 1997 - 02:11:47 MET


On Tue, 28 Jan 1997 14:01:34 +0100 (CET), Jarek Lis wrote:

>In pl.comp.pecet Gregorio Kus <Grego_at_RMnet.it> wrote:
>: to nadal nie tak
>: :-)
>: procesor oczywiscie ZAWSZE (czy pod winda czy pod DOSem) mogl
>: korzystac z calego RAMu :-)
>
>A nie [cala] prawda :-). Procesor 286 w zasadzie pod DOS nie mogl
>zaadresowac wiecej niz 1.064 MB pamieci.

mogl jak najbardziej. Tryb protected byl juz w 286
i juz w momencie wypuszczenia 286 mozna bylo napisac calkiem
niezly system operacyjny. Z ochrona pamieci, pamiecia virtualna,
multitaskingiem preemptywnym itd. Wlasciwie to nawet powstal
taki system (Xenix) ale nie okazal sie konstrukcja zbyt udana.
Najwieksza wada 286 okazala sie trudnosc z uzywaniem starych
programow pod systemem w pelni wykorzystujacym 286. Zanim by
powstaly nowe (pracujace w trybie chronionym) trzeba bylo
zapewnic poprawne funkcjonowanie starych, tymczasem o ile
przejscie z real (w ktorym startuje procesor) do protected
bylo latwe, o tyle (w 286, bo w 386 intel to poprawil) powrot
do trybu real
  [konieczny az nazbyt czesto, bo typowe programy DOSowskie
   tak dalece siegaly do sprzetu, ze wzgledu na kiepski BIOS
   i DOS iz najczesciej nie wystarczalo ich odpalic w trybie
   virtual]
byl skomplikowany i nieefektywny.

to po pierwsze. A po drugie Jarku - uwaga jest nieco nie na temat
bowiem jak pisal Grzegorz - dopiero pod winda procesor mogl
korzystac z calego RAMu. Stad moja uwaga - PROCESOR zawsze mogl.
(nie mogly normalne programy dosowskie, a to co innego)
[nienormalne - owszem mogly. sam takie pisalem]

>Taki 386 bez emm386 tez niezbyt.

niewazne winda, emm, czy rozne DOS extendery, wazne ze w trybie
protected, a tryb protected mozna bylo odpalic juz na 286.

>Tylko MS odkryl drobny blad w procesorkach 286, ktory powoduje ze
>i wiecej jest pod DOS dostepne.

to tylko 64kB (minus 16B). W dodatku to nawet nie byl blad.
Bledem bylo jedynie to, ze czesc "pomyslowych" programistow
(szkola C :-)) ) uzywala na procesorze 8088 czy 8086 adresow
$FFFF:x gdzie x >= 10H jako ekwiwalentow adresow zaczynajacych
sie od 0:0, przez co ich programy przestawaly dzialac na 286.
Tylko ze wzgledu na te programy musiano wprowadzic do chipset'ow
PC AT (i robi sie to nadal mimo iz takiich programow juz chyba
nie ma) specjalna obsluge 20tej linii adresowej, zapewniajac
ze w trybie real bedzie ona miala zawsze stan 0, a zmiany jej
stanu trzeba w specjalny sposob "zazadac", co zapewnia np HIMEM.SYS
udostepniajac ten dodatkowy segment zwany HMA rowniez programom
pracujacym w real mode.

>Tak i m sie blad spodobal, ze w 386 i nastepnych tez musiano go
>wprowadzic...

jezeli komus sie ten "blad" spodobal, to napewno nie intelowi.
(a M$ nie mial tu nic do "wykrywania", zasada adresowania byla
ta sama tzn. adres fizyczny = segment << 4 + offset)
i napewno nie byl to ich blad. Wylacznie brak wyobrazni
programistow myslacych po staremu tzn. oszczedzajacych pojedyncze
cykle i bajty. Jak inaczej intel mial to zrobic przechodzac
z 20 bitowego adresowania (fizycznego) na 24bity a potem na 32?
i zapewniajac kompatybilnosc wstecz?

Grego

p.s.
nawiasem mowiac w zdaniach:
>A nie [cala] prawda :-). Procesor 286 w zasadzie pod DOS nie mogl
>zaadresowac wiecej niz 1.064 MB pamieci.
>Tylko MS odkryl drobny blad w procesorkach 286, ktory powoduje ze
>i wiecej jest pod DOS dostepne.
tez jest blad. Pownno byc: "wiecej niz 1MB", bo wlasnie po wyzyskaniu
A20 (czyli wlasciwie dwudziestej pierwszej linii adresowej) uzyskiwalo
sie +64k-16. Z Twojej wypowiedzi mozna wywnioskowac ze pod DOSem
(czystym) programy moga uzyskac wiecej niz 1.064M, a to nie prawda.

--
/-----------------------------------------------------------------
Gregorio Kus         Grego_at_RMnet.it           Grego_at_cyberspace.org
ROMA, Italy          2ndAdmin_at_iName.com       Grego_at_FreeNet.hut.fi
Anonymous Mail Service - http://free.rmnet.it/~grego/AnonMail.html


To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:53:22 MET DST