OSDev.org

..

It can't be done at compile time. The full addresses aren't known to the assembler (the linker could relocate the code), so it can't perform complex arithmetic on then. It is possible to add and subtract constant values, because the linker knows how to do that.

Unless you want to hard-code the ISR_0 address, you will have to do this at run time.

..

@perica:

Even if you compile your sources to binary files, the adresses are OFFSETS relative to the start adress you provide the linker with.

You will have to do some calculating and byte counting to hard code the adresses of the isr's you want to refer to by the idt-entries.

why do you think it is needless to assign idt-entries at run time. I do this due to following: I have a full fledged idt. I have still not implemented all necessary drivers. so for hardware int's i have specified kinda dummy entry. this entry will be replaced by driver isr as soon as driver is initializing. It is a nice method which doesn't cause THAT kernel overhead. Just some small functions, that's all. What's but so bad with this approach?

Perica Senjak wrote: I am Compiling the Code to plain binary, why would it be a problem then? What does the error mean?

i'm afraid you are *not* compiling to plain binary. You are either assembling to plain binary, or compiling to ELF/COFF and *then* linking to plain binary ...

That means you have to fulfill the expectation of the ELF/COFF format for the intermediate object files ...

..

Per the NASM manual:

NASM supports two special tokens in expressions, allowing calculations to involve the current assembly position: the $ and $$ tokens. $ evaluates to the assembly position at the beginning of the line containing the expression; so you can code an infinite loop using JMP $. $$ evaluates to the beginning of the current section; so you can tell how far into the section you are by using ($-$$).

This means you would be taking (ISR_0 - (StartOfCurrentSection)) shifted by 16.

One of the tricks to getting your boot-sector to be 512, is to add the line:
resb 510-($-$$)
$ is the current line
$$ is the start of the section, so 510 minus both of those gives you the length of the boot sector remaining under 510 bytes.

So back to what you are trying to do, ISR_0 - $$ will give you the offset of ISR_0 within the current section. Then shift it by 16.

While this might work for you, you should really do it at runtime. Your approuch is not very flexible and I think you will regret it later.

_mark()

..

Why? Why would i waste time doing it at Run-Time, when it can be done at Compile-Time?

Why isn't it flexible?, lol... if i encounter problems with it, i can always change it later

Point taken on both accounts....

But i still don't see how this works, wouldn't it give a wrong address by subtracting $$ from ISR_0 ??

Perhaps...All the more reason to do it in software...

I think what is happening is that you are turning the offset of ISR_0 into a number that NASM knows the size and location of. This way it can be shifted. Prior to the modifier, it only knew the location, but not size.

Now - someone else needs to verify this because I am far from a NASM expert. The only thing I have used it for was my boot sector (maybe 100 lines of nasm code is all I have ever written).

_mark()

The trick with $$ works because the offset of a symbol from the start of the section (which is what ISR_0 - $$ gives you) is constant and is known by the assembler. However, this will not work once you start linking more than one source file into the kernel, regardless of whether the final format is binary or otherwise.

My advice is to do the patchups at runtime. You may be wasting time, but you are only wasting a couple of clocks (a few nanoseconds), and you are only wasting it once (when the OS is loaded). You're wasting more time thinking about it now than the total time wasted by all your users worldwide waiting for your OS to do the patchups at runtime.

..

I wouldn't recommend writing all the kernel stuff in ONE LARGE file. Sooner or later you'll come to trouble with it, due to lack of organisation. When you ever have to scan through a source code file that is abt 5000 - 6000 lines of cobol code (EXCLUSIVE copy-files, incl. some local data definitions) you will understand the sense of building small entities linked together.

..

..

when i split the double word into two words and AX contains the low word:
AND EAX, 0xFFFF

will this code correctly move the two bytes into the correct location in a descriptor? (EBX contains the location of the first byte of the low offset.

MOV word [EBX], AX