Re: Ternary operator and memory access
- From: Chris Torek <nospam@xxxxxxxxx>
- Date: 7 Aug 2006 22:49:37 GMT
Richard wrote On 08/07/06 11:05,:
Possibly I overs implified it : there is no issue with HW if the
"result" of b=g() is used from a register. But clearly if expressions
(1) and (2) are of the form "*a" or "*b" then it would be madness for
the compiler to access *b if the condition is true. Or?
Or, more specifically, suppose we have:
int f(int x, int *ap, int *bp) {
return x ? *ap : *bp;
}
(which is of course just the conditional operator itself, written in
function form, with type restricted to "int" and pointers for the
values involved).
In article <1154965455.873251@news1nwk>
Eric Sosman <Eric.Sosman@xxxxxxx> wrote:
The compiler might not know whether *a,*b are or aren't
safe, but it might be able to tell that it makes no difference.
int *a = ...;
int *b = ...;
*a = 42; /* die here if *a unsafe */
*b = 56; /* die here if *b unsafe */
x = cond ? *a : *b;
The compiler might conclude that if *a,*b are unsafe the final
line won't be executed anyhow, hence a speculative fetch adds
no new failure mode to the program.
Or, the machine may have a "load from memory, but if there is a
fault during loading, ignore it" instruction -- often actually
spelled "prefetch" and having no target register -- in which case,
it can generate:
f_: .global f_
# inputs: r1 = x, r2 = ap, r3 = bp
pref (r2) # prefetch from *ap
pref (r3) # prefetch from *bp
tst r1 # which one should we use?
bz L1
ld r0,(r2) # x != 0, so fetch from *ap
ret
L1:
ld r0,(r3) # fetch from *bp
ret
The two "extra" instructions start RAM -> cache transfers, which
typically take dozens of CPU cycles, if needed. Meanwhile the CPU
can still execute instructions. This means that the during the
delay caused by testing r1 (i.e., x), something useful is still
going on.
(These "prefetch" instructions would be more useful if they were
placed further back in the instruction stream, which is of course
only possible if the routine f() is expanded in line.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
.
- References:
- Ternary operator and memory access
- From: Udo A. Steinberg
- Re: Ternary operator and memory access
- From: Eric Sosman
- Re: Ternary operator and memory access
- From: Richard
- Re: Ternary operator and memory access
- From: Eric Sosman
- Ternary operator and memory access
- Prev by Date: Re: calloc()
- Next by Date: Re: code portability
- Previous by thread: Re: Ternary operator and memory access
- Next by thread: Re: Ternary operator and memory access
- Index(es):
Relevant Pages
|
