Eigenes OS?

[PHPnerd]

Did you try to get the assembly code generated by GCC?

Are you sure that the currentDir->physical is physical?
And are the new page tables, and page directories you made, page aligned?

// PHPnerd

[Erhard Henkes]

Did you try to get the assembly code generated by GCC?

Yes, I was interested in the consequence of putting (or not putting) registers into the clobber list. Here is the result:

clobbering ebx and edx ==> Page Fault:

asm volatile("         \
      cli;                 \
      mov %0, %%ecx;       \
      mov %1, %%esp;       \
      mov %2, %%ebp;       \
      mov %3, %%cr3;       \
      mov $0x12345, %%eax; \
      sti;                 \
      jmp %%ecx;           "
      : : "r"(eip), "r"(esp), "r"(ebp), "r"(current_directory->physicalAddr) 
      : "ebx","edx" );

objdump task.o -D > task.txt

35f:	fa                   	cli    
 360:	89 f1                	mov    %esi,%ecx
 362:	89 fc                	mov    %edi,%esp
 364:	89 cd                	mov    %ecx,%ebp
 366:	0f 22 d8             	mov    %eax,%cr3
 369:	b8 45 23 01 00       	mov    $0x12345,%eax
 36e:	fb                   	sti    
 36f:	ff e1                	jmp    *%ecx

The first thing you see is why we cannot clobber edi and esi, too.

Empty clobber list ==> GPF

351:	fa                   	cli    
 352:	89 d9                	mov    %ebx,%ecx
 354:	89 f4                	mov    %esi,%esp
 356:	89 fd                	mov    %edi,%ebp
 358:	0f 22 d8             	mov    %eax,%cr3
 35b:	b8 45 23 01 00       	mov    $0x12345,%eax
 360:	fb                   	sti    
 361:	ff e1                	jmp    *%ecx

clobbering ebx ==> GPF

35f:	fa                   	cli    
 360:	89 f1                	mov    %esi,%ecx
 362:	89 fc                	mov    %edi,%esp
 364:	89 d5                	mov    %edx,%ebp
 366:	0f 22 d8             	mov    %eax,%cr3
 369:	b8 45 23 01 00       	mov    $0x12345,%eax
 36e:	fb                   	sti    
 36f:	ff e1                	jmp    *%ecx

clobbering edx ==> GPF

351:	fa                   	cli    
 352:	89 d9                	mov    %ebx,%ecx
 354:	89 f4                	mov    %esi,%esp
 356:	89 fd                	mov    %edi,%ebp
 358:	0f 22 d8             	mov    %eax,%cr3
 35b:	b8 45 23 01 00       	mov    $0x12345,%eax
 360:	fb                   	sti    
 361:	ff e1                	jmp    *%ecx

[Erhard Henkes]

..

[Erhard Henkes]

Ich habe nun noch eine Variable für die physikalische Adresse in fork() eingefügt, um diese dort auszugeben:

// Create a new process.
    ULONG phys;
    task_t* new_task = (task_t*) k_malloc( sizeof(task_t),0,&phys );
    printformat("placement_address after creating a new process: %x phys: %x\n", placement_address, phys);

VFS & RAM Disk install
placement_address after ram disk install: 40200000h
ramdisk_start: 40081000h file_data_start: 0000A2E0h file_data_end: 0000B652h
After set_kernel_stack ==> tss_entry.esp0: 40101800h

> IRQ 127 <<<
Hello, user world!
...
placement_address after creating a new process: 40200000h phys: 0041CBE8h
fork() returned: 00000002h and getpid() returned: 00000001h
placement_address after creating a new process: 40200000h phys: 0041CC18h
fork() returned: 00000003h and getpid() returned: 00000001h
placement_address after creating a new process: 40200000h phys: 0041CC48h
fork() returned: 00000004h and getpid() returned: 00000001h
SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000018h, DS: 00000020h
task_switch before asm: eip: 0000D4CFh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->ph
ys: 0041E000h
Page Fault (page not present) at 0040FCC0h - EIP: 0040FCC0h

[PHPnerd]

I will explain the kmalloc for you.

