[M3commit] CVS Update: cm3

[Jay]

> "-march=i686".
 
This is a confusing area -- *so many* switches to configure and gcc, but maybe we should have m3-sys/m3cc/src/m3makefile configure it to always be so, or always at least so?
 
Maybe in this case it isn't even a configure switch, but the platform tuple.
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 17 Feb 2009 17:10:10 +1100
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> It is sometimes more efficient, depending on hardware.
>
> I forgot to mention that to use these intrinsics you need to tell the
> backend in your cm3.cfg to take advantage of suitable instructions
> where available. On x86 I use "-march=i686".
>
> On 17 Feb 2009, at 16:06, Jay wrote:
>
>>
>> Is CASP trivially constructed from CAS?
>>
>> CASP(value, old, new) == (CAS(value, old, new) == old) ?
>>
>> P for predicate? ie: returns boolean?
>>
>>
>> Or a) am I just wrong?
>> b) sometimes it is more efficient implemented more directly?
>>
>>
>> For example, I know "InterlockedIncrement" can be implemented as an
>> infinite retry loop around compare_and_swap, but that doesn't seem
>> most efficient, e.g:
>>
>>
>> long InterlockedIncrement(volatile long* p):
>> while (1)
>> long old = *p;
>> if (InterlockedCompareExchange(p, old, old + 1) == old)
>> return (old + 1);
>>
>>
>>
>> I assume we don't care about 386 support, nor maybe even 486.
>> Somewhere along the line way back "lock cmpxchg8b" is not supported.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> Date: Tue, 17 Feb 2009 05:45:48 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>>
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 09/02/17 05:45:48
>>>
>>> Modified files:
>>> cm3/m3-sys/m3front/src/builtinOps/: BuiltinOps.m3 m3makefile
>>> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Token.m3
>>> cm3/m3-sys/m3front/src/values/: Formal.i3 Formal.m3
>>> Added files:
>>> cm3/m3-sys/m3front/src/builtinOps/: Cas.i3 Cas.m3 CasP.i3
>>> CasP.m3
>>>
>>> Log message:
>>> Experimental support for compare_and_swap (CAS) and compare_and_set
>>> (CASP) builtin operations.
>>> CAS is defined as follows:
>>>
>>> CAS(v, o, n): BaseType(v)
>>>
>>> where v is an integer variable (INTEGER/LONGINT), and o and n are
>>> assignable to v,
>>> atomically sets v to value n, so long as the previous value of v is
>>> o, returning the previous
>>> value of v in either case.
>>>
>>> Similarly, CASP is defined as:
>>>
>>> CASP(v, o, n): BOOLEAN
>>>
>>> atomically sets v to n, so long as the previous value of v is o,
>>> returning TRUE if the
>>> comparison is successful and n was assigned to v.
>>>
>>> I may yet generalize these to permit v to have any ordinal type.
>>> In unsafe modules I may also permit v to be a subtype of ADDRESS.
>>>
>