Hi Adam,
First of all my contributions to a document list of memory management topics
themselves:
Since we probably all agree that x86/x64 are the primary targets, we should
really study the application notes and manuals from the processor makers:
- Paging:
- Intel, "TLBs, Paging-Structure Caches, and Their Invalidation",
Application Note, April 2007
- Memory Organization
- Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 1: Basic Architecture", specifically Chapter 3.3 and following
- Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide, Part 1", Chapters 2.4, 3, 4,
8.4/8.5/8.8, 10
And probably the most important:
- ISO/IEC 23271, "Common Language Infrastructure (CLI) Partition I: Concepts
and Architecture",Second Edition from 2006-10-01, specifically chapter 12.6
Next my wishlist for a TODO-List - working this list in order is preferred,
but not mandatory. I've most likely missed some things, because this is just
my PoV.
- We need a roadmap
- We really need to define a system architecture, how we want things to work
in the end. I suppose this should be in a Wiki, where we can all edit and
track changes.
- We need to define an operation model for x86/x64 specifically - regarding
memory model, protection boundaries etc.
- I believe we need to implement really good boot and processor init
sequences first
- Since it is 2008, we should be friendly regarding Virtualization
Extensions - we should be able to run as guests under a Virtual Machine
Monitor on supporting processors
- We really need to get Interrupts working, all other approaches just
consume time without any benefits
- Some of this is already done, but needs to be documented - sequence
diagrams would be nice for others to jump in later on - ideally hyperlinked
to respective source files
- We need to define a programming model for the core operating system
- We really need to obey object oriented principles, such as seperation of
concerns, testability etc.
- We need to define the APIs of core OS services so we can use them even if
they're just mocks at first
- Actually for testability I'd prefer having mock implementations of all
of these services
- We need to define and support a runtime execution engine
- Without availability of proper runtime metadata we're always going to
beat around the bush and not really get to a point or even use the benefits
we could gain by the runtime
(I'll provide a lot in this regard, but I do need support after I've
implemented as much as I need there.)
- We need to support exceptions so that we can stop writing a C-style
operating system in a more advanced language
- Since we're working on our own native code compiler(s) we need a lot more
tests there. I don't think we'll every be happy with any compiler if we
continue the way we're running now.
- Ideally we'd try to get 100% code coverage here
- I'd like us to work closely with Ensemble on this. After all we all have
limited resources. I think we should focus on a common kernel with
Ensemble/SharpOS being distributions of it.
- For the JIT we need some people who work on emitting native x86 code from
the intermediate representation. I REALLY NEED SUPPORT HERE GUYS.
To get to something, we need to do all of the above. It doesn't make sense
to work on anything more advanced or higher up in layers, unless the
basement's been built.
I'm going to eat my lunch. I'll be in IRC later on, but I'm still busy
writing my thesis paper - only about half way through there - and my
deadline is aproaching closer.
Mike
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
