Re: RE: __asm help..
Matt Dillon [EMAIL PROTECTED] wrote: :As long as gcc uses %ebp to address local variables and functoin parameters :rather than %esp you should be fine. %esp will be preserved, but if %esp is :for some odd reason used to address a variable during the C code, you are hosed. I strongly recommend against making assumptions about GCC's use of %ebp vs %esp... not if you want the __asm code to survive the GCC optimizer! But if gcc breaks that assumption, that implies it would break alloca(), and presumably they wouldn't do that. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] "Dead! And yet there he stands!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: __asm help..
: :But if gcc breaks that assumption, that implies it would break :alloca(), and presumably they wouldn't do that. : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] :"Dead! And yet there he stands!" alloca() is a GCC internal function, not a piece of __asm code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
:I'm trying to write some experimental mutex operations similar to those
:in -current, but to do differnt things (e.g. a read/write lock)
:however, I am having some problems with the __asm stuff.
:
:What I want to do is to define some operations that will
:assemble down to:
: pushfl
: cli
: [stuff]
: popfl
:
:I can generate the code, but it seems to me that there should be
:a way of telling gcc that you have just pushed an item onto the stack,
:so that if you were to have some C code between the push and po
:(of the flags reg) the compiler has a correct idea of where the
:SP is. I can imagine that it doesn't matter so it may be that there
:is no constaint for that purpose (I read the gcc asm info pages)
:but I wanted to make sure that that is the case because if it does turn
:out to be important, it may manifest itself as a wierd bug sometime
:in 2002.
:
:The current pushfl code in the kernel has the following:
:__asm __volatile("pushfl; popl %0" : "=r" (ef));
:which has no long term effect on the stack pointer so I cannot
:use it as a guide.
:
:--
: __--_|\ Julian Elischer
I think all you can do is move the addresses and data used
by 'stuff' into registers prior to the push, then manipulate
the registers between the push and the pop.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
__asm help..
I'm trying to write some experimental mutex operations similar to those
in -current, but to do differnt things (e.g. a read/write lock)
however, I am having some problems with the __asm stuff.
What I want to do is to define some operations that will
assemble down to:
pushfl
cli
[stuff]
popfl
I can generate the code, but it seems to me that there should be
a way of telling gcc that you have just pushed an item onto the stack,
so that if you were to have some C code between the push and po
(of the flags reg) the compiler has a correct idea of where the
SP is. I can imagine that it doesn't matter so it may be that there
is no constaint for that purpose (I read the gcc asm info pages)
but I wanted to make sure that that is the case because if it does turn
out to be important, it may manifest itself as a wierd bug sometime
in 2002.
The current pushfl code in the kernel has the following:
__asm __volatile("pushfl; popl %0" : "=r" (ef));
which has no long term effect on the stack pointer so I cannot
use it as a guide.
--
__--_|\ Julian Elischer
/ \ [EMAIL PROTECTED]
( OZ) World tour 2000
--- X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: __asm help..
On 08-Dec-00 Julian Elischer wrote: I'm trying to write some experimental mutex operations similar to those in -current, but to do differnt things (e.g. a read/write lock) however, I am having some problems with the __asm stuff. What I want to do is to define some operations that will assemble down to: pushfl cli [stuff] popfl I can generate the code, but it seems to me that there should be a way of telling gcc that you have just pushed an item onto the stack, so that if you were to have some C code between the push and po (of the flags reg) the compiler has a correct idea of where the SP is. I can imagine that it doesn't matter so it may be that there is no constaint for that purpose (I read the gcc asm info pages) but I wanted to make sure that that is the case because if it does turn out to be important, it may manifest itself as a wierd bug sometime in 2002. As long as gcc uses %ebp to address local variables and functoin parameters rather than %esp you should be fine. %esp will be preserved, but if %esp is for some odd reason used to address a variable during the C code, you are hosed. Just use foo = save_intr(); disable_intr(); .. restore_intr() for now. If you want to save the 2 instructions so badly, then you should probably be writing the whole chunk in assembly. Getting it correct first and optimizing later is more sane than getting correctness and optimization at the same time and not knowing which one your bugs are coming from. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
I'm trying to write some experimental mutex operations similar to those in -current, but to do differnt things (e.g. a read/write lock) however, I am having some problems with the __asm stuff. Julian; Wheels were invented around 1500BC. We don't need to go through all that again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: __asm help..
:As long as gcc uses %ebp to address local variables and functoin parameters :rather than %esp you should be fine. %esp will be preserved, but if %esp is :for some odd reason used to address a variable during the C code, you are hosed. I strongly recommend against making assumptions about GCC's use of %ebp vs %esp... not if you want the __asm code to survive the GCC optimizer! :Just use foo = save_intr(); disable_intr(); .. restore_intr() for now. If you :want to save the 2 instructions so badly, then you should probably be writing :the whole chunk in assembly. Getting it correct first and optimizing later is :more sane than getting correctness and optimization at the same time and not :knowing which one your bugs are coming from. : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ Yah, gotta agree there. The only thing that matters, Julian, are memory accesses. The number of instructions you use is irrelevant. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
Mike Smith wrote: I'm trying to write some experimental mutex operations similar to those in -current, but to do differnt things (e.g. a read/write lock) however, I am having some problems with the __asm stuff. Julian; Wheels were invented around 1500BC. We don't need to go through all that again. I'm doing it not for inclusion but for education. And in any case they may have been invented already but we don't HAVE suitable read/write locks in FreeBSD.. only the 'lock mangler' which is certainly not going to su[[ly me with locks for netgraph. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
Matt Dillon wrote: :As long as gcc uses %ebp to address local variables and functoin parameters :rather than %esp you should be fine. %esp will be preserved, but if %esp is :for some odd reason used to address a variable during the C code, you are hosed. I strongly recommend against making assumptions about GCC's use of %ebp vs %esp... not if you want the __asm code to survive the GCC optimizer! :Just use foo = save_intr(); disable_intr(); .. restore_intr() for now. If you :want to save the 2 instructions so badly, then you should probably be writing :the whole chunk in assembly. Getting it correct first and optimizing later is :more sane than getting correctness and optimization at the same time and not :knowing which one your bugs are coming from. : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ Yah, gotta agree there. The only thing that matters, Julian, are memory accesses. The number of instructions you use is irrelevant. foo = save_intr(); disable_intr(); .. restore_intr() has 4 extra memory accesses. pushf (the only way to save interrupt state) save to stack. save_intr() reads it back off the stack (ok a cache hit I suppose) and writes it to a memory location specied as an argument. (Not a cache hit..)(though maybe defered) After some processing, restore_intr() then reads it from the nominated address (probably a cache hit) and puts it on the stack. (not a cache hit). (though maybe defered) it is then read off the stack by popf (a cache hit). Since all I WANT to do is pushf disable intr fiddle popf (chache hit) I am annoyed by the fact that I have all those extra bus cycles going on. I can live with it for development but it still annoys me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
Since all I WANT to do is pushf disable intr fiddle popf (chache hit) I am annoyed by the fact that I have all those extra bus cycles going on. I can live with it for development but it still annoys me. You haven't yet explained how you plan to disable interrupts on the other CPUs... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
: : : Since all I WANT to do is : pushf : disable intr : fiddle : popf (chache hit) : : I am annoyed by the fact that I have all those extra bus cycles going on. : I can live with it for development but it still annoys me. : :You haven't yet explained how you plan to disable interrupts on the other :CPUs... : :-- :... every activity meets with opposition, everyone who acts has his Julian, I would recommend using the cmpxchgl instruction to implement atomic operations. Look at /usr/src/sys/i386/i386/mplock.s for an example. You will be in much better shape if you can avoid cli/sti (as Mike points out, it doesn't work across cpu's). mplock.s already has basic MP-compatible lock recursion and should provide a ready example on how you need to do the locking. There is a serious issue you need to consider when implementing an SMP-capable lock, and that is cpu-cpu synchronization. In order to synchronize an operation across multiple cpu's on IA32 you have to use the 'lock;' instruction prefix. Typically, the cmpxchgl must be locked. However, you only need to lock it when there is possible contention.. when you are aquiring the lock. You do not need to lock it when you are releasing the lock. If your assembly gets too complex, just make the assembly a subroutine call. Believe me, subroutine overhead is *nothing* compared to bus locking overhead. For that matter, the cli/sti alone will have more overhead then a subroutine call. Just write it in assembly and forget about trying to use the C __asm() directive. You'll be happier. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
: :foo = save_intr(); disable_intr(); .. restore_intr() :has 4 extra memory accesses. UGh. I put my foot in it. Let me qualify my remark... memory accesses that cause an L1 cache miss are a problem. Memory accesses to locations written to by other cpu's are a problem. Memory accesses that are L1 cached are NOT a problem. Memory accesses to the first few words of the stack are almost guarenteed to be in the L1 cache. Just don't worry about it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
