>> You mentioned Montgomery BN. > > Here are how the instructions work. > > The basic model is that there is a range of sizes supported by the > instruction, and all of the data is loaded into a combination of > the floating point registers and all of the register windows of > the cpu.
Ouch! > ... > > save > > ... > > restore > ... > > Of course, you might quickly ask what happens in 32-bit mode? No, before thinking about 32-bit mode, I quickly ask what's with save-s without arguments? I quickly ask what happens if context switch strikes in the middle? save without argument means that %sp will be effectively uninitialized and attempts to refer stack [during context switch or asynchronous signal delivery] are either doomed or corrupt stack. So save-s ought to allocate frames. But even then, [and in 64-bit mode], do instructions in question ensure that register windows are loaded prior execution? I mean consider context switch between a save and say montmul. Kernel dumps all windows on stack and when execution resumes it normally brings in only one top window and let's window trap bring in remaining ones on demand. So that before instructions in question can start actual processing, all windows has to be loaded. Presumably the instructions can trigger window trap, then kernel would have to see that it's one of the instructions that triggered it and act accordingly, i.e. bring in all the windows. Does it work that way? Or do I get it backwards? I assume that instructions in question are uninterruptible, so that trap can be generated only prior calculation... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