size = size (doh)
align = page aligned, this makes your address page aligned, usable for paging structures and TSS (and others)
phys = get the physical address. You can put NULL in it, or a pointer to a variable. Like:

uint32_t phys = 0;
uint32_t ptr = kmallocAP(0x100, 1, &phys);
printf("Phys: 0x%X, Virt: 0x%X\n",phys,ptr);

Getting physical address and doing nothing with it won't solve your problem.
The task doesn't have to be page aligned, since it is Software Multitasking, and you made it your own (nah, JamesM did :P)

The kmalloc code is 100% fine. (I used it my own some time ago)

// PHPnerd

[Erhard Henkes]

Yes, the k_malloc(...) of James Molloy (I have his written permission to use his source code as a base for own experiments in an OS tutorial, if I like, but I am not sure, if his code is really robust enough) is usable and is not the problem (Other people think, JM has put too much into paging.h/paging.c, because phys./virt. memory management should be separated clearly. This can be done easily.).

OK, alignment is not important. I was not quite sure about it.

Currently, I do not understand the difference in the result of EIP between cases 1) and 3). In 3) I just save the physical address at 0x01 or a variable phys. The reason must be in the way of saving details of the tasks. Hence, the clobbering can influence the deficient process.

I think, I should go back to the test code where the task switch really works and analyze the effects by looking at all the details again. I just did and the page fault came, too. Thus, the failure has another reason. That's good.
As soon as I have analyzed it, I will come back.

@PHPnerd: Thanks for staying with me in times of confusion.

I use the following "stable version":
ckernel.c (like main.c):

UCHAR c=0;
	while(TRUE)
	{

	  if( k_checkKQ_and_print_char() )
	  {
	    ++c;

	    if(c>5)
	    {
	      c=0;
	      settextcolor(4,0);
	      printformat("\nT: %x H: %x WRITE: %i Read: %i ", pODA->pTailKQ, pODA->pHeadKQ, pODA->KQ_count_write, pODA->KQ_count_read);
          printformat("*T: %c %i *H: %c %i\n", *(pODA->pTailKQ),*(pODA->pTailKQ),*(pODA->pHeadKQ),*(pODA->pHeadKQ));
          settextcolor(2,0);

          task_switch(); settextcolor(getpid(),0);
	    }
	  }
	}

kjsdfhsdkjksdjfhksdjfhsdkjfhksdjfhksdjfhsdkjfhsdkjfhksdjfhkjsdfhksjdhfß
T: 0000D80Fh H: 0000D80Fh WRITE: 66 Read: 66 *T: d 100 *H: d 100rnel_stack: 4010
task_switch before asm: eip: 0000D303h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->ph
ys: 00426000hk install
placement_address after ram disk install: 40200000h
ramdisk_start: 40081000h file_data_start: 0000A2C0h file_data_end: 0000B632h
After set_kernel_stack ==> tss_entry.esp0: 40101800h

> IRQ 127 <<<
Hello, user world!
Found file dev
(directory)
Found file f1
contents: "PrettyOS: My filename is test1.txt!"
Found file f2
contents: "PrettyOS: My filename is test2.txt!"
Found file f3
contents: "PrettyOS: My filename is test3.txt!"
placement_address after creating a new process: 40200000h phys: 0041CBE8h
fork() returned: 00000002h and getpid() returned: 00000001h
placement_address after creating a new process: 40200000h phys: 0041CC18h
fork() returned: 00000003h and getpid() returned: 00000001h
placement_address after creating a new process: 40200000h phys: 0041CC48h
fork() returned: 00000004h and getpid() returned: 00000001h
SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000018h, DS: 00000020h

While entering keystrokes, the task is switched after every sixth keystroke.
The logs of 'task_switch before asm:' with the original and 3 forked tasks are:

task_switch before asm: eip: 0000D4AFh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 0041E000h //PID 2

task_switch before asm: eip: 0000D4AFh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00422000h //PID 3

task_switch before asm: eip: 0000D4AFh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00426000h //PID 4

task_switch before asm: eip: 0000D303h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00001000h //PID 1

task_switch before asm: eip: 0000D303h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 0041E000h //PID 2

task_switch before asm: eip: 0000D303h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00422000h //PID 3

