From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3DD35C73.8090404@null.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: <51251da60e579ed6058e741fa0dbff7b@plan9.bell-labs.com> Subject: Re: [9fans] how to avoid a memset() optimization Date: Thu, 14 Nov 2002 10:22:07 +0000 Topicbox-Message-UUID: 1e96b31e-eacb-11e9-9e20-41e7f4b1d025 Russ Cox wrote: > This is a stupid argument anyway. Volatile is a crock. > Here's another problem. Suppose I'm worried that > leaking the processor flags at the end of my computation > might reveal something about the secret key. I want to > clear them. I could do something like: > x = 0 & 0; > which in this particular case will clear the appropriate > flags. But now the compiler comes along and optimizes > away the whole expression. Where do I put my volatile > to make that stay? Hmm? The answer is not more crappy > qualifiers. The answer is clearly dumber compilers. Do you really want the compiler to always generate code MOV R1,#0 MOV R2,#0 AND R2,R1 MOV R2,X(SP) ? Almost any modern compiler will peform the AND at compiler time (constant folding), and most customers want that. Anyway, I don't see why you need to AND in this context. Are you talking about the C and V bits? If some other process can inspect those for your process I'd think it could inspect a whole lot more.. It is certainly true that we could really use better access to the C bit from higher-level language source code. This shows up especially in the MP library. But exploiting too specific knowledge about the workings of a specific platform can be dangerous, as we've seen historically. If anybody can devise a *nice* way to get at the C bit in MP coding, please let me know so that it can be proposed for C0x.