"Terje Mathisen" <spamtrap@[EMAIL PROTECTED]
> wrote in message
news:77OdnffMSLK8n5fVnZ2dnUVZ_oOnnZ2d@[EMAIL PROTECTED]
> Chris Thomasson wrote:
>> Before I convert this code into AT&T syntax for GAS to assemble, and to
>> MASM I was wondering if there are any possible optimizations I can
>> perform on the following code, I will show the C header first:
>
> The code looks OK, at least on a first read-through, but you really
don't
> need to worry about asm performance details!
>
> The LOCK CMPXCHG etc instructions will take so much time that tiny
things
> like using XOR EAX,EAX instead of MOV EAX,0 to save code space doesn't
> matter.
;^)
> The one thing I would change would be the function call/return format:
>
> You are using the cdecl default of stackbased parameters and caller
stack
> cleanup, but you only use one or two parameters for most functions,
right?
Indeed.
> If you instead use register-based calling each call can be simpler &
> faster, and the implementation becomes shorter as well:
Okay. I am wondering about the consistency of the fastcall calling
convention. I am going to move this from inline _asm to pure assembly
files
that can be assembled with MASM and GAS. I am going this mainly because I
am
not good with GCC inline-assembly, and VC++ do***entation mentioned
something about dropping sup****t for it in future versions...
I would like to be able to allow a fairly diverse number of C compilers to
link against the assembled object files. Do you have any tips on how to
produce a "****table" register based calling convention? I know that VC++
and
GCC have fastcall directives, but I wonder if they pass parameters in the
same registers. I think I remember reading something in the do***entation
for VC++ that says fastcall is subject to change in further releases of
the
compiler.
If I can't reliably use register-based calling convention in the object
files, then, well I guess the code is good enough as-is... Humm...
[...]
> but at this point it should be obvious that this particular function can
> be implemented as a single-line inline macro, since there is nothing
here
> except for an atomic store. :-)
;^)
[...]
|
