On Mon, 2001-11-19 at 19:59, James Mastros wrote: > Hey all. > In parellel to splitting out features (yeah, I like that better then > "platforms" too) (which is going well this time, I think (I'm being a lot > better about checking against clean checkouts, but having problems > thinking of a good generic interface for open() and friends), I'm thinking > about a new packfile format. > I'm comeing across a common problem to both of them. That is, that the > sizeof things don't come in nice easy units. > In byteswapping the bytecode, it's a Very Good Thing if you can just > treat it as an array of some specifc type, so you don't have to figure out > how man args each opcode takes (this may, in fact, be impossible, if > oplibs are dynamicly loadable during the bytecode's runtime). > In the feature-splitting, for example in file opening, some interfaces > (POSIX open(), for example) want to return an integer (the fd), and some > (win32 CreateFile(), for example) want to return a void* (the file > handle). (This is a pointer to a kernel-allocated structure that will > cause a segfault to directly access, BTW, so no GC problems here.) > > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed > to be able to hold a void*. >
Seems reasonable to me, since jsr and jump are slated to use an I register to jump to a host-machine-address and start interpreting there. Brian
