[Mono-dev] Re: [Mono-list] Silly question (for documentation)

[Jonathan Pryor]

On Mon, 2006-03-06 at 03:53 -0600, Zac Bowling wrote:
> This is a silly question. Does anyone know of a good term or really 
> good short name that sums up the difference between a compiler that 
> uses reflection.emit like mcs does and one that uses a traditional 
> object compile, link, and execute method like DotGnu's or Microsoft's 
> C# compilers do?

I think there is less difference than you think there is.

First of all, "object compile, link, and execute" best describes GCC and
CL.EXE, compilers which actually have intermediate object code and a
linker (ld and LD.EXE, iirc) to link the object files together.

CSC.EXE doesn't do this -- it's the same as mcs, in that it takes
all .cs files at once and produces a .dll, .exe, or .netmodule file.
There are no intermediate object files.  CSC.EXE doesn't use
System.Reflection.Emit, choosing instead to use its own internal
mechanism (probably because CSC.EXE predates System.Reflection.Emit),
but that's not something that's really visible to us mere users.

I can't speak to DotGnu's C# compiler, but I imagine it also has a "take
all .cs files and produce an assembly from them" mode as well; having
separate object files is frequently considered to be annoying (since you
can have .o files which are out of sync with each other).  The only
advantage to object files is faster compiling (less code to parse &
compile), but mcs is already really fast...

So I don't think focusing on a SRE vs. "object compile, link, execute"
model makes sense.  It's more a difference between using SRE and an
internal IL generation mechanism, in which case this could be further
distinguished between SRE, PEAPI, Mono.Cecil, custom code, or some other
mechanism (generate IL directly and call ilasm?).  But these are all
differences in how the compiler is implemented, and don't impact how the
programmer uses the compiler at all.

 - Jon