On 02/02/03 Ilya Minkov wrote: > Have you considered VCODE/ICODE to become a basis for your JIT backend?
Yes. > It has been well ported to all (widespread) RISC CPUs, and there is a > half-broken x86 port. I have been intending to make a "real" x86 port x86 has 90+% of the market share, so if there is no good support for x86 it's not good enough:-) The main problem with vcode is that it has a high-level approach, but to implement efficiently many of the opcodes needed by the CLR, we need direct access to the CPU features: as an example, you may want to use vcode to implement the addition of two int64 values. How does the generated code look like on x86, ppc, sparc? How does the C code to produce it look like? What about the variant with overflow detection? > The thing to check: *licensing issues* (?), i don't know under which > condition it has been licensed. vcode is not free software, so it could not be used in mono, even if it was technically good for us. > I also think that it should be possible to attach a peephole optimiser > to VCODE. Any time a label is issued, if optimiser is enabled, it would > disassemble (simplified, extracting a minimum of information) all the > code generated since the last label, and write "tags", noting where each Ugh, maybe for RISC instruction sets it's easy and fast, but what about the x86 instruction set? It would be a complete pain to implement. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
