OSDev.org

Posted: **Thu Oct 04, 2007 3:08 pm**

not a middle man function that then signals the driver.

The entire HAL is a middle man of sorts. It acts like a motherboard driver between the kernel, kernel level drivers, and the hardware.

The HAL's register function would need to update the entry in the IDT with the new address of the routine that is being registered. Because IRQ's and ISR's are stored within the same table, We don't need to change anything else.

I have not thought about shared interrupts though.

This is still a design-in-progress though

I still have not found a nice way of loading the HAL with writing a hardware independent memory manager and file manager.

The problem is that of paging and memory management revolves around the hardware. However, placing hardware dependent code for memory management defies the purpose of the HAL in the first place. However, without proper memory management, we cannot have a file manager load programs at a virtual address, anywhere in memory. Thus, cannot load the HAL. (Unless we load it at a specific physical memory address, which is quite ugly.)

Any suggestions for this problem? :/

Posted: **Fri Oct 05, 2007 6:12 am**

Heh, let me try to remember.

Pseudocode:

Code: Select all

%macro push 1-*
  %rep %0
    %push %1
    %rotate 1
  %endrep
%endmacro

; usage:

push eax, ebx, ebp ; uses the macro
push rax ; doesn't qualify for the macro signature, so left as is.

[/code]

Posted: **Fri Oct 05, 2007 7:54 am**

For no real reason, I spent the last four hours working up a start at a HLL using NASM macros.

You can now:

Code: Select all

push ax, bx, cx
pop ax, bx, cx

and get the same order...

ccall my_method, a, b, c
pcall my_method, a, b, c

cret cc

do
..
credo cc

while cc
..
end

if cc
..
end

if cc
..
else
   if cc
   ..
   else
   ..
   end
end

I tried to get it doing once-only imports and methods automatically, but neither worked so well because of limitations with my understanding of how to put ( and " characters next to macro arguments.

fcall, and your own calling conventions are easy, but the for loop is also left to be written.

Perhaps someone can expand on this?

OSDev.org

Tip: Reducing the repetitive asm code from Bran's tutorial