flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
Niels 26 Jul 2007, 12:36
A short reaction from memory:
- Despite 'long mode' can't work with segments like this is done in 32-bit Pmode, 'long mode' still needs 1 segment, so to speak 'all-in-one-segment'. Pages is the way to 'segment'... - You refer to the hardware-taskmanagement-system, in 32-bit you are free to use or not use it, in 'long mode' you can't use it but this 'long mode' does need at least one task to work with and the actual 'task-switches' are manually done not by hardware-taskmanagement-system. Conclusion: You have to provide/load only one TSS (for 64-bit). - The memory is first considered(and accessed) to be 'all pages', within these pages you make GDT and optionally a LDT, the GDT also contains e.g. the IDT. Pages takeover most part of the 'security-system' like this normally is done with segments, so, a page is ring1, ring2 or ring3. Niels ps. I hope I remembered right... ![]() |
|||
![]() |
|
Niels 26 Jul 2007, 13:08
Gizmo,
I'm not an anti-AMD-person, but the manuals from Intel are considered 'more' than those from AMD. Both is best ![]() Here you can find some info about TSS: http://www.embedded.com/showArticle.jhtml?articleID=55301875 Niels ps. If you don't want to download the whole-shabang, it's the System Programming Guide, part 3A and 3B. ps2. The hard part of ASM is considered to be 'a gathering of simplicity' called a complex. |
|||
![]() |
|
Gizmo 26 Jul 2007, 14:23
so basically if I was to choose software task switching:
I would have a page directory (with its contained tables of course) per process (defined here as containing all threads belonging to an application). Inside of that I would have to store a stack for each thread, and that process's data (shared between all threads in that process). When I switch to a thread, I load that process's page directory, then pop the registers I pushed for that thread when I put it to sleep. To minimize swapping page directories, I should run all threads belonging to that one process before moving on to another process. When a thread is being switched out, I push all of the registers onto its stack and load the next threads registers form its stack. If the next thread belongs to a different process than the last thread, I swap page directories. I use only one tss for my entire operating system along with just one code and one data segment mapped from 0 to 4gb set to ring level 3. I map shared memory (shared between kernel and tasks) in the upper (3gb+) pages so user mode task can call the kernel. Does this sound about right? |
|||
![]() |
|
vid 26 Jul 2007, 14:37
Quote: Each task can have its own descriptor table (ldt). yes, but this isn't usually the case. For example windows doesn't use LDT at all, don't know about linux. Quote: I read in an amd manual that long mode does not support segments, should I just use a flat model so when I recode for long mode I won't have a mess on my hands? (how does gdt, ldt, page tales, tss, etc work there) In long mode, base address of CS, SS, DS and ES always have base 0, and limit FFFFFFFFFFFFFFFF. But FS and GS still can be set to any base (not sure about limit). I don't know if rights apply or not in 64bit mode. Besides that, it's like in 32bit mode. You must have GDT and all stuff, but these particular fields are simply ignored. Task switching in 64bit mode (at least on Intel processors) doesn't work, but you still have to have task register set to selector of task segment. Only difference is that task switch (retf/iret/jmp far to task segment/gate) will cause exception, and system has to process it by emulating it's functionality. Quote: You can store the page table for each task in that task's ldt if you desire a virtual address space per task? Quote: How exactly do you handle task and task switching? You must create task segment for each segment. This segment contains info about values of other system registers. Then, you must simply far jump (or far return, or iret) to this segment (offset doesn't matter, i think). When you do this, values of system registers are loaded from task segment. Task segment can be only in GDT. If you need to have selector in IDT or LDT (because of access rights), you create "task gate descriptor" in IDT/LDT, which just references task segment descriptor in GDT. Quote: How do you take back control from a task- both cooperating tasks and those who do not cooperate (such as a hung task)? You must hook on timer somehow, and when you decide (in timer handler) to switch to another task, you simply do it same way like you would do from within the task. Note that timer handler must run within currently running task for this, it can't have it's own task. |
|||
![]() |
|
Niels 26 Jul 2007, 14:55
Gizmo,
I see you want CPU.Application.Thread; Gizmo wrote: Inside of that I would have to store a stack for each thread Not neccesarily, if you like you could... Gizmo wrote: When I switch to a thread, I load that process's page directory Depends on your 'built-construction'. Gizmo wrote: To minimize swapping page directories "Swapping pages" will be more the case..., if a call to memory is made to a page not in memory your get a page-error, then you swap the old.page>to disk new.page>to mem. Gizmo wrote: I use only one tss for my entire operating system along with just one code and one data segment mapped from 0 to 4gb set to ring level 3. You could..., although you do need level0... Gizmo wrote: I map shared memory (shared between kernel and tasks) in the upper (3gb+) pages so user mode task can call the kernel. I do understand the 4gb OS-stackdown approach but as a motive for "user mode task can call the kernel" is unclear to me... this considering a gate will be used... Niels |
|||
![]() |
|
Niels 26 Jul 2007, 15:21
vid wrote: I don't know if rights apply or not in 64bit mode. Code segment-rights also apply 'normally', except for base and limit... But pages also have the system/user/data etc bits... Niels |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.