🚀 go-pugleaf

In article <1992Sep29.160306.6352@infodev.cam.ac.uk> crj10@phx.cam.ac.uk (Clive Jones) writes:
>Hmm. I've just got my hands on a draft ANSI C standard, and it's quite
>clear, unfortunately, that an implementation is under no obligation at
>all to do this, however:
>

Talking of ANSI compliance are the format specifiers for strftime()
well defined? The format specifiers for Sun cc are totally different
to those for Acorn/Norcroft C. Its a pain when porting.

Who is right?

A

Andrew P.Mell writes:
> Talking of ANSI compliance are the format specifiers for strftime()
> well defined? The format specifiers for Sun cc are totally different
> to those for Acorn/Norcroft C. Its a pain when porting.
> 
> Who is right?

Hmm.  Sun CC is (or at least, the one we use is) K&R/Unix BSD compatible,
and is *not* ANSI compliant!  As far as I can tell, the differences is the
libraries are due to ANSI, not Acorn/Norcroft.

However, Huw's UnixLib may contain the variant used in the Sun libraries.

							Ug!

Clive Jones writes:
> It would be very nice if the compound assignment operators (+=, -=,
> *=, etc.) were atomic if applied to volatile variables.

That's a *really* good idea!  In fact, ANSI does not decree that volatile
need effect anything, but it would be nice to see it used in this
manner.  Having easy access to atomic instructions would make thinks like
high-level synchonisation possible, without getting down and dirty and
doing it in assembler (which all too often loses the meaning of the
operation).

If it hasn't been done, then I for one would also vote for this!  (as if
deciding what goes into a product is a democratic process...  boy, are we
dumb or what?)
								Ug!

Clive Jones writes:
>Hmm. I've just got my hands on a draft ANSI C standard, and it's quite
>clear, unfortunately, that an implementation is under no obligation at
>all to do this, however:
>
>It would be very nice if the compound assignment operators (+=, -=,
>*=, etc.) were atomic if applied to volatile variables. The obvious
>way to achieve this would be using SWP, 

How?  Sorry to disappoint, but the SWP instruction (as its mnemonic
suggests) implements the swapping of data between memory and
registers, atomically (see below for details).  It doesn't implement
atomic register-to-memory operations of any other sort.  Regretably,
then, there is no obvious way to implement what Clive requests: the
SWP instruction itself cannot be used to do it.  

The nearest thing I can think of is to use SWP to implement
synchronisation interlocking (using spin-locks) around the required
("critical region") code sequences.  But this is only applicable for
inter-processor interlocks, it does not prevent interrupts from
getting in in the middle of an operation on a single processor.

If you really want atomic *=, +=, -= etc, you would need to add new
"atomic {multiply,add,subtract,<whatever>} register-to-memory"
instructions to ARM to implement them.  This is not going to happen
unless some very large customer approaches ARM Ltd with a very large
lump of money and seriously subverts their dedication to the RISC
philosophy.

[ For those who don't know, SWP takes three registers (Rd, Rm, Rn) as
operands, and atomically performs the two steps:

	Rd := memory[Rn]
	memory[Rn] := Rm

Rd and Rm can be different, so it's more general than a swap - it's
really a read-then-write to a single byte or word memory location.  At
the internal level the operation cannot be broken up by interrupt,
though it is still subject to address exception or data abort faults.
External atomicity is effected if appropriate (e.g. in multi-processor
systems) by asserting a LOCK pin on the processor chip for the whole
duration of the read-then-write operations. ]


Mark.

In article <19034@acorn.co.uk> mark@acorn.co.uk (Mark Taunton) writes:
>Clive Jones writes:
>>Hmm. I've just got my hands on a draft ANSI C standard, and it's quite
>>clear, unfortunately, that an implementation is under no obligation at
>>all to do this, however:
>>
>>It would be very nice if the compound assignment operators (+=, -=,
>>*=, etc.) were atomic if applied to volatile variables. The obvious
>>way to achieve this would be using SWP, 
>
>How?  Sorry to disappoint, but the SWP instruction (as its mnemonic
>suggests) implements the swapping of data between memory and
>registers, atomically (see below for details).  It doesn't implement
>atomic register-to-memory operations of any other sort.  Regretably,
>then, there is no obvious way to implement what Clive requests: the
>SWP instruction itself cannot be used to do it.  

Before posting, I came up with the following code, which updates the
variable pointed to by Ra, using v1 and v2 as scratch registers.

          LDR v1,[Ra]
loopback  MOV v2,v1
          < Perform the operation required on v1,
            eg. ADD v1,v1,#1  for  a+=1 >
          SWP v1,v1,[Ra]
          TEQ v1,v2
          BNE loopback

However, I have now checked the code, and, although it works fine for
two overlapping tasks, or for any number if the tasks are trying to
use equivalent operations, there is a potential for problems if three
tasks were to simultaneously try a|=1 a|=2 and a|=4, for example.

The problem arises because the above code updates the value in [Ra]
even if it has changed under its feet while it was processing. This is
unfortunate - what is really needed is is a TestAndReplace
instruction, similar to SWP, which means:

TAR Ra,Rb,[Rd] = 
  LOCK
  Load the old value from [Rd]
  TEQ that value with Rb, setting the ARM status flags on the result
  If Z is set, store Ra in [Rd]
  Put the old value of [Rd] in Rb
  UNLOCK

Unfortunately, this would require two transiently-held values at a time,
rather than one. )-8

My feeling is that there ought to be some modification to my above
code fragment that would make it secure in all cases - I'll think
about it. Can anyone else suggest a way to make it work for sure?

--Clive.