Re: [Mesa3d-dev] dynamic code generation with gcc

[Josh V. <ho...@na...>]

"Stephen J Baker" <sj...@li...> writes:

> I think the problems are significant:
> 
>   1) Whilst it'll (perhaps) improve frame rates once the code
>      has been compiled, you could easily get a several-second
>      pause when you first refer to something that triggers this
>      action.  In some applications, that would be disasterous.

This doesn't seem like a big problem to me.  In most cases, you could
compile the entire pipeline in a fraction of a second.

If you had to compile something really big, I guess you could fork()
the compiler at a low priority level and use a general purpose routine
until the compile finishes.

>   2) You are depending on picking a valid compiler correctly and
>      that there is a compiler on the system at all.  There are
>      many (and growing) platforms where software-only-Mesa might
>      make sense (eg http://www.agendacomputing.com - a Linux-based
>      PDA) where no compiler exists on the target machine.

You're right about this.  I would never suggest that Mesa not function
without having a compiler available at run time.  Lots of people run
Linux without installing a compiler.

> 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.

Josh