task_switch before asm: eip: 0000D303h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00426000h //PID 4

task_switch before asm: eip: 0000D303h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00001000h //PID 1 - the same as line 4

ff.

These are the data of the forked tasks:

phys: 0041CBE8h
fork() returned: 00000002h

phys: 0041CC18h
fork() returned: 00000003h

phys: 0041CC48h
fork() returned: 00000004h

SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000018h, DS: 00000020h

The task switch runs "unclobbered". Now it comes:

If I clobber ebx and edx (see above), then I get a PF:

task_switch before asm: eip: 0000D4AFh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 0041E000h
Page Fault (page not present) at 0040FCA0h - EIP: 0040FCA0h

If I shift the task switch to timer handler, then I get an "Absturz":

task_switch before asm: eip: 0000D303h esp: 0018FE74h ebp: 0018FE8Ch cur_dir->phys: 00001000h
...
task_switch before asm: eip: 0000D303h esp: 0018FE74h ebp: 0018FE8Ch cur_dir->phys: 00001000h
...
task_switch before asm: eip: 0000D303h esp: 0018FF70h ebp: 0018FF88h cur_dir->phys: 00001000h
...
task_switch before asm: eip: 0000D303h esp: 0018FE74h ebp: 0018FE8Ch cur_dir->phys: 00001000h
...
task_switch before asm: eip: 0000D4AFh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 0041E000h
...
placement_address after creating a new process: 40200000h phys: 0041CC18h
fork() returned: 00000003h and getpid() returned: 00000002h
placement_address after creating a new process: 40200000h phys: 0041CC48h
fork() returned: 00000004h and getpid() returned: 00000002h
SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000008h, DS: 00000010h

==> Absturz (no exception, no reboot, just nothing besides blinking cursor)

I think, this shows that JM's function task_switch() does not correctly work. Caring only for eip, esp, ebp seems to be not enough! Right?

[Erhard Henkes]

@PHPnerd: How do you switch tasks? Are you willing to show your new kmalloc?

[PHPnerd]

I do not switch tasks yet. I will explain main for it later here

And, I am using DogLea Algorithm with my own code.
So:
Headers and footers
List containing free blocks, sorted by size

Like the JamesM one, but than all my own code (like it more :P)

Maybe look deeper in Intel Manuals of the source of other OSes to get idea's

// PHPnerd

[PHPnerd]

With the multitasker:

Try to save more registers, since you don't have a TSS.

Save:
EFLAGS <--
Segment registers: CS, DS, ES, FS, GS
Possible save some general registers (can be done later)

Maybe the EFLAGS will save the problem.
Oh, and, did you do a end-of-interrupt before task switch when using switching in PIT? May be important.

// PHPnerd

[Erhard Henkes]

Save: FLAGS/EFLAGS

How can I do that? Is there a name for it in assembler? But I have read that you need not save them for task switch.

I think the problem is with eip. I have logged it just before the asm code and directly after the task_switch():

task_switch before asm: eip: 0000D54Fh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 0041E000h PID: 2
after task_switch: eip: 00008B11h esp: 0018FFE0h ebp: 0018FFF0h cur_dir->phys: 0041E000h PID: 2

D54Fh vs. 8B11h ? But the task switch runs in this special case:

///TEST
    printformat("task_switch before asm: eip: %x esp: %x ebp: %x cur_dir->phys: %x PID: %d\n",eip,esp,ebp,current_directory->physicalAddr, getpid());
    ///TEST

    asm volatile("       \
    cli;                 \
    mov %%ebx, %%esp;    \
    mov %%edx, %%ebp;    \
    mov %%eax, %%cr3;    \
    mov $0x12345, %%eax; \
    sti;                 \
    jmp *%%ecx;          "
               : : "c"(eip), "b"(esp), "d"(ebp), "a"(current_directory->physicalAddr) );

... changed to named registers.

