flat assembler
Message board for the users of flat assembler.

Home Search Register
Log in to check your private messages Log in

Index > MenuetOS > Memory map and address space of meOS/koOS?
Author
Thread Post new topic Reply to topic
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav 09 Nov 2010, 16:55
I was wondering if i rightly understood the way applications work in 32bit meos or kolibrios.
The apps are assembled with offset 0x0, so does that mean that the entire address space from 0 up to some limit is is for the application, with entry point at 0?

If so, what constitutes a null pointer there, and how do they catch null pointer errors?

Secondly, what is the general memory layout of the kernel and application address spaces?
Post 09 Nov 2010, 16:55
View user's profile Send private message Visit poster's website Reply with quote
Tolle



Joined: 21 Jan 2004
Posts: 71
Tolle 09 Nov 2010, 17:49
NULL != 0

A NULL pointer is a "convention" and although NULL usually equals zero in popular languages and implementations, there is nothing stopping you from defining NULL as -101. (If you write your own small memory manager)

Memory is handled in a very straightforward way in Menuet, You define how much memory you need in the header (you can expand it later), and you can make your memory management as simple or complex as you want. You can look at it as a flat "field" of bytes that are available to you.

At the beginning of this memory lives your program (you can write "self modifying" code) and at the end of your program a pool of memory is available for you. You can use static addressing (e.g. everything is always at the same offset), or code your own "memory manager" to use dynamic offsets. You can even use a combination of both.

Just experiment with the provided example.asm (Try to print the "MENUET" that is embedded in the header, try placing the text strings in other locations, try overwriting the text strings,...)

Experiment, have fun.
Post 09 Nov 2010, 17:49
View user's profile Send private message Visit poster's website Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav 09 Nov 2010, 18:47
Tolle wrote:
NULL != 0

A NULL pointer is a "convention" and although NULL usually equals zero in popular languages and implementations, there is nothing stopping you from defining NULL as -101. (If you write your own small memory manager)
Certainly. Which raises the original question #1 - is there, and which is it, the convention for NULL pointer in menuetos family?

And, question #2 - what happens to botched pointers in meos?
In windows at least, there is an access trap for 0h-FFFFh, to detect many NULL and NULL+offset pointer dereferencing. I gather there is nothing like that in meos?

Tolle wrote:
Experiment, have fun.
Sure, i'll likely be able to grind thru it on my own, but getting a system design doc/faq would be nice.


As far as i can tell, the idea of 0x0 start was correct, here is the GDT kolibriOS use:
Code:
GDT[0x01]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Accessed, 32-bit
GDT[0x02]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
GDT[0x03]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Accessed, 32-bit
GDT[0x04]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
GDT[0x05]=Code segment, base=0x800f0000, limit=0x000fffff, Execute/Read, 32-bit
GDT[0x06]=Data segment, base=0x800f0000, limit=0x000fffff, Read-Only
GDT[0x07]=Code segment, base=0x000f0000, limit=0x0000ffff, Execute/Read, 32-bit
GDT[0x08]=Code segment, base=0x000f0000, limit=0x0000ffff, Execute/Read, 16-bit
GDT[0x09]=Data segment, base=0x000f0000, limit=0x0000ffff, Read/Write
GDT[0x0a]=Data segment, base=0xfe000000, limit=0x007fffff, Read/Write, Accessed
GDT[0x0b]=32-Bit TSS (Busy) at 0x805fff80, length 0x0207f
GDT[0x0c]=Data segment, base=0x00000000, limit=0x00000fff, Read/Write, Accessed

There we see that applications do indeed have the flat address space starting at 0, with all the problems that could cause and solve.
Nothing better than guesstimates on the other selectors though.

Here is what appears to be the common page mapping:
Code:
From application point of view only, not here in kernel:
0x00000000-0x00000fff -> 0x00cc9000-0x00cc9fff

