Page 2 of 2
Re:Call gates
Posted: Wed Aug 11, 2004 9:01 pm
by chris
What exactly is the difference between Call Gates and Trap Gates?
Re:Call gates
Posted: Wed Aug 11, 2004 10:31 pm
by Brendan
Hi,
chris wrote:
What exactly is the difference between Call Gates and Trap Gates?
The main difference is that call gates allow parameters to be transferred on the stack (e.g. the top N dwords from the user level stack can be automatically copied to the kernel's stack). This is intended for the calling conventions in high level languages. With trap gates all parameters must be passed in registers.
Another difference is that trap gates belong in the IDT, while call gates go in the GDT or LDT.
Cheers,
Brendan
Re:Call gates
Posted: Wed Aug 11, 2004 11:48 pm
by Dreamsmith
Brendan wrote:The main difference is that call gates allow parameters to be transferred on the stack (e.g. the top N dwords from the user level stack can be automatically copied to the kernel's stack). This is intended for the calling conventions in high level languages. With trap gates all parameters must be passed in registers.
Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.
Re:Call gates
Posted: Thu Aug 12, 2004 10:14 am
by chris
Dreamsmith wrote:
Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.
Then why not simply use call gates?
Re:Call gates
Posted: Thu Aug 12, 2004 10:26 am
by RedMan
A new stack? I thought there was only one stack, what?s up with the new stack?
Re:Call gates
Posted: Thu Aug 12, 2004 1:08 pm
by Candy
RedMan wrote:
A new stack? I thought there was only one stack, what?s up with the new stack?
Each thread has its own stack, each thread also has its own kernel stack. Using some tricks you can avoid having two stacks (such as my OS will do when it gets to userlevel stuff), but usually you have both a kernel stack and a userlevel stack.
Re:Call gates
Posted: Thu Aug 12, 2004 5:23 pm
by RedMan
Oh, is this something "special magic autmaticlly" or I decide if I?d like to have that by changing the stack pointer by myself?
Re:Call gates
Posted: Fri Aug 13, 2004 12:23 am
by Candy
RedMan wrote:
Oh, is this something "special magic autmaticlly" or I decide if I?d like to have that by changing the stack pointer by myself?
no, this is fully automatic. You specify them all in your TSS (you must have one of those too), and then you always swap them, using Intels methods at least.
In AMD64 this is fixed, you can choose whether to swap the stack, and using SYSCALL/RET the default is NOT to. Upon interrupt one of a number of stacks can be used, all specified in the new-style TSS (which doesn't hold the task info but more the system state, such as the stacks).
Re:Call gates
Posted: Fri Aug 13, 2004 3:24 pm
by Dreamsmith
chris wrote:
Dreamsmith wrote:
Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.
Then why not simply use call gates?
Excellent question.
The answer would be, because trap gates take less space and are faster. Now, if I was using a trap gate, then manually copying the parameters between stacks, that would be silly, might as well use a call gate in that case. But I
don't copy parameters between stacks. Instead, I just look at them in place on the old stack. I don't use a call gate because I don't
want to waste time copying parameters between stacks when I don't need to.
Of course, for this to work, you need access to the caller's stack, but for my kernel that's a given. It would only be an issue if you're just routing the request to some user-thread, ala a microkernel approach, in which case you would need to copy the parameters.
Re:Call gates
Posted: Fri Aug 13, 2004 3:57 pm
by RedMan
Stupid question, but how does the CPU know how many arguments to pass to the new stack?
Re:Call gates
Posted: Fri Aug 13, 2004 4:14 pm
by Dreamsmith
You specify that when you create the call gate. Note, varargs is not an option...
Re:Call gates
Posted: Fri Aug 13, 2004 8:29 pm
by chris
Dreamsmith wrote:
chris wrote:
Dreamsmith wrote:
Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.
Then why not simply use call gates?
Excellent question.
The answer would be, because trap gates take less space and are faster. Now, if I was using a trap gate, then manually copying the parameters between stacks, that would be silly, might as well use a call gate in that case. But I
don't copy parameters between stacks. Instead, I just look at them in place on the old stack. I don't use a call gate because I don't
want to waste time copying parameters between stacks when I don't need to.
Of course, for this to work, you need access to the caller's stack, but for my kernel that's a given. It would only be an issue if you're just routing the request to some user-thread, ala a microkernel approach, in which case you would need to copy the parameters.
Makes sense to me, thanks.