Hello Keld, Thanks a lot for the detailed insite. Very helpful.
Many thanks Ole Keld Laursen <[EMAIL PROTECTED]> schrieb in im Newsbeitrag: [EMAIL PROTECTED] > > "Ole Grossklaus" <[EMAIL PROTECTED]> skrev i en meddelelse > news:[EMAIL PROTECTED] > > Anybody who can explain the process of compiling? Are the functions > compiled > > in sequencial order of the source file or in the order of their usage (or > > completely different). > > Anybody who knows the inside of this compiler/assembler/linker can you > > please try explaining the logic that runs behind this compilation process? > > Maybe this can help me understanding better what to change. Thanks a lot. > > Compiling, e.g. C or Pascal compiling is mostly single-pass. The compiler > starts at the top of your first file and walks trough it and comes out the > bottom. > If it find any variables during this, they get assigned a memory location. > All functions and inherent labels within the code (jump and loop labels) are > labelled and written to the resulting assembler file. At the end, you have a > fairly good approximation of your code, just in assembler. The reason that I > say a fairly good approximation is that the compiler might have done some > optimisation of the code. If you turn off all optimisations, you should be > able to find a 1:1 match between your original code and the assembler code. > Note that some of the inherent labels can be forward declarations and some > can be deferred declarations. > > Because of the deferred label declarations in the code, you put the > resulting assembler code trough a 2-pass assembler. This assembler again > starts at the top of your code and converts all mnemonics to op-codes and > again notes all the label positions. Labels that havent been defined when > used are temporarily set to point to address 0. When it reaches the end of > the code, the assembler returns to the start of the file and walks trough > the code once more to exchange the temporary assignments with the real ones. > Some optimising assemblers might use a third run to fix up on > relative/absolute branches when the code is correctly in place. Normally, > though, the compilers force the assembler to use the larges possible branch > distance for the op-code in question, e.g. a 8051 compiler/assembler can > jump relatively +/- 127 bytes, absolute to a position within a 4K code > segment and absolute to the whole code (64K in this example). The compiler > can in this example either use the "jmp" instruction, or force the assembler > by using the variants "sjmp", "ajmp" or "ljmp". Most compilers I've met > always inserts "ljmp"s. > > If the code is split up in several modules, the compiler/assembler creates a > special list of deferred declarations, which the linker is to resolve. > Together with these declarations, the linker receives info on the range of > values the declarations can take. This is to enable the linker to warn you > of too large jumps. > > Hope this helps > > Keld Laursen > > > > > -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
