🚀 go-pugleaf

Erik Warmelink <erik@flits102-126.flits.rug.nl> wrote:
>In article <slrn7pdmgk.v6r.nomail@linux.pe1chl.ampr.org>,
>	nomail@pe1chl.demon.nl (Rob Janssen) writes:

>> Bij een Intel processor bestaat een volledig adres uit een 16 bits segment
>> (eigenlijk een selector in de mode waarin de processor nu staat) en een 32
>> bits offset.  Totaal dus 48 bits.
>> 
>> Het nut is dat je daarmee meer dan 4GB kunt adresseren.  Of je dat nodig
>> vindt moet je zelf bepalen.

>Voorzover ik het begrepen heb, moet je daarvoor ook de wijze van
>adressering in je OS aanpassen. Dan kan het voor bepaalde toepassingen
>wel makkelijk zijn, maar in veel gevallen heb je het niet nodig
>(ook al omdat de CPU al dat geheugen toch niet kan aanspreken). Het
>geeft echter ook overhead voor programma's die dat geheugenbereik niet
>nodig hebben.

Je redeneert in een kringetje!  Het (Linux) OS kan al dat geheugen niet
adresseren omdat er voor gekozen is om die bovenste 16 bits niet te
gebruiken.  Dat is dus niet de reden om het niet in te voeren.

"niemand heeft meer dan 640K nodig" is een goed argument om bepaalde design
beslissingen te nemen, maar je kunt er wel mee op de koffie komen.  nu
beginnen we het punt te naderen waar dit met 4GB gaat gebeuren, en het zou
wel een beetje vreemd zijn om dat nu met hetzelfde argument af te houden
als waarmee destijds die 640K limiet ingevoerd is.

Bedenk ook dat als je files van meer dan 2GB gaat supporten, deze niet
in memory gemapped kunnen worden als je maar 32 bits virtueel adres
support.

(in de begintijd van Linux heb ik wel eens met Linus van gedachten
gewisseld over het idee om in de kernel altijd een memory mapping van alle
partities paraat te houden als basis van de file systemen.  filesystem code
zou dan gewoon in virtueel memory kunnen kliederen in plaats van moeizaam
diskblokken lezen en schrijven, bijvoorbeeld bij directory updates.  de
algemene virtueel memory routines zouden dan automatisch het lezen en
schrijven regelen.  er zijn operating systems (geweest), zoals Multics,
die het zo deden.  een van de hoofdredenen waarom het hem niet zo'n goed
idee leek was dat het de partitiegrootte die je comfortabel kunt beheren
zou beperken tot 4GB.  de Alpha was toen nog niet in beeld)

>Het volgende weet ik wel vrij zeker (en als ik dat mis heb, was mijn
>reactie inderdaad overdreven fel; in dat geval mijn excuses): je zult
>meer instructies moeten gebruiken voor een pointer dereference (je zult
>immers een segment register moeten laden), dat is toch wel een vrij stevige
>overhead. Aan "mixed memory" modellen (die een deel van die overhead
>weghalen) heb ik niet de plezierigste herinneringen om eerlijk te zijn.

Ja nu zeg je "small model is makkelijker" en dat is ook zo, maar dat wil
nog niet zeggen dat een volledig adres op een Intel processor geen 48 bits
is.  En daar ging het om.

Rob
-- 
+----------------------------------+--------------------------------------+
| Rob Janssen     pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet:     rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+