[M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack?

[Tony Hosking]

Here's what Boehm produces in his libatomic package.  Don't know if it helps or answers your question.

The C source:

int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new)
{ return AO_compare_and_swap_full(addr, *old, new); }

generates:

.globl _Atomic__CompareSwap_ordered
_Atomic__CompareSwap_ordered:
LFB526:
	pushq	%rbp
LCFI42:
	movq	%rsp, %rbp
LCFI43:
	movq	(%rsi), %rax
	lock; cmpxchgq %rdx, (%rdi); setz %al
	movsbl	%al,%eax
	leave
	ret
LFE526:
	.align 4,0x90



On 12 Feb 2010, at 04:17, Jay K wrote:

> Tony, currently I have atomic.compare_and_exchange generating e.g.:
>  
>  
>  load_address      gv.2[_MM_Main] 56
>  0000018E: 8D3538000000        LEA ESI gv.2[_MM_Main]+56
>  load_address      gv.2[_MM_Main] 152
>  00000194: 8D3D98000000        LEA EDI gv.2[_MM_Main]+152
>  load              gv.2[_MM_Main] 156 Int.32 Int.32
>  compare_exchange   Int.32 Int.32 Int.32
>  0000019A: 8BC7                MOV EAX EDI
>  0000019C: 8B1D9C000000        MOV EBX gv.2[_MM_Main]+156
>  declare_temp      4 4 Addr F tv.35[T$35] -4
>  000001A2: 8975FC              MOV tv.35[T$35] ESI
>  000001A5: F00FB15DFC          LOCK CMPXCHG  tv.35[T$35]:Addr EBX
>  
> 
> This might not be correct, but it is close.
>  
> 
> Now, the thing is, the eax register is special to lock cmpxchg.
>   It always holds the comparison value.
> 
> The point is, if cg.compare_exchange took its parameters as
> parameters instead of on the stack, it could chose the
> right register right away, instead of as above where it
> choses the wrong one and then must mov it.
>  
> Easy to change it like that?
>  
> 
> I realize this is an m3back deficiency.
> It does the register allocation too early.
> 
>  - Jay
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100212/c2aba604/attachment-0002.html>