From: Gareth H. <ga...@va...> - 2001-03-09 00:07:05
|
Josh Vanderhoof wrote: > > > I believe that when SGI do this kind of thing in their Windoze > > software-OpenGL, they were generating x86 machine code directly > > into memory without using compilers or even assemblers. That's > > a viable technique...at least for the most popular CPU types. > > That's the obvious way to approach the problem, but there are problems > there too. Say I have a routine that uses 1 more variable that there > are registers in the worst case, but usually fits in the registers. > Should the x86 generator have a register allocator? How about if some > versions of the generated code have common subexpressions? Should the > generator have a CSE pass? The generator will eventually start to > look like a bad compiler that can only generate x86 code. My approach for this is perhaps slightly different to yours. I was thinking more along the lines of having the compiled functions stored as strings, which can be copied and edited by the context as needed. This allows the context to insert hard-coded memory references and so on. Similarly, I've been kicking around a design of a dynamic software renderer, which is built from chunks of compiled code that can be tweaked and chained together depending on the current GL state etc. I don't think actually "compiling" code is the answer -- it's more a customization of pre-compiled code to suit the current context. -- Gareth |