Re: ptep_establish/establish_pte needs set_pte_atomic and all set_pte must be written in asm

[Andrea Arcangeli]

On Sun, Sep 26, 2004 at 10:36:40PM +0200, Andrea Arcangeli wrote:
> On Mon, Sep 27, 2004 at 06:30:25AM +1000, Paul Mackerras wrote:
> > FWIW, we also rely on several other things that are not guaranteed by
> > the C standard, for instance that integer arithmetic is 2's
> > complement, that bytes are individually addressable, and that pointers
> > are represented by an address that is no bigger than a long.
> 
> I wouldn't compare these with atomic writes on non volatile variables. I
> mean, sizeof(char *) being different than sizeof(long) is something I'm
> very confortable will not break anytime. If you want to add up to the
> list, even the gcc inline assembly itself isn't part of the language...
> (infact that was the major trouble for icc to add it AFIK)

Just to make an example of why you definitely cannot compare the
assumption of sizeof(char *) == sizeof(long), and complement 2
aritmetic, is that gcc is allowed to implement something like this:

	*64bit_ptr = 32bit_integer_var << 32;

as two instructions: xorl and a movl, that is likely to be faster than a
shiftleft + movq. Or maybe it's not faster on the x86-64 and gcc may
prefer to use shiftleft + movq, but you get the idea of what I'm talking
about, maybe for other archs the performance point is different etc...
(by instinct I believe it'd be faster even on x86, especially on the
nocona based on p4 core)

with the ptes on x86 the shiftleft of 12 probably avoid screwups but
that's just because we're lucky and I don't want to think what else gcc
could optimize by evaluating constants...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/