[OSy] Kompilovanie testov

[Miloslav Trmac]

On Fri, Nov 05, 2004 at 11:27:03AM +0100, Petr Tuma wrote:
> Predpokladam, ze funkce schedule prepina kontext ? Pokud ano, pak je 
> mozna vhodnejsi nekam do ni dat "volatile int foo; foo = 0;" nez davat 
> state jako volatile
Prirazeni do volatile promenne prece nema zadny vliv na ostatni promenne,
to neni vseobecna bariera branici prekladaci presouvat praci s ostatnimi
promennymi.[1]

Bez pohledu na zdrojaky:
* Kompilator si zrejme mysli, ze current se nemeni a ze zna vsechny pristupy
  k *current, nebo vi ze schedule () *current nemodifikuje; jinak by si
  nemohl dovolit "cachovat" pres volani fce.
* Strela do tmy: Nechybi v nejakem asm () jako `clobbered' polozka "memory"?
  ["Vseobecna bariera" jako vyse je v gcc
	asm volatile ("" : : : "memory")
  ]
	Mirek

[1] Vse, co C garantuje o volatile:
* 5.1.2.3p2: Accessing a volatile object ... are all side effects ...
  At ... sequence points, all side effects of previous evaluations shall
  be complete and no side effects of subsequent evaluations shall have
  taken place.
  (sequence point je napriklad v miste stredniku na konci prikazu)
* 5.1.2.3p5: At sequence points, volatile objects are stable in the sense
  that previous accesses are complete and subsequent accesses have not yet
  occurred.
* 6.7.3p6: An object that has volatile-qualified type may be modified in ways
  unknown to implementation or have other unknown side effects. Therefore any
  expression referring to such an object shall be evaluated strictly according
  to the rules of the abstract machine, as described in 5.1.2.3. Furthermore,
  at every sequence point the value last stored in the object shall agree
  with that prescribed by the abstract machine, except as modified by the
  unknown factors mentioned previously. ...
* 7.13.2.1p3: neco o longjmp a setjmp
* 7.14.1.1p5: neco o volatile sig_atomic_t