while(TRUE)
	{

	  if( k_checkKQ_and_print_char() )
	  {
	    ++c;

	    if(c>5)
	    {
	      c=0;
	      settextcolor(4,0);
	      printformat("\nT: %x H: %x WRITE: %i Read: %i ", pODA->pTailKQ, pODA->pHeadKQ, pODA->KQ_count_write, pODA->KQ_count_read);
          printformat("*T: %c %i *H: %c %i\n", *(pODA->pTailKQ),*(pODA->pTailKQ),*(pODA->pHeadKQ),*(pODA->pHeadKQ));
          settextcolor(2,0);

          task_switch(); 
          ///TEST
          printformat("after task_switch: eip: %x esp: %x ebp: %x cur_dir->phys: %x PID: %d\n",read_eip(),fetchESP(),fetchEBP(),current_directory->physicalAddr, getpid());
          ///TEST
          settextcolor(getpid(),0);
	    }
	  }
	}

[PHPnerd]

Does it work now?

// PHP

[Erhard Henkes]

Only in the while loop at the above shown location. I think that the failure is at another place, perhaps concerning kernel_stack of the task. I come back to that.

EDIT: One failure was in fork(): now new_task->kernel_stack instead of current_task->...

I log the processes with its data, the first task looks strange:

HEAP start: 40081000h end: 40100000h max: 4FFFF000h kernel mode: 0 read-only: 0
hole 40081000h hole-size: 0007F000h after create_heap: placement_address: 0030C020h  allocated frames: 795

VFS & RAM Disk install
placement_address after ram disk install: 40200000h ramdisk_start: 40081000h file_data_start: 0000A200h file_data_end: 0000B572h

tasking install
move stack, ESP: 0018FFD0h After init first task, p_a: 40200000h After k_malloc kernel_stack, p_a: 40200000h k_stack: 40101000h 

placement_address after creating a new process: 40200000h phys: 0041C814h
fork(): 00000002h and getpid(): 00000001h
placement_address after creating a new process: 40200000h phys: 0041C844h
fork(): 00000003h and getpid(): 00000001h
placement_address after creating a new process: 40200000h phys: 0041C874h
fork(): 00000004h and getpid(): 00000001h
t->id: 1, esp: 00000000h, eip: 00000000h k_stack: 40101000h, p_dir: 00000000h next: 40101814h
t->id: 2, esp: 0018FFD8h, eip: 0000D3C9h k_stack: 40105000h, p_dir: 40102000h next: 40101844h
t->id: 3, esp: 0018FFD8h, eip: 0000D3C9h k_stack: 40109000h, p_dir: 40106000h next: 40101874h
t->id: 4, esp: 0018FFD8h, eip: 0000D3C9h k_stack: 4010D000h, p_dir: 4010A000h next: 00000000h

SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000008h, DS: 00000010h

after typing keys and taskswitching by that:

kjdfghjkkhjkhkjkhkjhkkjh
task_switch before asm: eip: 0000D216h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00001000h PID: 1
after task_switch in ckernel.c: eip: 000089C7h esp: 0018FFE0h ebp: 0018FFF0h cur_dir->phys: 00001000h PID: 1


Improved Sourcecode: http://www.henkessoft.de/OS_Dev/Downloads/40.zip
I think it is not yet ready for the timer_handler, but I am on the right track now.

[PHPnerd]

Good!~

I almost finished my kmalloc. Working on Shrink now. Next is krealloc, but I may skip that one for now.

I will continue ordering my OS, and then the MultiTasker.

// PHP

[Erhard Henkes]

To my mind, the crucial point is that the source code stays transparent.

There was a create_heap(...) inside of paging_install(). I have taken it out, because the heap is more complicated to visualize by printformat(...), and process' stacks were created in the heap!

Now there is a new exception, if you put the task_switch() to practice inside the time_handler (k_m_nonheap means "pushing" placement_address, no heap):

k_m_nonheap k_m_nonheap k_m_nonheap k_m_nonheap k_m_nonheap
p_a: 0040D000h allocated frames: 1053
frames: 00400000h NFRAMES: 524288
k_dir->phys: 00406000h
p_a: 0040D000h allocated frames: 1053

k_m_nonheap

tasking install
stack, ESP: 0018FFD0h k_m_nonheap Init first task, p_a: 00410020h cur_task: 00410004h k_m_nonheap After k_malloc k_stack, p_a: 00411800h k_stack: 00411000h

