Hoe is het geheugenbeheer nu eigenlijk ?

Is het niet mogelijk om het geheugen te scheiden in een deel alleen voor
applicaties en een deel alleen voor data. Deze twee virtueel gescheiden
geheugen gebieden kunnen natuurlijk dynamisch groeien en krimpen en
uiteraard ten koste van elkaar. Swappen naar hdd moet natuurlijk ook
mogelijk blijven.

En dat de applicaties ook achter elkaar in het voor applicaties bestemde
geheugen liggen, zeg maar geen fragmentatie en als dit gebeurt dat het
OS de boel weer netjes archiveert. Ik denk wel dat op deze manier dat je
alleen nog maar software kan schrijven volgens het virtuele machine
principe.

Dan kun je een globaal code en data bit gebruiken, het nx bit zeg maar.
En vervolgens gebruik je voor iedere applicatie ook nog een keer eigen
afscherming en ook voor iedere data gedeelte per applicatie.


Gebeurt dit al ? Of moet de IA32 en IA64 architectuur op de helling ?

Is het niet mogelijk om de MMU tjes nog verder uit te breiden en dat het
hele concept van programma draaien herzien moet worden door gebruik te
maken van gespecialiseerde eenheden in de processor. Net zoiets als
CELL bedoeld is voor dsp berekeningen.

newsflash: Er is geen wondermiddel

Tuurlijk wel,
Alleen moeten we een andere architectuur gebruiken.
Oftewel hoe ver wil je gaan.
In de visie van de huidige generatie is dat niet mogelijk en dus klopt jou
antwoord vanuit dat perspectief.

dsp berekeningen is niet helemaal een goede uitspraak sorry.

Ik bedoel meer gewoon dat je voor bepaalde berekeningen een
gespecialiseerde eenheid kunt gebruiken. voor booleaanse en simpele
rekenkundige acties een standaard alu. Voor Fp berekeningen je floating
point unit. Een mmu voor geheugen beheer. Is de mmu niet uit te breiden
met een extra functies ? Puur bedoeld voor afscherming. Ik denk dan wel
dat je alle opcodes moet herzien dus zal ia32 of ia64 nooit een oplossing
kunnen bieden.

Ja, maar een mmu kan niet zien of een byte code of data is,
dat wordt dus aangegeven met het NX.

Ik weet het niet hoor, als ik intern in de chip nu met 72 bits werk
(even niet aan ecc bits denken).
Dan heb ik 64 bit mogelijkheden en 8 bits om aan te geven wat
de 8 bytes aan data voorstellen, code of data of stack of tabel,
desnoods rauwe data als muziek of video dan weer algorithmes.
Ieder met eigen beperkingen en mogelijkheden.
Maar dan kom ik op mijn eigen
antwoord terug, dan moeten we af van de ia32 en ia64
architectuur en dat is helaas een utopie op korte termijn.
Het systeem zoals we nu hebben ondergaat een evolutie maar
moet altijd compatibel blijven. Je ziet bijvoorbeeld verwoedde
pogingen van intel om de legacy hardware te dumpen. Microsoft
doet steeds een kleine poging om hun besturingssysteem te
verbeteren en oude legacy problemen te verhelpen.
Toch had bijvoorbeeld lang terug al een hoop 16 bit problemen
kunnen verkomen door een virtual machine in het echte 32 bits
windows in te bouwen. Dan kun je veel meer controleren omdat
je gebruik maakt van emulatie. de hardware is al enkele jaren
snel genoeg. Op die manier kun je ook compatibiliteit in bouwen.
We moeten meer en meer naar virtual machines toe en dat kan
alleen als er een hele andere filosofie van programmeren
aangeleerd gaat worden.

Het grootste probleem ligt volgens mij in het Object Oriented Programmng
model, waarbij bij het instantieren van een class met code en data deze
samen bij elkaar op de heap worden geplaatst. Compilers van software
zouden moeten worden aangepast dat de objecten van geinstantieerde
classes moeten splitsen in data en code blokken, waarbij de datablokken
worden voorzien van de NX bit.