In message <a05111b09b960bd6a030f@[63.120.19.221]> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Keys are either constant key structs, constant integers, string > registers, or integer registers. Encoding shouldn't be any different > than any other constant or register. Jeff's got an opcode function > naming scheme--I've not browsed back far enough in the discussion to > see if it's considered insufficient or not. The problem isn't really the encoding in the sense of the bytecode encoding - as you say that is no different to any other constant or register. The problem is the opcode names. I don't know where Jeff's scheme is documented, but none of the information I can find in the docs seems to provide a workable scheme for keyed ops. Given your description of the valid key types I would suggest that the key arguments be encoded in opcode names as follows: constant key struct k constant integer kic string register ks integer register ki Also, am I right in believing that when you talk about a string register being used as a key you mean that the register will be assumed to be a pointer to a KEY instead of a pointer to a string, and that this will be used to handle the case where a key has been build dynamically with the key ops? If I am right about that then it means that it is impossible to write an instruction that does a hash lookup from a string register, as this: set S1, P0[S0] Will be assumed to mean that S0 is a key. Instead you would either have to put the string into a PMC first, like this: set P1, S0 set S1, P0[P1] Which could be handled by building a constant key struct containing a single element. The other option would be to build a key dynamically and then use that to do the access. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
