virtual mode...

[AJ]

After an exception control is transferred to the kernel which DOES live above the 1MB mark. You are looking at the EIP of a JMP $ instruction inside the kernel.

Oops - missed that in my reply!

[xyjamepa]

Hi...

Now things are making more and more sense to me.
but I have another question:
I made a simple normal task not virtual and it was at 4KB (0x1000).
Inside this normal task I printed a char using direct access to
video memory 0xB8000 and every thing worked fine without any exceptions.
but when I tried to use my normal functions such as printf I got gpf.
what does this mean? why I couldn't use my functions there at 0x1000?

Just to be sure:
I used the same task but this time I enabled VM bit in EFLAGS so this task
became a virtual task I tried to print a char using direct access to 0xB8000
but I got gpf this sould be fine as long as I don't have a gpf handluer,
Am I right?
Thanx.

[Combuster]

Everything I am going to say now has been said before in this thread one way or the other. I doubt that is a good sign

I made a simple normal task not virtual and it was at 4KB (0x1000).
Inside this normal task I printed a char using direct access to
video memory 0xB8000 and every thing worked fine without any exceptions.
but when I tried to use my normal functions such as printf I got gpf.
what does this mean? why I couldn't use my functions there at 0x1000?

Have you actually organised your code with an entry point of 0x1000 [ORG 0x1000]? If you are using C, you will need to link to entry point 0x1000.

The logic behind that: an function thinks relative to itself. When you move a single function, all the functions related to it are somewhere completely different (they are now 1MB rather than a few bytes):

I used the same task but this time I enabled VM bit in EFLAGS so this task
became a virtual task I tried to print a char using direct access to 0xB8000
but I got gpf this sould be fine as long as I don't have a gpf handluer,
Am I right?
Thanx.

* You can not normally use GCC to generate code for virtual 8086 tasks. This is because GCC generates 32-bit code while in virtual mode code is executed as 16 bits. The easiest way is to write 16-bit assembly with nasm/yasm and use that.

[xyjamepa]

Hi...

The logic behind that: an function thinks relative to itself. When you move a single function, all the functions related to it are somewhere completely different (they are now 1MB rather than a few bytes):

I think I didn't get this point quite right,would you please give me more
explain about that

Have you actually organised your code with an entry point of 0x1000 [ORG 0x1000]? If you are using C, you will need to link to entry point 0x1000.

I'm using C ,so how can I link to an entry point 0x1000?

Thanx.

[AJ]

OK - you are using C, so firstly, make sure you are using a C compiler *which supports 16 bit code* (not GCC). You will either need to specify a command-line option or use a linker (like LD), to link at 0x1000. A linker script may have code like:

Code: Select all

ENTRY(__main);

phys = 0x1000;

SECTIONS
{
  .text phys : AT(phys) {
...
...
}

or something similar. You will have to know the specific command line option / script command for the 16 bit toolchain you are using.

The code output by your compiler is not position-independant. This means that the binary has to know where it is expecting to be loaded in memory. That's why you need to specify this value. Your exe loader needs to honour the expected entry point in order for the code to work.

I know this is probably extremely hypocritical of me , but I think you really need to know more about your chosen toolchain before attempting to develop an OS in it. There is normally a manual (online or otherwise) for the compiler which will explain what command switches do.

Granted - these online references can be a bit cryptic at times!

Cheers,
Adam

[Combuster]

FYI:
http://en.wikipedia.org/wiki/Position_independent_code
http://www.delorie.com/gnu/docs/binutils/ld_6.html

Next time, google before asking

[xyjamepa]

I'm okay now.

Thank you guys for your help.

I'm so grateful.