Intel manuals

[Dario]

Hi,

I'm finally in the phase when I have enough time to start reading Intel's manuals for 64 and IA-32 family processors and do some serious research before I start. I plan to spend next 2-3 months doing only that ( no programming ).
I've finished reading first ~100 pages of VOL1 and I realized that the rest of it goes very detailed about certain subjects like ISA, registers, VM....
My questions are:
1. Are these scripts any good to start with?
2. On which subjects should I pay more attention and which should I skip?

Thank you for your time.

[AJ]

You've made a good start by even bothering to read the manuals.

The simple answer to "what should I read?" is "What are you trying to achieve?". If you want a 64 bit OS with no legacy support, then you don't need to know about v86 mode (yet) or process isolation by segmentation, but you will need to know paging inside-out.

Generally, I would suggest keeping the excitement (sarcasm!) of volumes 2a and 2b until later, just using them as a reference for now. Most stuff in volumes 1, 3A and 3B is pretty essential, but if you find you get to a chapter about something you have no intention of implementing, skip it.

The optimisation reference may be a bit over-specific at the moment - it may be more useful when you are tweaking stuff later.

Others will probably disagree and claim that volumes 2a and 2b are fascinating, but just my two penn'orth.

Cheers,
Adam

[Dario]

You've made a good start by even bothering to read the manuals.

First 100 pages were very interesting...and pretty easy to read since there is some history and overview of the basic arhitecture.

The simple answer to "what should I read?" is "What are you trying to achieve?".

At this point I really don't care much about the legacy support. I just want to make pretty much traditional Unix like system...for my own research and hobby. Later if I get into it really deep, we'll search for new, more complex challenges.

...but you will need to know paging inside-out.

Paging...hmmmm...sounds fun.

Generally, I would suggest keeping the excitement (sarcasm!) of volumes 2a and 2b until later, just using them as a reference for now. Most stuff in volumes 1, 3A and 3B is pretty essential, but if you find you get to a chapter about something you have no intention of implementing, skip it.

Yeah, Vol2 A and B are mega complex. I bow to thee who knows every bit of it.

The optimisation reference may be a bit over-specific at the moment - it may be more useful when you are tweaking stuff later.

Yeah...later...I have time and you guys to help me out with it.

[Dario]

I have a question....currently I'm reading about the task switching and I can't figure out some things.

TSS is a data structure which relies somewhere in memory and holds state of execution enviroment?
Task register (TR), holds segment selector of the current running task which points to TSS block? Wait....isn't that actually a pointer to GDT segment?

Also I found this on wikipedia:
"Although a TSS could be created for each task running on the computer, Linux only creates one TSS for each CPU and uses them for all tasks. Linux only uses the I/O port permission bitmap and inner stack features of the TSS. The other features are only needed for hardware task switches which Linux does not use."

So basically, Linux uses it's own facilities to address task switching process...so that is actually SW task switching?
If so, why?

And how all of this relate to PCB or TCB ( process/thread control block ) which kernel uses to store execution env.?

[jal]

TSS is a data structure which relies somewhere in memory and holds state of execution enviroment?
Task register (TR), holds segment selector of the current running task which points to TSS block? Wait....isn't that actually a pointer to GDT segment?

You must create an entry in the GDT for each segment holding a TSS, then point the TR to the relevant TSS.

So basically, Linux uses it's own facilities to address task switching process...so that is actually SW task switching?
If so, why?

Hardware taskswitching using TSSes is depricated, and for example not available in 64-bit ('long') mode. You need one TSS though, as it contains the kernel stack address. Check the wiki for a description.

And how all of this relate to PCB or TCB ( process/thread control block ) which kernel uses to store execution env.?

That's a Linux specific question, I have no knowledge of that.


JAL

[Dario]

You must create an entry in the GDT for each segment holding a TSS, then point the TR to the relevant TSS.

Ahh...so TSS is just a segment which is also addressed through GDT by TR?

Hardware taskswitching using TSSes is depricated, and for example not available in 64-bit ('long') mode. You need one TSS though, as it contains the kernel stack address. Check the wiki for a description.

Why is taskswitching using TSSes avoided?

[Brendan]

Hi,

Why is taskswitching using TSSes avoided?

See this page of the OSdev wiki....


Cheers,

Brendan

[Dario]

Thanks Brendan

[jal]

Why is taskswitching using TSSes avoided?

Since it is very x86 specific, if you'll ever do a port to another platform, SW task switching is probably the only thing available. That's not to say you can directly port your x86 SW switching to another platform, but at least the basic mechanisms are the same. And even if you don't ever wanna go to a different platform, SW task switching is just much easier to understand and implement (imho), and gives you better control on what to do (e.g. not reloading segment registers).


JAL

[Love4Boobies]

It's also a lot faster, as you don't have to double-check a lot of things.