X-Git-Url: https://git.gag.com/?a=blobdiff_plain;f=doc%2FSDCCUdoc.html;h=9d225cecd02a12ab72d5490e5c5da5652f3b49f8;hb=7c4864abd20761f654c879b34752687088d20b18;hp=17638654f44ad05547d455162e7ffa9dfb0ed8e6;hpb=70340b617d95cf9422675947ad299226747eb1ef;p=fw%2Fsdcc diff --git a/doc/SDCCUdoc.html b/doc/SDCCUdoc.html index 17638654..9d225cec 100644 --- a/doc/SDCCUdoc.html +++ b/doc/SDCCUdoc.html @@ -46,138 +46,140 @@ Contents
@@ -276,7 +278,7 @@ place to find distribution sets. You can also find links to the user mailing lists that offer help or discuss SDCC with other SDCC users. Web links to other SDCC related sites can also be found here. This document can be found in the DOC directory of the source package as -a text or HTML file. Some of the other tools(simulator and assembler) +a text or HTML file. Some of the other tools (simulator and assembler) included with SDCC contain their own documentation and can be found in the source distribution. If you want the latest unreleased software, the complete source package is available directly by anonymous CVS @@ -393,14 +395,14 @@ the program should run and tell you the version. If it doesn't run, or gives a message about not finding sdcc program, then you need to check over your installation. Make sure that the sdcc bin directory is in your executable search path defined by the PATH environment -setting(see the Trouble-shooting section for suggestions). Make sure +setting (see the Trouble-shooting section for suggestions). Make sure that the sdcc program is in the bin folder, if not perhaps something did not install correctly.
SDCC binaries are commonly installed in a directory arrangement like
this:
-
+
/usr/local/bin | @@ -413,17 +415,23 @@ this:Holds common C header files |
+
+
Make sure the compiler works on a very simple example. Type in the
following test.c program using your favorite editor:
+
+
main()
+
{
+
+
+int i;
-main()
-
{ int i;
-
i = 0;
-
i += 10;
-
}
+i = 0;
+
+
+i += 10;
+
}
Compile this using the following command: ``sdcc -c test.c''. @@ -435,28 +443,33 @@ code, just to keep things simple for this step.
The next step is to try it with the linker. Type in ``sdcc test.c''. If all goes well the compiler will link with the libraries and produce -a test.ihx output file. If this step fails(no test.ihx, and the linker +a test.ihx output file. If this step fails (no test.ihx, and the linker generates warnings), then the problem is most likely that sdcc cannot -find the usr/local/share/sdcc/lib/small directory(see the Install -trouble-shooting section for suggestions). +find the /usr/local/share/sdcc/lib directory (see the Install trouble-shooting +section for suggestions).
The final test is to ensure sdcc can use the standard header files
and libraries. Edit test.c and change it to the following:
+
+
#include <string.h>
+
main()
+
{
-#include <string.h>
-
main()
-
{ char str1[10];
-
strcpy(str1, ``testing'');
-
}
+char str1[10];
+
+strcpy(str1, ``testing'');
+
+
}
+
Compile this by typing: ``sdcc test.c''. This should generate a test.ihx output file, and it should give no warnings such as not finding the string.h file. If it cannot find the string.h file, then the problem is that sdcc cannot find the /usr/local/share/sdcc/include -directory(see the Install trouble-shooting section for suggestions). +directory (see the Install trouble-shooting section for suggestions).
@@ -484,17 +497,15 @@ test.c
-A few things to try include starting from scratch by unpacking the -.tgz source package again in an empty directory. If this doesn't work, -you could try downloading a different version. If this doesn't work, -you can re-direct the install messages by doing the following: +A thing to try is starting from scratch by unpacking the .tgz source +package again in an empty directory. Confure it again and build like:
-$./make > dump.txt 2>&1 +``make 2SPMamp;>1 | tee make.log''
-After this you can examine the dump.txt files to locate the problem. -Or these messages can be attached to an email that could be helpful +After this you can review the make.log file to locate the problem. +Or a relevant part of this be attached to an email that could be helpful when requesting help from the mailing list.
@@ -764,7 +775,7 @@ at <http://mazsola.iit.uni-miskolc.hu/drdani/embedded/s51/>.
-SDCDB is the companion source level debugger . The current version +SDCDB is the companion source level debugger. The current version of the debugger uses Daniel's Simulator S51, but can be easily changed to use other simulators. @@ -832,11 +843,13 @@ created by the Linker.
-
+
sdcc foomain.c foolib.lib -L mylib @@ -973,109 +987,143 @@ development, not complete).
+-lib-path(-L) <absolute path to additional libraries> This +option is passed to the linkage editor's additional libraries search +path. The path name must be absolute. Additional library files may +be specified in the command line. See section Compiling programs for +more details. + +
+-xram-loc<Value> The start location of the external ram, +default value is 0. The value entered can be in Hexadecimal or Decimal +format, e.g.: -xram-loc 0x8000 or -xram-loc 32768. +
+ +
+ +
-
@@ -1083,254 +1131,210 @@ option as well.
-
-
The following options are provided for the purpose of retargetting -and debugging the compiler . These provided a means to dump the intermediate +and debugging the compiler. These provided a means to dump the intermediate code (iCode) generated by the compiler in human readable form at various stages of the compilation process.
-When reporting bugs, it can be helpful to include these dumps along -with the portion of the code that is causing the problem. - +
@@ -1345,13 +1349,10 @@ MCS51 specific storage classes.
Variables declared with this storage class will be placed in the extern -RAM. This is the default storage class for Large Memory model -. - -
-eg. xdata unsigned char xduc; -
-
+RAM. This is the default storage class for Large Memory model,
+e.g.:
+
+
xdata unsigned char xduc;
@@ -1362,12 +1363,9 @@ RAM. This is the default storage class for Large Memory model
This is the default storage class for Small Memory model. Variables declared with this storage class will be allocated in the -internal RAM. - -
-eg. data int iramdata; -
-
+internal RAM, e.g.:
+
+
data int iramdata;
@@ -1377,12 +1375,10 @@ internal RAM.
Variables declared with this storage class will be allocated into -the indirectly addressable portion of the internal ram of a 8051 . - -
-eg.idata int idi; -
-
+the indirectly addressable portion of the internal ram of a 8051,
+e.g.:
+
+
idata int idi;
@@ -1393,10 +1389,9 @@ the indirectly addressable portion of the internal ram of a 8051 .
This is a data-type and a storage class specifier. When a variable is declared as a bit , it is allocated into the bit addressable memory -of 8051. - -
-eg.bit iFlag;
+of 8051, e.g.:
+
+
bit iFlag;
@@ -1407,17 +1402,11 @@ eg.bit iFlag;
Like the bit keyword, sfr / sbit signifies both a data-type and storage class, they are used to describe the special function -registers and special bit variables of a 8051. - -
-eg. - -
-sfr at 0x80 P0; /* SPECIAL FUNCTION REGISTER P0 AT -LOCATION 0X80 */ - -
-sbit at 0xd7 CY; /* CY (CARRY FLAG) */
+registers and special bit variables of a 8051, eg:
+
+
sfr at 0x80 P0; /* special function register P0 at location
+0x80 */
+
sbit at 0xd7 CY; /* CY (Carry Flag) */
@@ -1429,66 +1418,49 @@ LOCATION 0X80 */ SDCC allows (via language extensions) pointers to explicitly point to any of the memory spaces of the 8051. In addition to the explicit pointers, the compiler also allows a _generic class of pointers -which can be used to point to any of the memory spaces. - -
+which can be used to point to any of the memory spaces.
+
+
Pointer declaration examples.
-
-
-/* pointer physically in xternal ram pointing to object
-in internal ram */
-
data unsigned char * xdata p;
-
- - -
-/* pointer physically in code rom pointing to data in xdata
-space */
-
xdata unsigned char * code p;
+
/* pointer physically in xternal ram pointing to object
+in internal ram */
+
data unsigned char * xdata p;
+
+
/* pointer physically in code rom pointing to data in xdata
+space */
+
xdata unsigned char * code p;
+
+
/* pointer physically in code space pointing to data in
+code space */
+
code unsigned char * code p;
+
+
/* the folowing is a generic pointer physically located
+in xdata space */
+
char * xdata p;
-
- - -
-/* pointer physically in code space pointing to data in
-code space */
-
code unsigned char * code p;
-
/* the folowing is a generic pointer physically located
-in xdata space */
-
char * xdata p;
-
- - -
Well you get the idea. For compatibility with the previous version -of the compiler, the following syntax for pointer declaration is also -supported. Note the above examples will be portable to other commercially -available compilers. - -
-unsigned char _xdata *ucxdp; /* pointer to data in external
-ram */
-
unsigned char _data *ucdp ; /* pointer to data in internal
-ram */
-
unsigned char _code *uccp ; /* pointer to data in R/O
-code space */
-
unsigned char _idata *uccp; /* pointer to upper 128
-bytes of ram */
-
- - -
-All unqualified pointers are treated as 3 - byte '_generic' pointers. -These type of pointers can also to be explicitly declared. - -
-unsigned char _generic *ucgp; -
- - -
+of the compiler, the following syntax for pointer declaration is still
+supported but will disappear int the near future.
+
+
unsigned char _xdata *ucxdp; /* pointer to data in external
+ram */
+
unsigned char _data *ucdp ; /* pointer to data in internal
+ram */
+
unsigned char _code *uccp ; /* pointer to data in R/O
+code space */
+
unsigned char _idata *uccp; /* pointer to upper 128
+bytes of ram */
+
+
+All unqualified pointers are treated as 3-byte (4-byte for the ds390)
+'_generic' pointers. These type of pointers can also to be explicitly
+declared.
+
+
unsigned char _generic *ucgp;
+
+
The highest order byte of the generic pointers contains the data space
information. Assembler support routines are called whenever data is
stored or retrieved using _generic pointers. These are useful for
@@ -1508,21 +1480,14 @@ be placed on the stack or in data-space. The default action of the
compiler is to place these variables in the internal RAM ( for small
model) or external RAM (for Large model). They can be placed on the
stack either by using the -stack-auto compiler option or by
-using the 'reentrant' keyword in the function declaration.
-
-
-eg -
- - -
-unsigned short foo( short i) reentrant {
-
...
-
}
-
- - -
+using the 'reentrant' keyword in the function declaration, e.g.:
+
+
unsigned char foo( char i) reentrant
+
{
+
...
+
}
+
+
Note that when the parameters & local variables are declared in the
internal/external ram the functions are non-reentrant. Since stack
space on 8051 is limited the 'reentrant' keyword or the -stack-auto
@@ -1532,22 +1497,23 @@ it DOES NOT mean that the function is register bank independent.
When compiled with the default option (i.e. non-reentrant ), local
-variables can be assigned storage classes and absolute addresses.
+variables can be assigned storage classes and absolute addresses,
+e.g.: (jwk: pending: this is obsolete and need a rewrite)
+
+
unsigned char foo() {
-eg -
- +xdata unsigned char i;
-unsigned short foo() {
-
xdata unsigned short i;
-
bit bvar;
-
data at 0x31 unsiged short j;
-
...
-
}
+bit bvar;
+
+data at 0x31 unsiged char j; +
+...
+
}
In the above example the variable i will be allocated in the @@ -1590,66 +1556,307 @@ call other functions using inline assembler code.
Parameters and Local variables of functions that contain 16 or 32
bit multiplication or division will NOT be overlayed since these are
-implemented using external functions.
+implemented using external functions, e.g.:
+
+
#pragma SAVE
+
#pragma NOOVERLAY
+
void set_error( unsigned char errcd)
+
{
-eg.
+P3 = errcd;
+
}
+
#pragma RESTORE
+
void some_isr () interrupt 2 using 1
+
{
-#pragma SAVE
-
#pragma NOOVERLAY
-
void set_error( unsigned short errcd)
+...
+
+
+set_error(10); + +
+...
+
}
+
+
+In the above example the parameter errcd for the function set_error +would be assigned to the overlayable segment (if the #pragma NOOVERLAY +was not present) , this could cause unpredictable runtime behavior +when called from an ISR. The pragma NOOVERLAY ensures that the parameters +and local variables for the function are NOT overlayed. + +
+ +
+SDCC allows interrupt service routines to be coded in C, with some +extended keywords. + +
+void timer_isr (void) interrupt 2 using 1
{
-
P3 = errcd;
-
}
-
#pragma RESTORE
-
void some_isr () interrupt 2 using 1
+
..
+
}
+
+ + +
+The number following the 'interrupt' keyword is the interrupt number +this routine will service. The compiler will insert a call to this +routine in the interrupt vector table for the interrupt number specified. +The 'using' keyword is used to tell the compiler to use the specified +register bank (8051 specific) when generating code for this function. +Note that when some function is called from an interrupt service routine +it should be preceded by a #pragma NOOVERLAY (if it is not reentrant). +A special note here, int (16 bit) and long (32 bit) integer division, +multiplication & modulus operations are implemented using external +support routines developed in ANSI-C, if an interrupt service routine +needs to do any of these operations then the support routines (as +mentioned in a following section) will have to recompiled using the +-stack-auto option and the source file will need to be compiled using +the -int-long-rent compiler option. + +
+If you have multiple source files in your project, interrupt service +routines can be present in any of them, but a prototype of the isr +MUST be present in the file that contains the function 'main'. + +
+Interrupt Numbers and the corresponding address & descriptions for
+the Standard 8051 are listed below. SDCC will automatically adjust
+the interrupt vector table to the maximum interrupt number specified.
+
+
+
Interrupt # | +Description | +Vector Address | +
0 | +External 0 | +0x0003 | +
1 | +Timer 0 | +0x000B | +
2 | +External 1 | +0x0013 | +
3 | +Timer 1 | +0x001B | +
4 | +Serial | +0x0023 | +
+If the interrupt service routine is defined without 'using' +a register bank or with register bank 0 (using 0), the compiler will +save the registers used by itself on the stack (upon entry and restore +them at exit), however if such an interrupt service routine calls +another function then the entire register bank will be saved on the +stack. This scheme may be advantageous for small interrupt service +routines which have low register usage. + +
+If the interrupt service routine is defined to be using a specific +register bank then only ``a'',''b'' & ``dptr'' are save +and restored, if such an interrupt service routine calls another function +(using another register bank) then the entire register bank of the +called function will be saved on the stack. This scheme is recommended +for larger interrupt service routines. + +
+Calling other functions from an interrupt service routine is not recommended +avoid it if possible. + +
+ +
+A special keyword may be associated with a function declaring it as
+'critical'. SDCC will generate code to disable all interrupts
+upon entry to a critical function and enable them back before returning.
+Note that nesting critical functions may cause unpredictable results.
+
+
+eg:
+
+
int foo () critical
{
-
...
-
set_error(10);
-
...
+
...
+
...
}
+
+
+The critical attribute maybe used with other attributes like reentrant.
+
+
+ +
+A special keyword may be associated with a function declaring it as
+'_naked'. The '_naked' function modifier attribute
+prevents the compiler from generating prologue and epilogue code for
+that function. This means that the user is entirely responsible for
+such things as saving any registers that may need to be preserved,
+selecting the proper register bank, generating the 'return'
+instruction at the end, etc. Practically, this means that the contents
+of the function must be written in inline assembler. This is particularly
+useful for interrupt functions, which can have a large (and often
+unnecessary) prologue/epilogue. For example, compare the code generated
+by these two functions:
+
+
+data unsigned char counter;
+
+void simpleIterrupt(void) interrupt 1
+
{
+
+
+counter++;
+
}
+
+
+void nakedInterrupt(void) interrupt 2 _naked
+
{
+
+
+_asm + +
+ inc _counter + +
+ reti ; MUST explicitly include ret in _naked +function. + +
+_endasm;
+
}
+
+
+For an 8051 target, the generated simpleInterrupt looks like:
+
+
+_simpleIterrupt:
+
+
+push acc + +
+push b + +
+push dpl + +
+push dph + +
+push psw + +
+mov psw,#0x00 + +
+inc _counter + +
+pop psw + +
+pop dph + +
+pop dpl + +
+pop b +
+pop acc +
+reti
+
+
+whereas nakedInterrupt looks like:
+
+
+_nakedInterrupt:
-In the above example the parameter errcd for the function set_error -would be assigned to the overlayable segment (if the #pragma NOOVERLAY -was not present) , this could cause unpredictable runtime behavior. -The pragma NOOVERLAY ensures that the parameters and local variables -for the function are NOT overlayed. +inc _counter + +
+reti ; MUST explicitly include ret(i) in _naked function.
+
+
+While there is nothing preventing you from writing C code inside a
+_naked function, there are many ways to shoot yourself in the foot
+doing this, and is is recommended that you stick to inline assembler.
-
-A special keyword may be associated with a function declaring it as -'critical'. SDCC will generate code to disable all interrupts -upon entry to a critical function and enable them back before returning -. Note that nesting critical functions may cause unpredictable results. +The 'using' attribute (which tells the compiler to use a register +bank other than the default bank zero) should only be applied to 'interrupt' +functions (see note A below). This will in most circumstances make +the generated ISR code more efficient since it will not have to save +registers on the stack.
-eg
+The 'using' attribute will have no effect on the generated
+code for a non-'interrupt' function (but may occasionally be
+useful anyway1).
+
(jwk: todo: I don't think this has been done yet)
-int foo () critical
-
{
-
...
-
...
-
}
-
- +An 'interrupt' function using a non-zero bank will assume that it +can trash that register bank, and will not save it. Since high-priority +interrupts can interrupt low-priority ones on the 8051 and friends, +this means that if a high-priority ISR 'using' a particular bank occurs +while processing a low-priority ISR 'using' the same bank, terrible +and bad things can happen. To prevent this, no single register bank +should be 'used' by both a high priority and a low priority ISR. This +is probably most easily done by having all high priority ISRs use +one bank and all low priority ISRs use another. If you have an ISR +which can change priority at runtime, you're on your own: I suggest +using the default bank zero and taking the small performance hit.
-The critical attribute maybe used with other attributes like reentrant. +It is most efficient if your ISR calls no other functions. If your +ISR must call other functions, it is most efficient if those functions +use the same bank as the ISR (see note A below); the next best is +if the called functions use bank zero. It is very inefficient to call +a function using a different, non-zero bank from an ISR.
-
@@ -1699,101 +1906,8 @@ over all the variables allocated.
-
-SDCC allows interrupt service routines to be coded in C, with some -extended keywords. - -
-void timer_isr (void) interrupt 2 using 1
-
{
-
..
-
}
-
- - -
-The number following the 'interrupt' keyword is the interrupt number -this routine will service. The compiler will insert a call to this -routine in the interrupt vector table for the interrupt number specified. -The 'using' keyword is used to tell the compiler to use the specified -register bank (8051 specific) when generating code for this function. -Note that when some function is called from an interrupt service routine -it should be preceded by a #pragma NOOVERLAY (if it is not reentrant) -. A special note here, int (16 bit) and long (32 bit) integer division, -multiplication & modulus operations are implemented using external -support routines developed in ANSI-C, if an interrupt service routine -needs to do any of these operations then the support routines (as -mentioned in a following section) will have to recompiled using the --stack-auto option and the source file will need to be compiled using -the -int-long-rent compiler option. - -
-If you have multiple source files in your project, interrupt service -routines can be present in any of them, but a prototype of the isr -MUST be present in the file that contains the function 'main'. - -
-Interrupt Numbers and the corresponding address & descriptions for -the Standard 8051 are listed below. SDCC will automatically adjust -the interrupt vector table to the maximum interrupt number specified. - -
-
Interrupt # | -Description | -Vector Address | -
0 | -External 0 | -0x0003 | -
1 | -Timer 0 | -0x000B | -
2 | -External 1 | -0x0013 | -
3 | -Timer 1 | -0x001B | -
4 | -Serial | -0x0023 | -
-If the interrupt service routine is defined without a register bank -or with register bank 0 (using 0), the compiler will save the registers -used by itself on the stack (upon entry and restore them at exit), -however if such an interrupt service routine calls another function -then the entire register bank will be saved on the stack. This scheme -may be advantageous for small interrupt service routines which have -low register usage. - -
-If the interrupt service routine is defined to be using a specific -register bank then only ``a'',''b'' & ``dptr'' are save -and restored, if such an interrupt service routine calls another function -(using another register bank) then the entire register bank of the -called function will be saved on the stack. This scheme is recommended -for larger interrupt service routines. - -
-Calling other functions from an interrupt service routine is not recommended -avoid it if possible. - -
- -
@@ -1810,8 +1924,8 @@ hardware or perform some other critical operation prior to static
-
@@ -1844,7 +1958,7 @@ carefully before using this option.
The inline assembler code can contain any valid code understood by the assembler (this includes any assembler directives and comment -lines ) . The compiler does not do any validation of the code within +lines). The compiler does not do any validation of the code within the _asm ... _endasm; keyword pair.
@@ -1882,8 +1996,8 @@ assembly CANNOT be accessed by C statements.
-
@@ -1955,8 +2069,8 @@ option, after which the source program will have to be compiled with
-
@@ -2040,8 +2154,8 @@ mentioned above will need to recompiled with the -model-Large option)
-
@@ -2069,8 +2183,8 @@ recommdended that the small model be used unless absolutely required.
-
@@ -2108,12 +2222,12 @@ on the sdcc command line.
-
-The compiler creates the following #defines . +The compiler creates the following #defines.
@@ -2272,7 +2386,7 @@ will be changed to
Note: the dead stores created by this copy propagation will be eliminated -by dead-code elimination . +by dead-code elimination.
@@ -2288,7 +2402,7 @@ and the register allocator tries to keep the induction variables in registers for the duration of the loop. Because of this preference of the register allocator , loop induction optimization causes an increase in register pressure, which may cause unwanted spilling of -other temporary variables into the stack / data space . The compiler +other temporary variables into the stack / data space. The compiler will generate a warning message when it is forced to allocate extra space either on the stack or data space. If this extra space allocation is undesirable then induction optimization can be eliminated either @@ -2394,8 +2508,8 @@ within the loop. Note djnz instruction can be used for 8-bit values ONLY, therefore -it is advantageous to declare loop control symbols as either 'char' -or 'short', ofcourse this may not be possible on all situations. +it is advantageous to declare loop control symbols as either 'char', +ofcourse this may not be possible on all situations.
@@ -2513,7 +2627,7 @@ If the above switch statement is broken down into two switch statements
then both the switch statements will be implemented using jump-tables -whereas the unmodified switch statement will not be . +whereas the unmodified switch statement will not be.
@@ -2523,14 +2637,14 @@ whereas the unmodified switch statement will not be .
Bit shifting is one of the most frequently used operation in embedded -programming . SDCC tries to implement bit-shift operations in the -most efficient way possible. +programming. SDCC tries to implement bit-shift operations in the most +efficient way possible.
eg.
-unsigned short i; +unsigned char i;
@@ -2610,10 +2724,10 @@ will generate the following code.
-SDCC uses pattern matching on the parse tree to determine this operation -.Variations of this case will also be recognized as bit-rotation i.e -i = ((i >> 7) | (i << -1)); /* left-bit rotation */ +SDCC uses pattern matching on the parse tree to determine this operation.Variations +of this case will also be recognized as bit-rotation i.e i = +((i >> 7) | (i << 1)); /* +left-bit rotation */
@@ -2623,7 +2737,7 @@ SDCC uses pattern matching on the parse tree to determine this operation
It is frequently required to obtain the highest order bit of an integral -type (int,long,short or char types). SDCC recognizes the following +type (long, int, short or char types). SDCC recognizes the following expression to yield the highest order bit and generates optimized code for it. @@ -2659,7 +2773,7 @@ mov _foo_hob_1_1,a
-Variations of this case however will NOT be recognized . It is a standard +Variations of this case however will NOT be recognized. It is a standard C expression , so I heartily recommend this be the only way to get the highest order bit, (it is portable). Of course it will be recognized even if it is embedded in other expressions. @@ -2685,7 +2799,7 @@ will still be recognized.
The compiler uses a rule based , pattern matching and re-writing mechanism -for peep-hole optimization . It is inspired by 'copt' a peep-hole +for peep-hole optimization. It is inspired by 'copt' a peep-hole optimizer by Christopher W. Fraser (cwfraser@microsoft.com). A default set of rules are compiled into the compiler, additional rules may be added with the -peep-file <filename> option. The rule language @@ -2856,7 +2970,7 @@ are applicable only at a function level.
format output type argument-type
-
@@ -3024,7 +3138,7 @@ This simplified version of printf supports only the following formats.
The routine is very stack intesive , -stack-after-data parameter
should be used when using this routine, the routine also takes about
-1K of code space .It also expects an external function named putchar(char
+1K of code space. It also expects an external function named putchar(char
) to be present (this can be changed). When using the %s format
the string / pointer should be cast to a generic pointer. eg.
@@ -3121,8 +3235,8 @@ malloc.
%d decimal int
+
%d decimal short/int
%ld decimal long
-
%hd decimal short/char
-
%x hexadecimal int
+
%hd decimal char
+
%x hexadecimal short/int
%lx hexadecimal long
-
%hx hexadecimal short/char
-
%o octal int
-
%lo octal long
-
%ho octal short/char
+
%hx hexadecimal char
+
%o octal short/int
-
%c character char/short
+
%lo octal long
+
%ho octal char
+
%c character char
%s character _generic pointer
-extern int asm_func( unsigned short, unsigned short); +extern int asm_func( unsigned char, unsigned char);
-
int c_func (unsigned short i, unsigned short j)
+
int c_func (unsigned char i, unsigned char j)
{
return asm_func(i,j);
}
@@ -3258,7 +3370,7 @@ the left most parameter will be on the top of the stack. Here is an
example.
-extern int asm_func( unsigned short, unsigned short); +extern int asm_func( unsigned char, unsigned char);
@@ -3268,7 +3380,7 @@ example.
-int c_func (unsigned short i, unsigned short j) reentrant
+int c_func (unsigned char i, unsigned char j) reentrant
-When the source is compiled with -noregparms option , space is allocated
-for each of the parameters passed to a routine.
-
-
-
-
-In the following example the function cfunc calls an assembler
-routine asm_func, which takes two parameters.
-
-
-extern int asm_func( unsigned short, unsigned short);
-
-
-
-
-
-
-
-
-
-The corresponding assembler function is:-
-
-
- .globl _asm_func_PARM_1
-
-
-
-
-Note here that the return values are placed in 'dpl' - One byte return
-value, 'dpl' LSB & 'dph' MSB for two byte values. 'dpl', 'dph' and
-'b' for three byte values (generic pointers) and 'dpl','dph','b' &
-'acc' for four byte values.
-
-
-The parameter naming convention is _<function_name>_PARM_<n>,
-where n is the parameter number starting from 1, and counting from
-the left. i.e. the left-most parameter
-name will be _<function_name>_PARM_1.
-
-
-
-
-Assemble the assembler routine with the following command.
-
-
-asx8051 -losg asmfunc.asm
-
-
-Then compile and link the assembler routine to the C source file with
-the following command,
-
-
-sdcc cfunc.c asmfunc.rel
-
-
-
-
-In this case the parameters will be passed on the stack , the parameters
-are pushed from right to left i.e. after the call the left most parameter
-will be on the top of the stack. Here is an example.
-
-
-extern int asm_func( unsigned short, unsigned short);
-
-
-
-
-
-
-
-
-
-int c_func (unsigned short i, unsigned short j) reentrant
-
-
-
-
-
-The corresponding assembler routine is.
-
-
- .globl _asm_func
-
-
-
-
-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.
-
-
-
-
@@ -3484,8 +3445,8 @@ option, this port MAY NOT be used by the application program.
-
@@ -3580,18 +3541,18 @@ like 'foo()' */
{
return asm_func(i,j);
@@ -3314,158 +3426,7 @@ the stack for parameters and local variables.
-4.6 With -noregparms Option
-
-
-
-4.6.1 Assembler Routine Non-reentrant
-
-
-
int c_func (unsigned short i, unsigned short j)
-
{
-
return asm_func(i,j);
-
}
-
int main()
-
{
-
return c_func(10,9);
-
}
-
.globl _asm_func_PARM_2
-
.globl _asm_func
-
.area OSEG
-
_asm_func_PARM_1: .ds 1
-
_asm_func_PARM_2: .ds 1
-
.area CSEG
-
_asm_func:
-
mov a,_asm_func_PARM_1
-
add a,_asm_func_PARM_2
-
mov dpl,a
-
mov dpl,#0x00
-
ret
-
-4.6.2 Assembler Routine(reentrant)
-
-
-
{
-
return asm_func(i,j);
-
}
-
int main()
-
{
-
return c_func(10,9);
-
}
-
_asm_func:
-
push _bp
-
mov _bp,sp
-
mov a,_bp
-
clr c
-
add a,#0xfd
-
mov r0,a
-
mov a,_bp
-
clr c
-
add a,#0xfc
-
mov r1,a
-
mov a,@r0
-
add a,@r1
-
mov dpl,a
-
mov dph,#0x00
-
mov sp,_bp
-
pop _bp
-
ret
-
-4.7 External Stack
+4.6 External Stack
-4.8 ANSI-Compliance
+
+4.7 ANSI-Compliance
-
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. +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 @@ -3631,7 +3592,7 @@ are generally good programming practice.
@@ -3890,7 +3850,7 @@ 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 . +it into appropriate commands for the simulator.
@@ -3936,7 +3896,7 @@ 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 +should be -directory=/home/src1:/home/src2. Note there can be no spaces in the option.
The command line arguments were:
- latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir72816uWRHo/lyx_tmpbuf7281E6F6dg/SDCCUdoc.tex
-
-The translation was initiated by Karl Bongers on 2001-07-02
+The translation was initiated by Karl Bongers on 2001-07-04
+