The rest is the same, in both application and kernel points of view.
No idea what these mean. Kernel allocating more memory to itself?
0x80000000-0x805fefff -> 0x00000000-0x005fefff
0x805ff000-0x80601fff -> 0x00543000-0x00545fff
0x80602000-0x807fffff -> 0x00602000-0x007fffff
0x80800000-0x8081ffff -> 0x00548000-0x00567fff
0x80820000-0x80821fff -> 0x00546000-0x00547fff
0x80822000-0x80861fff -> 0x007f0000-0x0082ffff
0x80862000-0x80863fff -> 0x00544000-0x00545fff
0x80864000-0x808a3fff -> 0x00864000-0x008a3fff
0x808a4000-0x808a4fff -> 0x00cc6000-0x00cc6fff
0x808a5000-0x808abfff -> 0x008a5000-0x008abfff
0x808ac000-0x808acfff -> 0x00cc7000-0x00cc7fff
0x808ad000-0x808adfff -> 0x00cc9000-0x00cc9fff
0x808b0000-0x808b2fff -> 0x008b0000-0x008b2fff
0x808b3000-0x808bafff -> 0x00830000-0x00837fff
0x808bb000-0x808c1fff -> 0x007e9000-0x007effff
0x808c2000-0x8090efff -> 0x00838000-0x00884fff
0x8090f000-0x80a16fff -> 0x00888000-0x0098ffff
0x80a17000-0x80a17fff -> 0x00885000-0x00885fff
0x80a18000-0x80a1afff -> 0x00990000-0x00992fff
0x80a1b000-0x80a1dfff -> 0x009b9000-0x009bbfff
0x80a1e000-0x80a1efff -> 0x009a3000-0x009a3fff
0x80a1f000-0x80a21fff -> 0x009a0000-0x009a2fff
0x80a22000-0x80a25fff -> 0x00a00000-0x00a03fff
0x80a26000-0x80a28fff -> 0x009ce000-0x009d0fff
0x80a29000-0x80a2bfff -> 0x009dd000-0x009dffff
0x80a2c000-0x80a2dfff -> 0x00c37000-0x00c38fff
0x80a2e000-0x80a2efff -> 0x00c7d000-0x00c7dfff
0x80a2f000-0x80a2ffff -> 0x00c81000-0x00c81fff
0x80a30000-0x80a30fff -> 0x00c84000-0x00c84fff
0x80a31000-0x80a31fff -> 0x00c87000-0x00c87fff
0x80a32000-0x80a32fff -> 0x00c82000-0x00c82fff
0x80a33000-0x80a33fff -> 0x00c86000-0x00c86fff
0x80a34000-0x80a34fff -> 0x00cb1000-0x00cb1fff
0x80a35000-0x80a61fff -> 0x00c39000-0x00c65fff
0x80a62000-0x80a6bfff -> 0x00993000-0x0099cfff
0x80a6c000-0x80a7ffff -> 0x00c66000-0x00c79fff
0x80a80000-0x80a80fff -> 0x00c7c000-0x00c7cfff
0x80a81000-0x80ac8fff -> 0x00a10000-0x00a57fff
0x80ac9000-0x80ac9fff -> 0x00a09000-0x00a09fff
0x80aca000-0x80c29fff -> 0x00ad0000-0x00c2ffff
0x80c2a000-0x80c2bfff -> 0x00c7a000-0x00c7bfff
0x80c2c000-0x80c2cfff -> 0x00c89000-0x00c89fff
0x80c2d000-0x80c2efff -> 0x00caf000-0x00cb0fff
0x80c2f000-0x80c31fff -> 0x00cd8000-0x00cdafff
0x80c36000-0x80c45fff -> 0x00c98000-0x00ca7fff
0x80c46000-0x80c47fff -> 0x00c8e000-0x00c8ffff
0x80c48000-0x80c49fff -> 0x00ca8000-0x00ca9fff
0x80c4a000-0xfdbfffff -> 0x00c4a000-0x7dbfffff
0xfdc00000-0xfdc00fff -> 0x00ccf000-0x00ccffff
0xfde00000-0xfde00fff -> 0x00000000-0x00000fff
0xfde01000-0xfdff6fff -> 0x0033e000-0x00533fff
0xfdff7000-0xfdff7fff -> 0x00cce000-0x00ccefff
0xfdff8000-0xfdff8fff -> 0x007e8000-0x007e8fff
0xfdff9000-0xfdffffff -> 0x00536000-0x0053cfff
0xfe000000-0xfe27ffff -> 0x00568000-0x007e7fff
0xfe400000-0xffffffff -> 0x7e400000-0x7fffffff


Oh, and Bochs IO debugger ports access causes a crash of application doing it, so getting a debugger breakpoint at a defined address is kind of tricky.
Post 09 Nov 2010, 18:47
View user's profile Send private message Visit poster's website Reply with quote
Tolle



Joined: 21 Jan 2004
Posts: 71
Tolle 15 Nov 2010, 22:40
If i recall correctly...
1) Nope, no such concept.
2) Nope, only things applications can't do is the stuff in the PROTECTION app. (Things like using OUT etc...)

As to the memory mappings, ask Ville Very Happy
Post 15 Nov 2010, 22:40
View user's profile Send private message Visit poster's website Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 308
Ville 14 Dec 2010, 14:52
M64-095 checks that pages are present for pointers and memory areas. NULL pointer handling depends on the system call.
See the system call list at: http://www.menuetos.net/syscall.txt
Post 14 Dec 2010, 14:52
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Main index Download Documentation Examples Message board

Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.