avr_design.txt

很少见的源码公开的msc51和z80的c编译器。

Design Document for AVR Port
----------------------------

The first release will support all AVR architectures except ATMega & ATtiny
(i.e. all variants with 64K or less of code/data space will be supported)

All functions will be REENTRANT .

I) Language extensions.
-----------------------

a) Storage classes
------------------

"bit"   - not applicable (will be returned to user name space)
"data"  - not applicable (will be returned to user name space)
"idata" - not applicable (will be returned to user name space)
"xdata" - not applicable (will be returned to user name space)
"code"  - will place variable in "code" space. NOTE code space is NOT read-only.
"eeprom"- (new) will place the variable in eeprom (read & write)
"sram"  - (new) will place the variable in "SRAM" after the SFRs (default).


b) register/sfr bit access.
--------------------------
Operator '.' will be overloaded ( the compiler will decide if it
is a structure access or register bit access depending on context)
eg.

sfr SOME_SFR = 0x40;
sfr SOME_OTHER_SFR = 0x41;
foobar() 
{
	...
	SOME_SFR.4 = 1; // set bit 4 of sfr SOME_SFR
	...
	SOME_SFR.5 = SOME_OTHER_SFR.6; // copy bit 6 of SOME_OTHER_SFR to SOME_SFR's bit 5.
	...
}

II) Pointers 
------------
As mentioned above initial releases will NOT support ATMega. 

Keeping with the three byte pointers for generic pointers,
the compiler will treat unqualified pointers as 3 byte pointers, 
the storage area will be saved in the upper nibble of the third byte 
(this will facilitate later support for ATMega). Here we differ for 
IAR (they seem to make copies of variables in code & other address 
spaces into data space, seemed like a needless waste of data space).

pointer declaration examples.

char *cp;        /* generic three byte pointer */
code char *cp;   /* pointer to code space */
eeprom char *cp; /* pointer to data in eepromp */
sram char *cp;   /* pointer to data in SRAM space */

III) Function calls
-------------------
The previous issue of function calls has been somewhat resolved.
SDCC will NOT support ATtiny & other variants (such as AT90S1200)
which have limited stack depth. It will however support variants
with 8 bit stack pointers.

IV) Register Usage
------------------

R0-R7      -  Paramter passing & return value (differs from IAR I don't
	      like IAR's usage of R16-R23, specially since R0-R1 has
	      to be kept free anyway for divide & multiply operations)
R8-R25     -  General purpose registers for local variables.
R28-R29(Y) -  Stack Frame (Same as IAR)
R26-R27(X) -  GPRs assigned to pointers (non generic pointers).
R30-R31(Z) -  GPRs assigned to pointers (non generic pointers).

V) Parameter passing & return values
------------------------------------
Registers R0-R7 (eight) registers will be used for parameter passing.
Unlike the 8051 port the AVR port will pass the first eight bytes of
parameters in a registers (8051 passes only yhe first parameter in
registers), the exception being.. part of a paramter will not be put
into registers.

Examples
int foo (char a,long b);
    R0    <- a,
    R1-R4 <- b;

int foo (long a, char b, long c)
    R0-R3   <- a,
    R4      <- b,
    (STACK) <- c;

int foo (long a,long b)
    R0-R3   <- a,
    R4-R7   <- b;

Return values will be placed in registers R0-R3;

VI) Memory models
-----------------
The memory model will be used primarily to determine the 
width of the stack pointer.

--model-small - stack pointer 8 bit
--model-large - stack pointer 16 bit.