This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: atomic accesses


The Linux kernel, and probably some user-space applications and libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction whenever possible"
and it seems the current compiler actually does work like this.
Seems a pity to have the bit-field exception here, why is it there?
Bit-fields will generally require a read-modify-write instruction,
and I don't think we actually guarantee to generate one right now.
Well if they do require more than one instruction, the rule has
no effect ("whenever possible"). If they can be done in one
instruction  (as on the x86), then why not require this, why
make a special case?
Because current GCC doesn't work like this AFAIK.  I'm aiming for
a documentation-only change here, we can always extend it later.

Fair enough, we don't want to document something we don't do!


Does this rule extend to the use of floating-point instructions
to guarantee atomic access to 64-bit long_long_integer, as
written it does!

Good point. Suggestions for better wording? How does


	"any access to a naturally aligned scalar object in memory
	that is not a bit-field and fits in a general purpose integer
	machine register, will be performed by a single machine
	instruction whenever possible"

or

	"any access to a naturally aligned scalar object in memory
	that is not a bit-field and not bigger than a long int,
	will be performed by a single machine instruction whenever
	possible"

sound?


Segher



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]