<!doctype linuxdoc system>
-<!-- LinuxDoc file was created by LyX 1.0 (C) 1995-1999 by <sandeep> Thu Oct 14 02:37:55 1999
+<!-- LinuxDoc file was created by LyX 1.0 (C) 1995-1999 by <sandeep> Sun Mar 26 12:40:33 2000
-->
<linuxdoc>
should be compiled with this option. In addition the standard library routines
are compiled with small model , they will need to be recompiled.
<item><bf>--model-small</bf> <label id="--model-small" >Generate code for Small Model programs see section Memory
+ Models for more details. This is the default model.
+ <item><bf>--model-flat24</bf> <ref id="--model-flat24" name="--model-flat24" >Generate code for Small Model programs see section Memory
Models for more details. This is the default model.
<item><bf>--stack-auto</bf> <label id="--stack-auto" >All functions in the source file will be compiled as reentrant,
i.e. the parameters and local variables will be allocated on the stack. see
<p>Note if all these routines are used simultaneously the data space might
overflow. For serious floating point usage it is strongly recommended that
the Large model be used (in which case the floating point routines mentioned
- above will need to recompiled with the --model-Large option).
+ above will need to recompiled with the --model-Large option)
</p>
<sect>Memory Models<label id="Memory Models" >
<p>SDCC allows two memory models, modules compiled with different memory models
model, it is therefore strongly recommdended that the small model be used unless
absolutely required.
</p>
+ <sect>Flat 24 bit addressing model.<label id="--model-flat24" >
+ <p>This option generates code for the 24 bit contiguous addressing mode of
+ the Dallas DS80C390 part. In this mode, up to four meg of external RAM or code
+ space can be directly addressed. See the data sheets at www.dalsemi.com for
+ further information on this part.
+ </p>
+ <p>Note that the compiler does not generate any code to place the processor
+ into this mode (it defaults to 8051 compatible mode). Boot loader or similar
+ code must ensure that the processor is in 24 bit contiguous addressing mode
+ before calling the SDCC startup code.
+ </p>
+ <p>Like the --model-large option, variables will by default be placed into
+ the XDATA segment. However, a current limitation is that the compiler will
+ spill variables into the DATA segment when it runs out of registers. This means
+ that compiling complex code can rapidly fill up the DATA segment. This limitation
+ is being worked on, and should be addressed in the next release of sdcc.
+ </p>
+ <p>Segments may be placed anywhere in the 4 meg address space using the usual
+ --*-loc options. Note that if any segments are located above 64K, the -r flag
+ must be passed to the linker to generate the proper segment relocations, and
+ the Intel HEX output format must be used. The -r flag can be passed to the
+ linker by using the option -Wl-r on the sdcc command line.
+ </p>
+ <p>--stack-10bit:
+ </p>
+ <p>This option generates code for the 10 bit stack mode of the Dallas DS80C390
+ part. In this mode, the stack is located in the lower 1K of the internal RAM,
+ which is mapped to 0x400000.
+ </p>
+ <p>With this option, sdcc will generate the proper addressing for stack variables.
+ </p>
+ <p>Note that the support is incomplete, since it still uses a single byte
+ as the stack pointer. This means that only the lower 256 bytes of the potential
+ 1K stack space can actually be used. However, this does allow you to reclaim
+ the precious 256 bytes of low RAM for use for the DATA and IDATA segments.
+ </p>
+ <p>The compiler will not generate any code to put the processor into 10 bit
+ stack mode. It is important to ensure that the processor is in this mode before
+ calling any re-entrant functions compiled with this option.
+ </p>
+ <p>In principle, this should work with the --stack-auto option, but that has
+ not been tested. It is incompatible with the --xstack option. It also only
+ makes sense if the processor is in 24 bit contiguous addressing mode (see the
+ --model-flat24 option).
+ </p>
<sect>Defines created by the compiler.<label id="Defines." >
<p>The compiler creates the following #defines .
</p>
</p>
<p>Unknown - for the GNU C - preprocessor.
</p>
+ <sect>Appendix A: The Z80 and gbz80 port
+ <p>2.2.0 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, but apart
+ from that the code generated is correct.
+ </p>
+ <p>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.bc
+ </p>
+ <p>9
+ </p>
<p>
</p>
projects / fw / sdcc / blobdiff