Warp wrote:
>   Can you compile a C# program into a stand-alone executable that does not
> require a JIT compiler environment? (Well, I suppose that if the JIT
> compiler is linked into the executable, it could perhaps work.)

There's a tool called NGEN that takes the byte code file and inserts 
compiled code too. For things you install into the "global assembly 
container" (i.e., /lib basically) it runs that tool at install time.

>   But thinking about it, why is the final compilation into machine code
> delayed until the program is run? Why cannot it be done at compile time?

I would think it would be difficult to do it before link time, if only 
because of the fact that you can inherit from a superclass and then have the 
superclass recompiled out from under you. (Which is, in part, why putting 
something in the GAC requires that it be cryptographically signed yadda 
yadda, so that sort of thing doesn't happen.)  Basically, you'd need at 
least the entire assembly available. (One assembly is the smallest unit of 
compiled code you can distribute. It might be in multiple DLLs, but it 
wouldn't make sense to distribute one DLL without the other.)

Also, if you compile the code before you run it and then never throw away 
that code, you can't take advantage of precisely which chip it's running on 
(like new SSE instructions or something) and you can't do optimizations like 
cross-assembly code inlining. There's also odd stuff happening in the 
background, whereby new optimizations get pulled down of the internet or 
something weird? I don't know, I just turn all that stuff off, but 
apparently there's some really deeply funky/screwy stuff going on in that 
part of the code generation process.

(As an aside and completely irrelevant to the above points, I found it 
really cool the XNA compiler will take per-pixel or per-vertex constant 
calculations in shader code and hoist them back to the main CPU. I've never 
seen a cross-CPU loop invariant hoist before. :-)

>   AFAIK they added export templates to the standard because they confirmed
> that it can be done. They didn't predict, however, how hard it would be,
> nor that major compiler writers would just skip doing it because of that.

As I said, maybe I misunderstood it. The article was by the guys who wrote 
the first compiler that supported it. Thinking on it, it's possible what 
they were saying is they implemented draft proposals, found where that 
broke, and then reported back to the committee, who then fixed those problems.

>   Support for export templates would allow the templated code to have
> types, functions and data that are local to the compilation unit (and
> possibly shared among all the different template type instantiations)
> where the templated code is implemented. This might sound like a small
> thing, but it's actually a huge defect in templated code when the compiler
> doesn't support export templates.

Got it. So, making templates more like classes sorta? With "static" 
variables and so on?

>   (Ok, it's not completely impossible. You could make 'counter' global,
> in which case the non-export foo() instantiations could modify it. However,
> this obviously reduces modularity significantly, and grants unwanted
> access for outside code to the variable.)

Got it. Thanks for the explanation!

>   AFAIK people working in the standardization committee are trying to come
> up with a different solution to this problem which would be much easier for
> compilers to implement.

That would be good. Unfortunately, I don't think it's easy to think up a 
solution that has as much power as C++ templates (and be as easy) without 
having the sources around at compile time.

LISP has macros that are super powerful, but there really isn't a whole lot 
of static typing / overloading kind of stuff going on there.

Erlang, again, is dynamically typed. It has compiled macros that are 
basically functions which take a AST as input and return another AST as a 
result, and that's how you implement macros.

But both of these solutions require running code you just compiled before 
you finish compiling, as part of the compilation process.  Not something I 
really see happening with a language targeting the kinds of projects C tends 
to address (in terms of maximum efficiency and portability).

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message