Date: Thu, 13 Jan 2000 21:41:28 -0500 From: "Mikhail Evstiounin" <evstiounin@adelphia.net> To: <keramida@ceid.upatras.gr> Cc: <freebsd-questions@freebsd.org> Subject: Re: Volatile variables Message-ID: <00b701bf5e38$dc273600$a9353018@evstiouninadelphia.net.pit.adelphia.net>
next in thread | raw e-mail | index | archive | help
-----Original Message----- From: Giorgos Keramidas <charon@hades.hell.gr> To: Mikhail Evstiounin <evstiounin@adelphia.net> Cc: freebsd-questions@freebsd.org <freebsd-questions@freebsd.org> Date: Thursday, January 13, 2000 5:36 PM Subject: Re: Volatile variables >On Wed, Jan 12, 2000 at 10:02:43PM -0500, Mikhail Evstiounin wrote: >> >> > From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> >> >> Your example still leaves variable in a "stale" mode. > >It was not Oliver's example; it was mine. Any blame for not using >aggressive optimization should also be credited back to me, and not >Oliver, thank you. In fact, I did use -O2 of gcc-2.7.2.3 which comes >with my FreeBSD 3.4-STABLE. That was supposed to provide for some form >of optimization. Yeap, I figured it out after I sent it and appologized (could my appology be accepted?). > >Anyway, what volatile means, as far as I have understood so far, is >that "between" C statements the compiler can not assume that the >variable has not changed. Therefore, it's value must be refetched from >it's memory location, instead of relying on a register which `might' >contain the value of the variable. In my mind, it even worse. Probably I didn't myself clear enough. When I qouted BS, I mean, that value of variable could be changed not just between lines, but as a matter of fact, while you are in the middle of line. Timer is perfect example. Your example about hardware ports and registers is another perfect case. Any hardware works asynchronosly and can chage this variable at any time. And let me say something more - variable could be on a register if this is the only copy of a varible. Once we wrote a compiler (I believe, for some NS chip). It has 192 registers - very RISK CPU - w eallocated a special pool of registeres for global variables, we wrote the whole system - compiler, smart linker, etc. And in PDP11 world you could map memory to registers (or vice versa), and that allows you to do some fancy stuff. So vilotile, form my point of view, means - no copy of a variable. > >If a signal handler changes the value of a variable, the context change >that happens when you enter the signal handler is not know to the >compiler. Two statements like: > > int k = 0; > k = 1; > >might be interrupted for handling a signal. If the compiler can assume >that the value of a register holds the true value of `k' and a signal >handler changes it in the middle of these two statements, then weird Again, if any line is mapped to multiple assembler command then the sequence of assembler command could be interrupted between any assembler commands. It's even worse, than your assumption. >things can happen. That's what `volatile' is supposed to protect us >from. > >> The same is with vilotile - if there is a way to provide an "atomic" >> way for some part of code then compiler can use some pretty aggresive >> optimizations. > >There are ways to provide atomic modifications to memory areas under >Unix too, but that would require the compiler to know a lot more about >the execution environment (Unix in this case). > it depends on hardware and OS. >Semaphores spring into my mind, but that would require the compiler to >know whether you have SYSV_SEM in your kernel options, which you might >prefer not to have. It's a mess, it seems... Yeap, but sometimes, hardware gives you a special support. There was a big discussion about ho to implement semaphores on I8086, 286, until Intel supports a special command. But even then there were some problems with multi CPU support. If you are interested, I can try to recall all this stuff. I a not in a business of compiler writing since 5:-( > >Ciao. > >-- >Giorgos Keramidas, < keramida @ ceid . upatras . gr > >"What we have to learn to do, we learn by doing." [Aristotle] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00b701bf5e38$dc273600$a9353018>