> >> - do all compilation steps process the whole source file before passing to
> >> the next step? (My guess is - not, this is valid only for preprocessing,
> >> assembling and linking - the rest is called from the parser
> >> function-wise???).
> >The preprocessing and the rest of the compiling (but not the linking and
> >assembling) effectively operate in parallel. Although the preprocessor
> >runs as a separate program, its output is piped back to the main compiler
> >which parses the preprocessed results as they are generated.
Well, no, more character-wise (or preprocessor-token-wise), but this is
of no importance as it is hidden by the pipe abstraction.
> But, would there be any difference if the preprocessor would be run
> standalone, then the result as a whole fed to the rest (parser etc.)?
You can just as well write the preprocessor output into a (temporary)
file and read that one back into the compiler (the lexer actually);
pipes are just more efficient.
> I.e. is there any other information communicated between the
> preprocessor and "the rest" than just the preprocessed line itself?
Nope, preprocessing is completely separate.
> AFAI understand, "rest" shares a complete set of variables, so they
> cannot be simply split; and after the lexer/parser chews up a bit of
> code (how much - see a question below) it submits it to the following
> processing steps (as you described below), which all are accomplished
> one after other on this particular bit of code; correct?
Once the parser recognizes that a function is complete, createFunction()
(in src/SDCCast.c) is called, which has the AST annotated (probably via
decorateType()), has it turned it into iCode (iCodeFromAst() calling
ast2iCode()), and lets the backend emit appropriate code (via
eBBlockFromiCode() in port->assignRegisters, which maps to, e.g.,
> However, a question on the "processing bit": sdcc/doc/random-notes.txt
> mentions briefly "eBBlock" (basic block). Is this the "processing
> bit"? Is this equal to "function"?
A basic block is a straight-line sequence of code with no branches (and
only one entry); so if any instruction in a basic block is executed, all
instructions in this basic block are executed.
(Sometimes, multiple exits (conditional branches) from basic blocks are
allowed, resulting in extended basic blocks. These still guarantee that
if an instruction i is executed, all instructions preceding i in the eBB
are also executed. Such information is most useful for optimization
> >> What is the next step in processing of the code?
> >After each function is parsed: 1) the AST for the function is converted to
> >intermediate code, 2) processor independent optimizations are performed on
> >the intermediate code, 3) processor dependent optimizations are performed
> >on the intermediate code and register usage is determined, 4) assembly
> >code is generated from the intermediate code, and 5) the assembly code is
> >peephole optimized.
> >After reaching the end of the source file, the initializers for any
> >non-const global or static variables also go through these same steps.
> I'll upgrade the "processing steps" in wiki according to this. However,
> one more request, I know I am asking for quite a lot now: can anybody
> describe in terms of source files/functions this process?
Rough version for step 1 found above, 2 is included in
eBBlockFromiCode(): cseAllBlocks(), killDeadCode(), loopOptimizations(),
all src/SDCCopt.c. Not sure about 3, though. 4 and 5 are port-specific.