k_m_nonheap k_m_nonheap placement_address after creating a new process: 00414020h phys: 00414004h
k_m_nonheap fork(): 00000002h and getpid(): 00000001h
k_m_nonheap k_m_nonheap placement_address after creating a new process: 00418020h phys: 00418004h
k_m_nonheap fork(): 00000003h and getpid(): 00000001h
t->id: 1, esp: 00000000h, eip: 00000000h k_stack: 00411000h, p_dir: 0040E000h next: 00414004h
t->id: 2, esp: 0018FFD8h, eip: 0000D379h k_stack: 00415000h, p_dir: 00412000h next: 00418004h
t->id: 3, esp: 0018FFD8h, eip: 0000D379h k_stack: 00419000h, p_dir: 00416000h next: 00000000h

p_a: 00419800h

SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000008h, DS: 00000010h

task_switch before asm: cur_task->p_dir: 00412000h task_switch before asm:
eip: 0000D379h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00413000h PID: 2
Invalid Opcode >>> Exception. System Halted! <<<

Wie kann man den "Invalid Opcode" besser auswerten? z.B. Invalid Opcode ... at address ...? Ich habe mir z.B. r->eip angeschaut. Das passt einfach nicht zu dem in task_t. Verflixt!

Tippt man vor dem Timer Handler schnell noch ein paar task switches, dann findet man:

klxdfgjkldfgjdfkgjkldfgjkldfgjkldfgjkldfjglkdfgjlkdfgjkldfjgkldfjglk
task_switch before asm: cur_task->p_dir: 0040E000h task_switch before asm: eip: 0000D1BBh esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 0040F000h PID: 10h ebp: 0018FFF0h cur
Invalid Opcode >>> Exception. System Halted! <<<

This is the test code in ckernel.c (main.c):

int main()
{
//...

    settextcolor(2,0); printformat("paging install\n"); settextcolor(15,0);
    paging_install();

    settextcolor(2,0); printformat("tasking install\n"); settextcolor(15,0);
    tasking_install(); settextcolor(15,0);
    int retValFork1 = fork(); int retValGetPid1 = getpid();
    printformat("fork(): %x and getpid(): %x\n", retValFork1, retValGetPid1);
    int retValFork2 = fork(); int retValGetPid2 = getpid();
    printformat("fork(): %x and getpid(): %x\n", retValFork2, retValGetPid2);
    int retValFork3 = fork(); int retValGetPid3 = getpid();
    printformat("fork(): %x and getpid(): %x\n", retValFork3, retValGetPid3);

    task_t* t = current_task;
    while(TRUE) {
        while(t->next) {
          printformat("t->id: %d, esp: %x, eip: %x k_stack: %x, p_dir: %x next: %x\n", t->id, t->esp, t->eip, t->kernel_stack, t->page_directory, t->next);
          t = t->next;
        }
        printformat("t->id: %d, esp: %x, eip: %x k_stack: %x, p_dir: %x next: %x\n", t->id, t->esp, t->eip, t->kernel_stack, t->page_directory, t->next);
        break;
    }
    printformat("p_a: %x \n", placement_address);
    printformat("SS: %x, ESP: %x, EBP: %x, CS: %x, DS: %x\n", fetchSS(),fetchESP(),fetchEBP(),fetchCS(),fetchDS());
    settextcolor(2,0);
    UCHAR c=0;
	while(TRUE) {
	  if( k_checkKQ_and_print_char() ) {
	    ++c;
	    if(c>5) {
	      c=0;
	      task_switch();
              printformat("after task_switch in ckernel.c: eip: %x esp: %x ebp: %x cur_dir->phys: %x PID: %d\n",read_eip(),fetchESP(),fetchEBP(),current_directory->physicalAddr, getpid());
              settextcolor(getpid(),0);
	    }
	  }
	}
	return 0;
}

EDIT:
I have printed now the infos from the struct reg by evaluating the exception in the IRQ/fault handler:

placement_address: 00419800h
SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000008h, DS: 00000010h
task_switch before asm: cur_task->p_dir: 00412000h eip: 0000D4D9h esp: 0018FFD8h ebp: 0018FFF0h cur_dir->phys: 00413000h PID: 2

