Andrew Haley wrote:
This doesn't sound very different from the small memory model. With
the small model, the program and its symbols must be linked in the
lower 2 GB of the address space, but pointers are still 64 bits. This
is the default model for gcc on GNU/Linux. It would be possible in
th
Andrew Haley wrote:
Darryl Miles writes:
> Andrew Haley wrote:
> I'm not aware of a small memory model until now, let alone that I maybe
> actually using it already and that its already what I'm making an
> inquiry about.
Reading the gcc documentation would h
Comments inline below v
Tomash Brechko wrote:
Consider this piece of code:
extern int v;
void
f(int set_v)
{
if (set_v)
v = 1;
}
f:
pushl %ebp
movl%esp, %ebp
cmpl$0, 8(%ebp)
movl$1, %e
Dave Korn wrote:
On 27 October 2007 18:27, Darryl Miles wrote:
The "unintended write-access" optimization is a massive headache for
developers of multi-threaded code.
But it's a boon for the autovectoriser, because it means it can transform
code with a branch into straight-li
David Miller wrote:
The compiler simply cannot speculatively load or store to variables
with global visibility.
s/with global visibility/with visibility outside the scope of the
functional unit the compiler is able to see at compile time/
Which basically means the compiler is king for doing
David Miller wrote:
From: Darryl Miles <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 04:53:49 +
What are the issues with "speculative loads" ?
The conditional might be protecting whether the pointer is valid and
can be dereferenced at all.
This then leads into the questio
skaller wrote:
Ah .. ok I think I finally see. Thanks! The code ensures
well definedness by checking the establishment of the
required invariant and dynamically chosing whether or not
to do the access on that basis .. and the optimisation
above defeats that by lifting the access out of the
condit
Michael Matz wrote:
if (condition)
*p = value;
(i.e. without any synchronization primitive or in fact anything else after
the store in the control region) and expect that the store indeed only
happens in that control region. And this expectation is misguided. Had
they written it like:
Michael Matz wrote:
Don't you need the barrier before. This is to ensure it completed the
condition test completely first before it then processed the assignment
expression.
if(condition) {
somebarrier();
*p = value;
}
The issue is not that the store is done too late, but that a
write-acces
