+mov dph,#0x00
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+mov sp,_bp
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+pop _bp
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ret
+\newline
+
+\newline
+
+\family default
+The compiling and linking procedure remains the same, however note the extra
+ entry & exit linkage required for the assembler code, _bp is the stack
+ frame pointer and is used to compute the offset into the stack for parameters
+ and local variables.
+\layout Subsection
+
+External Stack
+\layout Standard
+
+The external stack is located at the start of the external ram segment,
+ and is 256 bytes in size.
+ When ---xstack option is used to compile the program, the parameters and
+ local variables of all reentrant functions are allocated in this area.
+ This option is provided for programs with large stack space requirements.
+ When used with the ---stack-auto option, all parameters and local variables
+ are allocated on the external stack (note support libraries will need to
+ be recompiled with the same options).
+\layout Standard
+
+The compiler outputs the higher order address byte of the external ram segment
+ into PORT P2, therefore when using the External Stack option, this port
+ MAY NOT be used by the application program.
+\layout Subsection
+
+ANSI-Compliance
+\layout Standard
+
+Deviations from the compliancy.
+\layout Itemize
+
+functions are not always reentrant.
+\layout Itemize
+
+structures cannot be assigned values directly, cannot be passed as function
+ parameters or assigned to each other and cannot be a return value from
+ a function, e.g.:
+\family typewriter
+
+\newline
+
+\newline
+struct s { ...
+ };
+\newline
+struct s s1, s2;
+\newline
+foo()
+\newline
+{
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+...
+
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+...
+
+\newline
+}
+\newline
+struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
+ ANSI */
+\newline
+{
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+struct s rets;
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+...
+
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+return rets;/* is invalid in SDCC although allowed in ANSI */
+\newline
+}
+\layout Itemize
+
+'long long' (64 bit integers) not supported.
+\layout Itemize
+
+'double' precision floating point not supported.
+\layout Itemize
+
+No support for setjmp and longjmp (for now).
+\layout Itemize
+
+Old K&R style function declarations are NOT allowed.
+\newline
+
+\family typewriter
+
+\newline
+foo(i,j) /* this old style of function declarations */
+\newline
+int i,j; /* are valid in ANSI but not valid in SDCC */
+\newline
+{
+\newline
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+...
+
+\newline
+}
+\layout Itemize
+
+functions declared as pointers must be dereferenced during the call.
+\newline
+
+\family typewriter
+
+\newline
+int (*foo)();
+\newline
+...
+
+\newline
+/* has to be called like this */
+\newline
+(*foo)(); /* ansi standard allows calls to be made like 'foo()' */
+\layout Subsection
+
+Cyclomatic Complexity
+\layout Standard
+
+Cyclomatic complexity of a function is defined as the number of independent
+ paths the program can take during execution of the function.
+ This is an important number since it defines the number test cases you
+ have to generate to validate the function.
+ The accepted industry standard for complexity number is 10, if the cyclomatic
+ complexity reported by SDCC exceeds 10 you should think about simplification
+ of the function logic.
+ Note that the complexity level is not related to the number of lines of
+ code in a function.
+ Large functions can have low complexity, and small functions can have large
+ complexity levels.
+
+\newline
+
+\newline
+SDCC uses the following formula to compute the complexity:
+\newline
+
+\layout Standard
+
+complexity = (number of edges in control flow graph) - (number of nodes
+ in control flow graph) + 2;
+\newline
+
+\newline
+Having said that the industry standard is 10, you should be aware that in
+ some cases it be may unavoidable to have a complexity level of less than
+ 10.
+ For example if you have switch statement with more than 10 case labels,
+ each case label adds one to the complexity level.
+ The complexity level is by no means an absolute measure of the algorithmic
+ complexity of the function, it does however provide a good starting point
+ for which functions you might look at for further optimization.
+\layout Section
+
+TIPS
+\layout Standard
+
+Here are a few guidelines that will help the compiler generate more efficient
+ code, some of the tips are specific to this compiler others are generally
+ good programming practice.
+\layout Itemize
+
+Use the smallest data type to represent your data-value.
+ If it is known in advance that the value is going to be less than 256 then
+ use an 'unsigned char' instead of a 'short' or 'int'.
+\layout Itemize
+
+Use unsigned when it is known in advance that the value is not going to
+ be negative.
+ This helps especially if you are doing division or multiplication.
+\layout Itemize
+
+NEVER jump into a LOOP.
+\layout Itemize
+
+Declare the variables to be local whenever possible, especially loop control
+ variables (induction).
+\layout Itemize
+
+Since the compiler does not always do implicit integral promotion, the programme
+r should do an explicit cast when integral promotion is required.
+\layout Itemize
+
+Reducing the size of division, multiplication & modulus operations can reduce
+ code size substantially.
+ Take the following code for example.
+\family typewriter
+
+\newline
+
+\newline
+foobar(unsigned int p1, unsigned char ch)
+\newline
+{
+\newline
+ unsigned char ch1 = p1 % ch ;
+\newline
+ ....
+
+\newline
+}
+\newline
+
+\family default
+
+\newline
+For the modulus operation the variable ch will be promoted to unsigned int
+ first then the modulus operation will be performed (this will lead to a
+ call to support routine _moduint()), and the result will be casted to a
+ char.
+ If the code is changed to
+\newline
+
+\family typewriter
+
+\newline
+foobar(unsigned int p1, unsigned char ch)
+\newline
+{
+\newline
+ unsigned char ch1 = (unsigned char)p1 % ch ;
+\newline
+ ....
+
+\newline
+}
+\newline
+
+\family default
+
+\newline
+It would substantially reduce the code generated (future versions of the
+ compiler will be smart enough to detect such optimization oppurtunities).
+\layout Subsection
+
+Notes on MCS51 memory layout
+\layout Standard
+
+The 8051 family of micro controller have a minimum of 128 bytes of internal
+ memory which is structured as follows
+\newline
+
+\newline
+- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
+
+\newline
+- Bytes 20-2F - 16 bytes to hold 128 bit variables and
+\newline
+- Bytes 30-7F - 60 bytes for general purpose use.
+\newline
+
+\newline
+Normally the SDCC compiler will only utilise the first bank of registers,
+ but it is possible to specify that other banks of registers should be used
+ in interrupt routines.
+ By default, the compiler will place the stack after the last bank of used
+ registers, i.e.
+ if the first 2 banks of registers are used, it will position the base of
+ the internal stack at address 16 (0X10).
+ This implies that as the stack grows, it will use up the remaining register
+ banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
+ general purpose use.
+\layout Standard
+
+By default, the compiler uses the 60 general purpose bytes to hold "near
+ data".
+ The compiler/optimiser may also declare some Local Variables in this area
+ to hold local data.
+
+\layout Standard
+
+If any of the 128 bit variables are used, or near data is being used then
+ care needs to be taken to ensure that the stack does not grow so much that
+ it starts to over write either your bit variables or "near data".
+ There is no runtime checking to prevent this from happening.
+\layout Standard
+
+The amount of stack being used is affected by the use of the "internal stack"
+ to save registers before a subroutine call is made (---stack-auto will
+ declare parameters and local variables on the stack) and the number of
+ nested subroutines.
+\layout Standard
+
+If you detect that the stack is over writing you data, then the following
+ can be done.
+ ---xstack will cause an external stack to be used for saving registers
+ and (if ---stack-auto is being used) storing parameters and local variables.
+ However this will produce more code which will be slower to execute.
+
+\layout Standard
+
+---stack-loc will allow you specify the start of the stack, i.e.
+ you could start it after any data in the general purpose area.
+ However this may waste the memory not used by the register banks and if
+ the size of the "near data" increases, it may creep into the bottom of
+ the stack.
+\layout Standard
+
+---stack-after-data, similar to the ---stack-loc, but it automatically places
+ the stack after the end of the "near data".
+ Again this could waste any spare register space.
+\layout Standard
+
+---data-loc allows you to specify the start address of the near data.
+ This could be used to move the "near data" further away from the stack
+ giving it more room to grow.
+ This will only work if no bit variables are being used and the stack can
+ grow to use the bit variable space.
+\newline
+
+\newline
+Conclusion.
+\newline
+
+\newline
+If you find that the stack is over writing your bit variables or "near data"
+ then the approach which best utilised the internal memory is to position
+ the "near data" after the last bank of used registers or, if you use bit
+ variables, after the last bit variable by using the ---data-loc, e.g.
+ if two register banks are being used and no bit variables, ---data-loc
+ 16, and use the ---stack-after-data option.
+\layout Standard
+
+If bit variables are being used, another method would be to try and squeeze
+ the data area in the unused register banks if it will fit, and start the
+ stack after the last bit variable.
+\layout Section
+
+Retargetting for other MCUs.
+\layout Standard
+
+The issues for retargetting the compiler are far too numerous to be covered
+ by this document.
+ What follows is a brief description of each of the seven phases of the
+ compiler and its MCU dependency.
+\layout Itemize
+
+Parsing the source and building the annotated parse tree.
+ This phase is largely MCU independent (except for the language extensions).
+ Syntax & semantic checks are also done in this phase, along with some initial
+ optimizations like back patching labels and the pattern matching optimizations
+ like bit-rotation etc.
+\layout Itemize
+
+The second phase involves generating an intermediate code which can be easy
+ manipulated during the later phases.
+ This phase is entirely MCU independent.
+ The intermediate code generation assumes the target machine has unlimited
+ number of registers, and designates them with the name iTemp.
+ The compiler can be made to dump a human readable form of the code generated
+ by using the ---dumpraw option.
+\layout Itemize
+
+This phase does the bulk of the standard optimizations and is also MCU independe
+nt.
+ This phase can be broken down into several sub-phases:
+\newline
+
+\newline
+Break down intermediate code (iCode) into basic blocks.
+\newline
+Do control flow & data flow analysis on the basic blocks.
+\newline
+Do local common subexpression elimination, then global subexpression elimination
+\newline
+Dead code elimination
+\newline
+Loop optimizations
+\newline
+If loop optimizations caused any changes then do 'global subexpression eliminati
+on' and 'dead code elimination' again.
+\layout Itemize
+
+This phase determines the live-ranges; by live range I mean those iTemp
+ variables defined by the compiler that still survive after all the optimization
+s.
+ Live range analysis is essential for register allocation, since these computati
+on determines which of these iTemps will be assigned to registers, and for
+ how long.
+\layout Itemize
+
+Phase five is register allocation.
+ There are two parts to this process.
+\newline
+
+\newline
+The first part I call 'register packing' (for lack of a better term).
+ In this case several MCU specific expression folding is done to reduce
+ register pressure.
+\newline
+
+\newline
+The second part is more MCU independent and deals with allocating registers
+ to the remaining live ranges.
+ A lot of MCU specific code does creep into this phase because of the limited
+ number of index registers available in the 8051.
+\layout Itemize
+
+The Code generation phase is (unhappily), entirely MCU dependent and very
+ little (if any at all) of this code can be reused for other MCU.
+ However the scheme for allocating a homogenized assembler operand for each
+ iCode operand may be reused.
+\layout Itemize
+
+As mentioned in the optimization section the peep-hole optimizer is rule
+ based system, which can reprogrammed for other MCUs.
+\layout Section
+
+SDCDB - Source Level Debugger
+\layout Standard
+
+SDCC is distributed with a source level debugger.
+ The debugger uses a command line interface, the command repertoire of the
+ debugger has been kept as close to gdb (the GNU debugger) as possible.
+ The configuration and build process is part of the standard compiler installati
+on, which also builds and installs the debugger in the target directory
+ specified during configuration.
+ The debugger allows you debug BOTH at the C source and at the ASM source
+ level.
+\layout Subsection
+
+Compiling for Debugging
+\layout Standard
+
+The \SpecialChar \-
+\SpecialChar \-
+debug option must be specified for all files for which debug information
+ is to be generated.
+ The complier generates a .cdb file for each of these files.
+ The linker updates the .cdb file with the address information.
+ This .cdb is used by the debugger.
+\layout Subsection
+
+How the Debugger Works
+\layout Standard
+
+When the ---debug option is specified the compiler generates extra symbol
+ information some of which are put into the the assembler source and some
+ are put into the .cdb file, the linker updates the .cdb file with the address
+ information for the symbols.
+ The debugger reads the symbolic information generated by the compiler &
+ the address information generated by the linker.
+ It uses the SIMULATOR (Daniel's S51) to execute the program, the program
+ execution is controlled by the debugger.
+ When a command is issued for the debugger, it translates it into appropriate
+ commands for the simulator.
+\layout Subsection
+
+Starting the Debugger
+\layout Standard
+
+The debugger can be started using the following command line.
+ (Assume the file you are debugging has the file name foo).
+\newline
+
+\newline
+
+\family sans
+\series bold
+sdcdb foo
+\newline
+
+\family default
+\series default
+
+\newline
+The debugger will look for the following files.
+\layout Itemize
+
+foo.c - the source file.
+\layout Itemize
+
+foo.cdb - the debugger symbol information file.
+\layout Itemize
+
+foo.ihx - the intel hex format object file.
+\layout Subsection
+
+Command Line Options.
+\layout Itemize
+
+---directory=<source file directory> this option can used to specify the
+ directory search list.
+ The debugger will look into the directory list specified for source, cdb
+ & ihx files.
+ The items in the directory list must be separated by ':', e.g.
+ if the source files can be in the directories /home/src1 and /home/src2,
+ the ---directory option should be ---directory=/home/src1:/home/src2.
+ Note there can be no spaces in the option.
+
+\layout Itemize
+
+-cd <directory> - change to the <directory>.
+\layout Itemize
+
+-fullname - used by GUI front ends.
+\layout Itemize
+
+-cpu <cpu-type> - this argument is passed to the simulator please see the
+ simulator docs for details.
+\layout Itemize
+
+-X <Clock frequency > this options is passed to the simulator please see
+ the simulator docs for details.
+\layout Itemize
+
+-s <serial port file> passed to simulator see the simulator docs for details.
+\layout Itemize
+
+-S <serial in,out> passed to simulator see the simulator docs for details.
+\layout Subsection
+
+Debugger Commands.
+\layout Standard
+
+As mention earlier the command interface for the debugger has been deliberately
+ kept as close the GNU debugger gdb, as possible.
+ This will help the integration with existing graphical user interfaces
+ (like ddd, xxgdb or xemacs) existing for the GNU debugger.
+\layout Subsubsection
+
+break [line | file:line | function | file:function]
+\layout Standard
+
+Set breakpoint at specified line or function:
+\newline
+
+\newline
+
+\family sans
+\series bold
+sdcdb>break 100
+\newline
+sdcdb>break foo.c:100
+\newline
+sdcdb>break funcfoo
+\newline
+sdcdb>break foo.c:funcfoo
+\layout Subsubsection
+
+clear [line | file:line | function | file:function ]
+\layout Standard
+
+Clear breakpoint at specified line or function:
+\newline
+
+\newline
+
+\family sans
+\series bold
+sdcdb>clear 100
+\newline
+sdcdb>clear foo.c:100
+\newline
+sdcdb>clear funcfoo
+\newline
+sdcdb>clear foo.c:funcfoo
+\layout Subsubsection
+
+continue
+\layout Standard
+
+Continue program being debugged, after breakpoint.
+\layout Subsubsection
+
+finish
+\layout Standard
+
+Execute till the end of the current function.
+\layout Subsubsection
+
+delete [n]
+\layout Standard
+
+Delete breakpoint number 'n'.
+ If used without any option clear ALL user defined break points.
+\layout Subsubsection
+
+info [break | stack | frame | registers ]
+\layout Itemize
+
+info break - list all breakpoints
+\layout Itemize
+
+info stack - show the function call stack.
+\layout Itemize
+
+info frame - show information about the current execution frame.
+\layout Itemize
+
+info registers - show content of all registers.
+\layout Subsubsection
+
+step
+\layout Standard
+
+Step program until it reaches a different source line.
+\layout Subsubsection
+
+next
+\layout Standard
+
+Step program, proceeding through subroutine calls.
+\layout Subsubsection
+
+run
+\layout Standard
+
+Start debugged program.
+\layout Subsubsection
+
+ptype variable
+\layout Standard
+
+Print type information of the variable.
+\layout Subsubsection
+
+print variable
+\layout Standard
+
+print value of variable.
+\layout Subsubsection
+
+file filename
+\layout Standard
+
+load the given file name.
+ Note this is an alternate method of loading file for debugging.
+\layout Subsubsection
+
+frame
+\layout Standard
+
+print information about current frame.
+\layout Subsubsection
+
+set srcmode
+\layout Standard
+
+Toggle between C source & assembly source.
+\layout Subsubsection
+
+! simulator command
+\layout Standard
+
+Send the string following '!' to the simulator, the simulator response is
+ displayed.
+ Note the debugger does not interpret the command being sent to the simulator,
+ so if a command like 'go' is sent the debugger can loose its execution
+ context and may display incorrect values.
+\layout Subsubsection
+
+quit.
+\layout Standard
+
+"Watch me now.
+ Iam going Down.
+ My name is Bobby Brown"
+\layout Subsection
+
+Interfacing with XEmacs.
+\layout Standard
+
+Two files (in emacs lisp) are provided for the interfacing with XEmacs,
+ sdcdb.el and sdcdbsrc.el.
+ These two files can be found in the $(prefix)/bin directory after the installat
+ion is complete.
+ These files need to be loaded into XEmacs for the interface to work.
+ This can be done at XEmacs startup time by inserting the following into
+ your '.xemacs' file (which can be found in your HOME directory):
+\newline
+
+\newline
+
+\family typewriter
+(load-file sdcdbsrc.el)
+\family default
+
+\newline
+
+\newline
+.xemacs is a lisp file so the () around the command is REQUIRED.
+ The files can also be loaded dynamically while XEmacs is running, set the
+ environment variable 'EMACSLOADPATH' to the installation bin directory
+ (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
+ To start the interface enter the following command:
+\newline
+
+\newline
+
+\family sans
+\series bold
+ESC-x sdcdbsrc
+\family default
+\series default
+
+\newline
+
+\newline
+You will prompted to enter the file name to be debugged.
+
+\newline
+
+\newline
+The command line options that are passed to the simulator directly are bound
+ to default values in the file sdcdbsrc.el.
+ The variables are listed below, these values maybe changed as required.
+\layout Itemize
+
+sdcdbsrc-cpu-type '51
+\layout Itemize
+
+sdcdbsrc-frequency '11059200
+\layout Itemize
+
+sdcdbsrc-serial nil
+\layout Standard
+
+The following is a list of key mapping for the debugger interface.
+\layout Standard
+
+\SpecialChar ~
+
+\family typewriter
+
+\newline
+;; Current Listing ::
+\newline
+;;key\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+binding\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+Comment
+\newline
+;;---\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+------\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+--------
+\newline
+;;
+\newline
+;; n\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-next-from-src\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB next command
+\newline
+;; b\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-back-from-src\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB back command
+\newline
+;; c\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-cont-from-src\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB continue command
+\newline
+;; s\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-step-from-src\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB step command
+\newline
+;; ?\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-whatis-c-sexp\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB ptypecommand for data at
+\newline
+;;\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ buffer point
+\newline
+;; x\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-delete\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB Delete all breakpoints if no arg
+\newline
+;;\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+given or delete arg (C-u arg x)
+\newline
+;; m\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-frame\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB Display current frame if no arg,
+\newline
+;;\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+given or display frame arg
+\newline
+;;\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+buffer point
+\newline
+;; !\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-goto-sdcdb\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+Goto the SDCDB output buffer
+\newline
+;; p\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-print-c-sexp\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB print command for data at
+\newline
+;;\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ buffer point
+\newline
+;; g\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-goto-sdcdb\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+Goto the SDCDB output buffer
+\newline
+;; t\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-mode\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+Toggles Sdcdbsrc mode (turns it off)
+\newline
+;;
+\newline
+;; C-c C-f\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-finish-from-src\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+SDCDB finish command
+\newline
+;;
+\newline
+;; C-x SPC\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdb-break\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+Set break for line with point
+\newline
+;; ESC t\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-mode\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+Toggle Sdcdbsrc mode
+\newline
+;; ESC m\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ sdcdbsrc-srcmode\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+ Toggle list mode
+\newline
+;;
+\family default
+
+\newline
+
+\layout Section
+
+Other Processors
+\layout Subsection
+
+The Z80 and gbz80 port
+\layout Standard
+
+SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
+ The port is incomplete - long support is incomplete (mul, div and mod are
+ unimplimented), and both float and bitfield support is missing.
+ Apart from that the code generated is correct.
+\layout Standard
+
+As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
+ The stack frame is similar to that generated by the IAR Z80 compiler.
+ IX is used as the base pointer, HL is used as a temporary register, and
+ BC and DE are available for holding varibles.
+ IY is currently unusued.
+ Return values are stored in HL.
+ One bad side effect of using IX as the base pointer is that a functions
+ stack frame is limited to 127 bytes - this will be fixed in a later version.
+\layout Section
+
+Support
+\layout Standard
+
+SDCC has grown to be a large project.
+ The compiler alone (without the preprocessor, assembler and linker) is
+ about 40,000 lines of code (blank stripped).
+ The open source nature of this project is a key to its continued growth
+ and support.
+ You gain the benefit and support of many active software developers and
+ end users.
+ Is SDCC perfect? No, that's why we need your help.
+ The developers take pride in fixing reported bugs.
+ You can help by reporting the bugs and helping other SDCC users.
+ There are lots of ways to contribute, and we encourage you to take part
+ in making SDCC a great software package.
+\layout Subsection
+
+Reporting Bugs
+\layout Standard
+
+Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
+cc@sdcc.sourceforge.net'.
+ Bugs will be fixed ASAP.
+ When reporting a bug, it is very useful to include a small test program
+ which reproduces the problem.
+ If you can isolate the problem by looking at the generated assembly code,
+ this can be very helpful.
+ Compiling your program with the ---dumpall option can sometimes be useful
+ in locating optimization problems.
+\layout Section
+
+Compiler internals
+\layout Subsection
+
+The anatomy of the compiler
+\layout Standard
+
+
+\shape italic
+This is an excerpt from an atricle published in Circuit Cellar MagaZine
+ in august 2000.
+ It's a little outdated (the compiler is much more efficient now and user/devell
+oper friendly), but pretty well exposes the guts of it all.
+\shape default
+
+\newline
+
+\newline
+The current version of SDCC can generate code for Intel 8051 and Z80 MCU.
+ It is fairly easy to retarget for other 8-bit MCU.
+ Here we take a look at some of the internals of the compiler.
+
+\layout Paragraph*
+
+Parsing
+\layout Standard
+
+Parsing the input source file and creating an AST (Annotated Syntax Tree).
+ This phase also involves propagating types (annotating each node of the
+ parse tree with type information) and semantic analysis.
+ There are some MCU specific parsing rules.
+ For example the storage classes, the extended storage classes are MCU specific
+ while there may be a xdata storage class for 8051 there is no such storage
+ class for z80 or Atmel AVR.
+ SDCC allows MCU specific storage class extensions, i.e.
+ xdata will be treated as a storage class specifier when parsing 8051 C
+ code but will be treated as a C identifier when parsing z80 or ATMEL AVR
+ C code.
+\layout Paragraph*
+
+Generating iCode
+\layout Standard
+
+Intermediate code generation.
+ In this phase the AST is broken down into three-operand form (iCode).
+ These three operand forms are represented as doubly linked lists.
+ ICode is the term given to the intermediate form generated by the compiler.
+ ICode example section shows some examples of iCode generated for some simple
+ C source functions.
+\layout Paragraph*
+
+Optimizations.
+\layout Standard
+
+Bulk of the target independent optimizations is performed in this phase.
+ The optimizations include constant propagation, common sub-expression eliminati
+on, loop invariant code movement, strength reduction of loop induction variables
+ and dead-code elimination.
+\layout Paragraph*
+
+Live range analysis
+\layout Standard
+
+During intermediate code generation phase, the compiler assumes the target
+ machine has infinite number of registers and generates a lot of temporary
+ variables.
+ The live range computation determines the lifetime of each of these compiler-ge
+nerated temporaries.
+ A picture speaks a thousand words.
+ ICode example sections show the live range annotations for each of the
+ operand.
+ It is important to note here, each iCode is assigned a number in the order
+ of its execution in the function.
+ The live ranges are computed in terms of these numbers.
+ The from number is the number of the iCode which first defines the operand
+ and the to number signifies the iCode which uses this operand last.
+\layout Paragraph*
+
+Register Allocation
+\layout Standard
+
+The register allocation determines the type and number of registers needed
+ by each operand.
+ In most MCUs only a few registers can be used for indirect addressing.
+ In case of 8051 for example the registers R0 & R1 can be used to indirectly
+ address the internal ram and DPTR to indirectly address the external ram.
+ The compiler will try to allocate the appropriate register to pointer variables
+ if it can.
+ ICode example section shows the operands annotated with the registers assigned
+ to them.
+ The compiler will try to keep operands in registers as much as possible;
+ there are several schemes the compiler uses to do achieve this.
+ When the compiler runs out of registers the compiler will check to see
+ if there are any live operands which is not used or defined in the current
+ basic block being processed, if there are any found then it will push that
+ operand and use the registers in this block, the operand will then be popped
+ at the end of the basic block.
+
+\layout Standard
+
+There are other MCU specific considerations in this phase.
+ Some MCUs have an accumulator; very short-lived operands could be assigned
+ to the accumulator instead of general-purpose register.
+\layout Paragraph*
+
+Code generation
+\layout Standard
+
+Figure II gives a table of iCode operations supported by the compiler.
+ The code generation involves translating these operations into corresponding
+ assembly code for the processor.
+ This sounds overly simple but that is the essence of code generation.
+ Some of the iCode operations are generated on a MCU specific manner for
+ example, the z80 port does not use registers to pass parameters so the
+ SEND and RECV iCode operations will not be generated, and it also does
+ not support JUMPTABLES.
+
+\newline
+
+\series bold
+\shape italic
+\color red
+<Where is Figure II ?>
+\layout Paragraph*
+
+ICode Example
+\layout Standard
+
+This section shows some details of iCode.
+ The example C code does not do anything useful; it is used as an example
+ to illustrate the intermediate code generated by the compiler.
+\newline
+
+\newline
+
+\family typewriter
+1.\SpecialChar ~
+xdata int * p;
+\newline
+2.\SpecialChar ~
+int gint;
+\newline
+3.\SpecialChar ~
+/* This function does nothing useful.
+ It is used
+\newline
+4.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+for the purpose of explaining iCode */
+\newline
+5.\SpecialChar ~
+short function (data int *x)
+\newline
+6.\SpecialChar ~
+{
+\newline
+7.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+short i=10; /* dead initialization eliminated */
+\newline
+8.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+short sum=10; /* dead initialization eliminated */
+\newline
+9.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+short mul;
+\newline
+10.\SpecialChar ~
+\SpecialChar ~
+int j ;
+\newline
+11.\SpecialChar ~
+\SpecialChar ~
+while (*x) *x++ = *p++;
+\newline
+12.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+sum = 0 ;
+\newline
+13.\SpecialChar ~
+\SpecialChar ~
+mul = 0;
+\newline
+14.\SpecialChar ~
+\SpecialChar ~
+/* compiler detects i,j to be induction variables */
+\newline
+15.\SpecialChar ~
+\SpecialChar ~
+for (i = 0, j = 10 ; i < 10 ; i++, j---) {
+\newline
+16.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+sum += i;
+\newline
+17.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+mul += i * 3; /* this multiplication remains */
+\newline
+18.\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+\SpecialChar ~
+gint += j * 3;/* this multiplication changed to addition */
+\newline
+19.\SpecialChar ~
+\SpecialChar ~
+}
+\newline
+20.\SpecialChar ~
+\SpecialChar ~
+return sum+mul;
+\newline
+21.\SpecialChar ~
+}
+\newline
+
+\newline
+
+\family default
+In addition to the operands each iCode contains information about the filename
+ and line it corresponds to in the source file.
+ The first field in the listing should be interpreted as follows:
+\newline
+
+\shape italic
+\size footnotesize
+Filename(linenumber: iCode Execution sequence number : ICode hash table
+ key : loop depth of the iCode).
+\shape default
+\size default
+
+\newline
+Then follows the human readable form of the ICode operation.
+ Each operand of this triplet form can be of three basic types a) compiler
+ generated temporary b) user defined variable c) a constant value.
+ Note that local variables and parameters are replaced by compiler generated
+ temporaries.
+ Live ranges are computed only for temporaries (i.e.
+ live ranges are not computed for global variables).
+ Registers are allocated for temporaries only.
+ Operands are formatted in the following manner:
+\newline
+
+\shape italic
+\size footnotesize
+Operand Name [lr live-from : live-to ] { type information } [ registers
+ allocated ].
+\shape default
+\size default
+
+\newline
+As mentioned earlier the live ranges are computed in terms of the execution
+ sequence number of the iCodes, for example
+\newline
+the iTemp0 is live from (i.e.
+ first defined in iCode with execution sequence number 3, and is last used
+ in the iCode with sequence number 5).
+ For induction variables such as iTemp21 the live range computation extends
+ the lifetime from the start to the end of the loop.
+\newline
+The register allocator used the live range information to allocate registers,
+ the same registers may be used for different temporaries if their live
+ ranges do not overlap, for example r0 is allocated to both iTemp6 and to
+ iTemp17 since their live ranges do not overlap.
+ In addition the allocator also takes into consideration the type and usage
+ of a temporary, for example itemp6 is a pointer to near space and is used
+ as to fetch data from (i.e.
+ used in GET_VALUE_AT_ADDRESS) so it is allocated a pointer registers (r0).
+ Some short lived temporaries are allocated to special registers which have
+ meaning to the code generator e.g.
+ iTemp13 is allocated to a pseudo register CC which tells the back end that
+ the temporary is used only for a conditional jump the code generation makes
+ use of this information to optimize a compare and jump ICode.
+\newline
+There are several loop optimizations performed by the compiler.
+ It can detect induction variables iTemp21(i) and iTemp23(j).
+ Also note the compiler does selective strength reduction, i.e.
+ the multiplication of an induction variable in line 18 (gint = j * 3) is
+ changed to addition, a new temporary iTemp17 is allocated and assigned
+ a initial value, a constant 3 is then added for each iteration of the loop.
+ The compiler does not change the multiplication in line 17 however since
+ the processor does support an 8 * 8 bit multiplication.
+\newline
+Note the dead code elimination optimization eliminated the dead assignments
+ in line 7 & 8 to I and sum respectively.
+\newline
+
+\layout Standard
+
+
+\size footnotesize
+Sample.c (5:1:0:0) _entry($9) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(5:2:1:0) proc _function [lr0:0]{function short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:3:2:0) iTemp0 [lr3:5]{_near * int}[r2] = recv
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:4:53:0) preHeaderLbl0($11) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:5:55:0) iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near
+ * int}[r2]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:6:5:1) _whilecontinue_0($1) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:7:7:1) iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near *
+ int}[r0]]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:8:8:1) if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:9:14:1) iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far
+ * int}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:10:15:1) _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2
+ {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:13:18:1) iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far
+ * int}[DPTR]]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:14:19:1) *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int
+}[r2 r3]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:15:12:1) iTemp6 [lr5:16]{_near * int}[r0] = iTemp6 [lr5:16]{_near
+ * int}[r0] + 0x2 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:16:20:1) goto _whilecontinue_0($1)
+\layout Standard
+
+
+\size footnotesize
+Sample.c(11:17:21:0)_whilebreak_0($3) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(12:18:22:0) iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(13:19:23:0) iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:20:54:0)preHeaderLbl1($13) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:21:56:0) iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:22:57:0) iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:23:58:0) iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:24:26:1)_forcond_0($4) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:25:27:1) iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4]
+ < 0xa {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:26:28:1) if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
+\layout Standard
+
+
+\size footnotesize
+Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
+ + ITemp21 [lr21:38]{short}[r4]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(17:29:33:1) iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4]
+ * 0x3 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
+ + iTemp15 [lr29:30]{short}[r1]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(18:32:36:1:1) iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7
+ r0]- 0x3 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(18:33:37:1) _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{
+int}[r7 r0]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:36:42:1) iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4]
+ + 0x1 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(15:37:45:1) iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5
+ r6]- 0x1 {short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(19:38:47:1) goto _forcond_0($4)
+\layout Standard
+
+
+\size footnotesize
+Sample.c(19:39:48:0)_forbreak_0($7) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
+ + ITemp11 [lr19:40]{short}[r3]
+\layout Standard
+
+
+\size footnotesize
+Sample.c(20:41:50:0) ret iTemp24 [lr40:41]{short}
+\layout Standard
+
+
+\size footnotesize
+Sample.c(20:42:51:0)_return($8) :
+\layout Standard
+
+
+\size footnotesize
+Sample.c(20:43:52:0) eproc _function [lr0:0]{ ia0 re0 rm0}{function short}
+\size default
+
+\newline
+
+\newline
+Finally the code generated for this function:
+\newline
+
+\layout Standard
+
+
+\size footnotesize
+.area DSEG (DATA)
+\layout Standard
+
+
+\size footnotesize
+_p::
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
+\SpecialChar ~
+.ds 2
+\layout Standard
+
+
+\size footnotesize
+_gint::
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
+\SpecialChar ~
+.ds 2
+\layout Standard
+
+
+\size footnotesize
+; sample.c 5
+\layout Standard
+
+
+\size footnotesize
+; ----------------------------------------------
+\layout Standard
+
+
+\size footnotesize
+; function function
+\layout Standard
+
+
+\size footnotesize
+; ----------------------------------------------
+\layout Standard
+
+
+\size footnotesize
+_function:
+\layout Standard
+
+
+\size footnotesize
+; iTemp0 [lr3:5]{_near * int}[r2] = recv
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
+\SpecialChar ~
+mov r2,dpl
+\layout Standard
+
+
+\size footnotesize
+; iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near * int}[r2]
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
+\SpecialChar ~
+mov ar0,r2
+\layout Standard
+
+
+\size footnotesize
+;_whilecontinue_0($1) :
+\layout Standard
+
+
+\size footnotesize
+00101$:
+\layout Standard
+
+
+\size footnotesize
+; iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near * int}[r0]]
+\layout Standard
+
+
+\size footnotesize
+; if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
+\SpecialChar ~
+mov ar2,@r0
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
+\SpecialChar ~
+inc r0
+\layout Standard
+
+
+\size footnotesize
+\SpecialChar ~
projects / fw / sdcc / blobdiff