[LLVMdev] me being stupid: me vs the llvm codebase...

[BGB]

well, as it so seems I need to bother everyone on the list with my pointless 
newb crap, but here goes.

maybe there was a FAQ for all this, but I missed it.

well, I am not trying to demean LLVM in any way here, only trying to 
understand and evaluate things from my POV is all...

sorry if at all I seem arrogant or condescending...


well, running a linecounter, it is about 223 kloc (c++ ...), + 72 kloc 
headers.

this is decently large. my compiler, in comparrision, is only about 62 kloc 
thus far, but I have about 300 kloc of 3D code in my main project, so ok, it 
balances I guess...

ok, I also currently only do x86 (at present this is all I really need for 
my uses...).


skimming, it does not look like LLVM uses its own assembler or linker?... 
(or at least, I can't seem to find anything looking like one in the codebase 
anywhere).

I am assuming then that some external assembler is used (such as 'gas')?...


actually, I don't really understand the code so well. I am a C-head (almost 
never using C++), and have very different organization and structuring 
practices (I learned much of my coding practice from things like the quake 
source and linux kernel, and I got into compilers and interpreters initially 
by at one point skimming over the guile source...), so it is hard to figure 
out just how the parts go together and how things work...


internally, the compilers look *VERY* different (I am right now doubting 
there is much of anything similar...).


looks like it is more intended to work as a static compiler, or for digging 
around in the compiler machinery?...

it looks like much of the interconnection and data sharing is done through 
objects and templates?...

(I usually gain modularity by use of abstraction, for example, several of 
the major components work by moving the data between the compiler stages 
serialized as large chunks of ascii text. as a result, some of my APIs end 
up looking more than a little like printf...)


doesn't appear much like working like a dynamic compiler is a major design 
goal (so I hear, it can be used this way, but this is not the focus).

so, it looks like the design focuses mostly of taking the input modules, 
grinding it and mixing it, and doing lots of spify inter-module 
optimizations (presumably forming a monolithic output representing the 
entire project?...).

very different...


mine is very different, I produce masses of object-modules (in the more 
traditional sense), which are linked at runtime, and kept in an in-memory 
largely but not completely linked form. dynamic relinking is a design goal 
in my case, so it is good to be able to unlink a module from the running 
image and/or relink a new module in its place (hopefully, if possible, 
without crashing the app in the process).

as a result, my compiler generally refrains from inlining things or doing 
brittle inter-function optimizations (after all, one could potentially 
relink parts of the image and break things...).

like, basically, I mostly wanted to be able to tweak out C code in much the 
same way as is possible with LISP (going beyond the confines of what is 
possible with compilers like gcc, or with existing interpreter-based 
scripting VMs, while trying to preserve both the speed and capability of a 
true compiler, with the flexibility and dynamic changability of a typical 
interpreter-based VM...).


so, basic question:
how well would LLVM work for being used in a manner comprable to LISP-style 
eval (or Self, Smalltalk, or Python style incremental restructuring)?...
and incrementally replacing functions or modules at runtime?...

or is the intention more like "compile once and use"?...
would this likely imply redoing much of the compilation process for each 
incremental change?...

or am I missing something major here?...


as a result, the assembler and the linker form the core around which nearly 
my entire compiler framework is built (the assembler and linker core form 
the base platform, and the upper and lower compilers allow me to use it with 
something other than assembly and object files...).

the lower compiler (RIL to ASM, 16.4 kloc) was originally intended to be a 
replacable component, but ended up being a little larger and more 
complicated than was hoped (so I fudged it, and largely implemented both x86 
and x86-64 support in the same version). it may be eventually split into an 
upper-lower and lower-lower portions (upper-lower managing mostly the 
abstract machine and type mechanics, and lower-lower handling the codegen).

the upper compiler (C to RIL), is similarly intended as replacable (an 
'Embedded C++' frontend, for example, would likely exist by simply replacing 
the whole frontend...). actually, for technical reasons, I may eventually 
replace it anyways. the current upper-compiler was just sort of 
hacked-together mostly from pre-existing code I had laying around (mostly, 
it was derived from the compiler from the immediate predecessor, which was 
an interpreted, and later JIT-compiled scripting language...).


so, my thought:
the projects seem sufficiently different, that it seems to me thus far that 
about the only real similarity is that both are compilers...

the goals are just doubtful the same as my goals is all...


still, I will encourage the developers for this project to keep up the good 
work.
this is still an interesting project, in any case.

or such...