the mini jit also abstracts both front and backend, it could be entirely possible to make the mono jit execute pike internal opcodes.
Aha, that's what I missed. Then it's suddenly a whole lot simpler. How would it work integration-wise? Would we have to rip out a lot of source from CIL, or is it some kind of yacc-like tool which eats a VM/opcode spec and spits out a custom VM?
question: wouldn't it safe some memory if the internal struct{}'s were packed and alinged? gcc does this with __attribute(pack) or so.
They are aligned by default. That's the idea at least. Packing them would perhaps save a bit of memory but at the expense of cpu cycles, and memory is typically a less precious resource than cpu time.
In many places the order and sizes are chosen specifically to get both packing and alignment. E.g. in the svalue struct:
struct svalue { unsigned INT16 type; unsigned INT16 subtype; union anything u; };
On a typical 32 bit architecture this takes two 4-byte words: type and subtype shares the first and the other holds the union (which is an integer, float or a pointer to something). If the compiler doesn't pack this by default it probably has a good reason for it.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-17 22:40: Subject: Re: pike and CIL/mono (was Re: source encryption)
well, looking at the pike interpreter code and the new mono jitter called mini, i discover lots of similarities, but the code in mini is _lots_ cleaner, and both seem to follow similar concepts.
the mini jit also abstracts both front and backend, it could be entirely possible to make the mono jit execute pike internal opcodes.
(but i know nothing about interpreters/compilers :-)
question: wouldn't it safe some memory if the internal struct{}'s were packed and alinged? gcc does this with __attribute(pack) or so.
/ karl
/ Brevbäraren