On Apr 10, 2008, at 11:47 AM, Dennis Cote wrote: > Michael Schlenker wrote: >> >> The old code did some stowing away of values via OP_StoreMem/ >> OP_LoadMem and >> those have been replaced by OP_Copy etc. in the register VM. So how >> many >> registers are available in the VM to push away some intermediate >> results? >> > > From the documentation at http://www.sqlite.org/opcode.html we have: > > The virtual machine contains an arbitrary number of registers > locations > with addresses beginning at one and growing upward. Each memory > location > can hold an arbitrary string. The registers hold all intermediate > results of a calculation. >
That is correct, but it is not the whole story. Registers have to be allocated. The canonical way to do this is to increment the Parse.nMem field. Or one can call sqlite3GetTempReg() or sqlite3GetTempRange(). Registers acquired this way need not be released for reuse, though of course they can be. On the other hand, anybody who is modifying the code generator (which is what Michael Schlenker appears to be doing) needs to read through the entire code generator source code base and understand at a deep level what is going on. And, such programmers need to be prepared to throw away their changes and start over when code generator implementation changes, which it does from time to time. 3.5.4->3.5.5 was a big change for the code generator. But you should know that we are not through changing it yet and more big changes could appear in future releases. The virtual machine in SQLite is not an API and we make positively zero effort to maintain backwards compatibility from one point release to the next. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
