If I have a code selector with its base set to 1024 and then put a program in the associated segment... What will the EIP be? Will it be 1024 or will it be zero?
You probably understand why I'm asking this (that is, if you understood my question since it is quite hard to understand at all )... I want to know if a program with "org 0" can execute correctly in any of the code selectors that may exist...
Selector's base...
Re:Selector's base...
a near jmp has a new EIP as an operand
jmp mylabel
a far jmp takes (in the case of pmode) a selector and EIP
jmp CODE_SEL:mylabel
This is basically the same as real mode, except the value in CS in interpreted differently -- as a 'selector' whose top 13 bits are an index into the GDT (which provides the physical base address, among other things)
Regarding ORG, which only applies to binary files, here is a quote from the NASM docs
"Its sole function is to specify one offset which is added to all internal address references within the file"
Although I understand the "what if" nature of your question, on a practical level, there aren't too many cases of having user programs as binary files or even using segmentation for memory management. Paging and some kind of executable file format with header info are pretty much ubiquitous.
jmp mylabel
a far jmp takes (in the case of pmode) a selector and EIP
jmp CODE_SEL:mylabel
This is basically the same as real mode, except the value in CS in interpreted differently -- as a 'selector' whose top 13 bits are an index into the GDT (which provides the physical base address, among other things)
Regarding ORG, which only applies to binary files, here is a quote from the NASM docs
"Its sole function is to specify one offset which is added to all internal address references within the file"
Although I understand the "what if" nature of your question, on a practical level, there aren't too many cases of having user programs as binary files or even using segmentation for memory management. Paging and some kind of executable file format with header info are pretty much ubiquitous.
Re:Selector's base...
I know what use Org has but its sole purpose in my topic was to show that the base of the program memory pointers is set to zero (nothing is added to the pointers).crazybuddha wrote:
a near jmp has a new EIP as an operand
jmp mylabel
a far jmp takes (in the case of pmode) a selector and EIP
jmp CODE_SEL:mylabel
This is basically the same as real mode, except the value in CS in interpreted differently -- as a 'selector' whose top 13 bits are an index into the GDT (which provides the physical base address, among other things)
Regarding ORG, which only applies to binary files, here is a quote from the NASM docs
"Its sole function is to specify one offset which is added to all internal address references within the file"
Although I understand the "what if" nature of your question, on a practical level, there aren't too many cases of having user programs as binary files or even using segmentation for memory management. Paging and some kind of executable file format with header info are pretty much ubiquitous.
Segmentation is always required in memory management from what I have read... And how can an exe header help???
Your answer then is that
* an Org 0-program cannot run properly if the code selector's base isn't zero and
* to make it run properly, paging is required.
Have I understand your answer correctly?
Re:Selector's base...
Not quite. You can, of course, create descriptors with different base addresses for programs to run in. The EIP will be relative to those. This should be easy (?!) to test by creating an additional descriptor (in addition to the usual null, code, data) and jmp'ing there and back again. Make sure the "program" file is assembled separately so it doesn't have screwed up offsets. You might have to be careful of the limits though. And it would probably be helpful to have already setup the IDT to handle exceptions in some way.
ORG allows you the 'fix up' the addresses at assembly. Otherwise, you have a loader that will patch the object code (such as for an EXE file) with new addresses based on where it's loaded. The header tells the loader where in the file to find the necessary info to do this.
Paging maps physical memory to 'logical' (i.e. virtual) addresses, which will start at zero. So as far as a program is concerned, it looks to it like there is nothing else in memory at all.
All this loading stuff is complicated by the different formats (COM, EXE, AOUT, COFF. ELF), but they tend to be suited to different circumstances.
ORG allows you the 'fix up' the addresses at assembly. Otherwise, you have a loader that will patch the object code (such as for an EXE file) with new addresses based on where it's loaded. The header tells the loader where in the file to find the necessary info to do this.
Paging maps physical memory to 'logical' (i.e. virtual) addresses, which will start at zero. So as far as a program is concerned, it looks to it like there is nothing else in memory at all.
All this loading stuff is complicated by the different formats (COM, EXE, AOUT, COFF. ELF), but they tend to be suited to different circumstances.