On 9 April 2012 21:20, deadalnix <deadal...@gmail.com> wrote: > Le 08/04/2012 14:02, Alex Rønne Petersen a écrit : > > On 08-04-2012 11:42, Manu wrote: >> >>> On 8 April 2012 11:56, Timon Gehr <timon.g...@gmx.ch >>> <mailto:timon.g...@gmx.ch>> wrote: >>> >>> On 04/08/2012 10:45 AM, Timon Gehr wrote: >>> >>> That actually sounds like a pretty awesome idea. >>> >>> >>> Make sure that the compiler does not actually rely on the fact that >>> the template generates a function. The design should include the >>> possibility of just generating tables. It all should be completely >>> transparent to the compiler, if that is possible. >>> >>> >>> This sounds important to me. If it is also possible to do the work with >>> generated tables, and not calling thousands of indirect functions in >>> someone's implementation, it would be nice to reserve that possibility. >>> Indirect function calls in hot loops make me very nervous for non-x86 >>> machines. >>> >> >> Yes, I agree here. The last thing we need is a huge amount of >> kinda-sorta-virtual function calls on ARM, MIPS, etc. It may work fine >> on x86, but anywhere else, it's really not what you want in a GC. >> >> > Nothing prevent the generated function to itself call other generated > functions, when things are predictable. It avoid many indirect calls, and > purely by lib, which is good (can be tuned for application/plateform). >
Eh? Not sure what you mean. The idea is the template would produce a struct/table of data instead of being a pointer to a function, this way the GC could work without calling anything. If the GC was written to assume GC info in a particular format/structure, it could be written without any calls. I'm just saying to leave that as a possibility, and not REQUIRE an indirect function call for every single allocation in the system. Some GC might be able to make better use of that sort of setup.