Invalid Opcode >>> Exception. System Halted! <<<
err_code: 00000000h address(eip): 0000024Bh edi: 00000020h esi: 00000000h ebp: 00000008h esp: 0018FFE8h eax: 000000D7h ebx: 00000000h ecx: 00012345h edx: 0000D7F0h cs: 8 ds: 16 es: 16 fs: 16 gs 16 ss 2097144 int_no 6 eflags 00010202h useresp 00000000h

These should be the data direct after the asm-code in task switch.
address: 24Bh (eip) cannot be correct, if we enter with D4D9h.
The ss 2097144 = 1FFFF8h looks "kaput". It should be 16 (10h).
eflags: 10000001000000010b = 10202h

The whole task_management has to be looked thru.
JM's code in this area is not robust, it was only for short demos.

[Erhard Henkes]

Ich habe jetzt mal pushf und popf eingebaut, um die flags zu sichern:

asm volatile("       \
    cli;                 \
    pushf;               \
    mov %%ebx, %%esp;    \
    mov %%edx, %%ebp;    \
    mov %%eax, %%cr3;    \
    mov $0x12345, %%eax; \
    popf;                \
    sti;                 \
    jmp *%%ecx;          "
               : : "c"(eip), "b"(esp), "d"(ebp), "a"(current_directory->physicalAddr) );

Ergebnis via task_switch mittels timer:

p_a: 00419800h
SS: 00000010h, ESP: 0018FFE0h, EBP: 0018FFF0h, CS: 00000008h, DS: 00000010h
task_switch before asm: cur_task->p_dir: 00412000h eip: 0000D519h esp: 0018FFD8
h ebp: 0018FFF0h cur_dir->phys: 00413000h PID: 2 ss: 16
err_code: 00000000h address(eip): 0000D40Bh
edi: 0018FFF0h esi: 0018FFD8h ebp: 0018FFF0h esp: 0018FFC8h eax: 00012345h ebx:
0018FFD8h ecx: 0000D519h edx: 0018FFF0h
cs: 8 ds: 16 es: 16 fs: 16 gs 16 ss 55376
int_no 1 eflags 00007FC6h useresp 00418000h
Debug >>> Exception. System Halted! <<<

Jetzt haben wir eine DEBUG Exception.

Übrigens: Wenn ich pushfd / popfd verwenden will, macht mein oldtimer gcc (verwendet wegen aout Format von NASM um den Asemblercode einzubinden) das nicht mit:

c:/djgpp/tmp/cc5s5oYe.s: Assembler messages:
c:/djgpp/tmp/cc5s5oYe.s:237: Error: no such instruction: pushfd' c:/djgpp/tmp/cc5s5oYe.s:237: Error: no such instruction:popfd'

kann also nur die FLAGS nicht die EFLAGS sichern.

EDIT: Ich denke inzwischen, dass JM's Sourcecode im Bereich (multi)tasking für PrettyOS einfach unbrauchbar ist.

Auf jeden Fall hat mir die Beschäftigung mit den Themen viel gebracht, bin nun auch oft genug gegen den Baum gefahren, um zu wissen, was etwas taugt und was einem bei Problemen nur noch den Rest gibt.

Daher mache ich nun einen kompletten "roll-back" und setze am Ende des Tutorials an. !!!Schnitt!!!

[schnitt]

Wird es nicht mehr weiter entwickelt oder was?????

[Erhard Henkes]

Roll-back starts now:

Tutorial: http://www.henkessoft.de/OS_Dev/OS_Dev1.htm
Source Code: ..

Zunächst mal einige Fragen an euch zu den Tools (nasm/gcc/ld):

1. Im Tutorial werden gcc 3.1 und ld 2.13 (im Rahmen von DJGPP, Download-Link von osdever.net empfohlen: http://www.osdever.net/downloads/compilers/DJGPP-Installer-nocpp.exe ) verwendet.
   Einer der Gründe besteht darin, dass wir damit das aout-Format (Linux a.out object file) linken konnten. abc.w konnte dieses Problem, soweit ich es verstanden habe, auch nicht lösen, sodass wir dabei blieben. Mit dem gcc 3.1 kommt man allerdings immer suspekt daher. Ein Fehler könnte ja am Uralt-Compiler liegen.

Mögliche NASM output-Formate sind:
bin, aout, aoutb, coff, elf32, elf, elf64, as86, obj ...

Verwendet man für die NASM outputs COFF bzw. WIN32, dann gibt es folgende nette Meldung:
kernel.asm: ... : error: COFF format does not support non-32-bit relocations
Soweit ich das verstanden habe, hängt dies an unserem eleganten Übergang von 16 Bit nach 32 Bit. Hier erhält man von "Fachleuten" den Rat, GRUB einzusetzen und sich auf den C-Kernel zu konzentrieren. Das widerspricht aber dem Geist des bisherigen Tutorials, das die Dinge bottom-up zeigen will. Ich habe außer diesem aout-Format bisher kein Format gefunden, dass sowohl 16- als auch 32-Bit verarbeitet und von ld zum restlichen C-Code gebunden wird. Gibt es ein modernes Format, das dies kann?

Ich bin nicht sicher, inweiweit dies ein echtes Problem oder nur Ansichtssache ist. GCC 3.1 stammt ja immerhin schon von May 15, 2002. Also so richtig uralt ist er nicht.

Warum wurde z.B. pushfd / popfd im asm-Code nicht akzeptiert? Das kann doch nicht am gcc-Baudatum 2002 liegen, den 386er asm-Set gibt es seit den 80ern.

2. zur AT&T-Syntax: %eax %%eax *%%eax
   wo muss man genau was verwenden?

[+fricky]

Erhard Henkes schrieb:

Auf jeden Fall hat mir die Beschäftigung mit den Themen viel gebracht, bin nun auch oft genug gegen den Baum gefahren, um zu wissen, was etwas taugt und was einem bei Problemen nur noch den Rest gibt.

meiner meinung nach hast du zu viele themen gleichzeitig bearbeitet. das liegt wohl auch daran, dass es keine richtige trennung zwischen den komponenten des 'referenzsystems' von JM gibt (vermutlich ist er ein opfer der verfrickelten x86-technologie geworden, die einem instabile software-konstrukte aufzwingt). dabei kann man virtual memory, multitasking, heaps und exceptions ziemlich unabhängig voneinander betrachten. aber egal, nur nicht aufgeben...

[Erhard Henkes]

Den Mut habe ich keinesfalls verloren, ganz im Gegenteil! Man kann ein solches Tutorial keinesfalls schreiben, wenn man schon 20 verschiedene OS entwickelt hat, weil man sich dann für garnix mehr entscheiden kann und alles nur noch theoretisch/abstrakt sieht, aber auch nicht aus dem Nichts. Inzwischen verstehe ich, warum JM nicht weiter macht.

dabei kann man virtual memory, multitasking, heaps und exceptions ziemlich unabhängig voneinander betrachten

Ja, das stimmt. Es gibt daneben noch weitere Punkte, nämlich die Trennung des physikalischen und virtuellen MM, die Software-Interrupts, die Syscalls und die Ausführung von Programmen. Das VFS und die RAM-Disk gefallen mir gut von JM, wobei sein VFS noch nicht ausgefeilt ist, aber das kann man ja noch machen. Heap-Mechanismus funktioniert auch gut. Vielleicht liefert uns PHPnerd etwas Besseres, aber sein Ansatz klingt für mich gleich zu JM, aber ich bin kein Informatiker.

[Erhard Henkes]

Ich habe mit Teil 2 begonnen und die Themen FIFO circular Key Queue und "lean" key handler verarbeitet, um den Anschluss an das Tutorial zu bekommen.
http://www.henkessoft.de/OS_Dev/OS_Dev2.htm (Tut)
http://www.henkessoft.de/OS_Dev/Downloads/20090501_PrettyOS_101.zip

Was mir wirklich Sorgen macht, ist, dass ich mit DJGPP arbeite, gilt als obsolet. leider haben wir 16-bit im Gepäck. Vielleicht kann man das auf 32-Bit abändern und auf COFF umsteigen.