This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Porting GCC to 8051-Microcontroler: memory layout


To the developers of the GCC,

referring to my project of porting the GCC for the Intel 8051
microcontroler I want to ask some questions (again).

The 8-Bit-Microcontroler 8051 has 128 Byte internal memory and 64KByte
external memory. There are different instructions for addressing both
memory types (-> internal: MOV ... / external: MOVX ...). But because
the internal memory is not very big, it shall be reserved only for most
of the registers and the stack. There are the following registers: the
Accu A, a multiplier register B, 4 Register banks (each of them has
eight Registers R0 - R7), a Stack Pointer SP and a Data Pointer DPTR.
All registers are 8 Bit, except the DPTR which is 16-Bit to address the
64 KByte external memory. So the external memory is the actual data
memory. The external RAM can only be addressed by the 16-Bit-DPTR or by
two of the R-Registers of Register Bank 0 -> R0 and R1. But when using
R0 or R1, you can address only the lowest 256 Byte of the external RAM,
because they are only 8 Bit. So addressing external memory is very
restricted. Furthermore the only way to load a 16-Bit-Address into DPTR
is by loading an immediate operand, so then the address has to be
constant. Else you can load the high byte and the low byte of the
address seperately in the 8-Bit-parts DPH and DPL which both together
build the DPTR-Register.

Now my question: do you think that it is a better solution to define
only the Registers DPL and DPH instead of DPTR to the GCC, because it is
the only 16 Bit Register ? Then there would be only 8-Bit-Registers - a
fact that maybe makes it easier to define some other Machine Macros and
the machine description. But in this case: how does the GCC know that an
address can be 16-Bit and has to be loaded byte by byte into DPH and DPL
?
Or do you see no problem when defining a single 16-Bit-Register among a
lot of 8-Bit-Registers ? But how I can realize that an address, that is
not a immediate constant, is loaded seperately and in the right order in
DPH and DPL ?

Independantly whether this register is defined as  DPTR or DPL and DPH :
Is it advisable to define DPTR (or DPL/DPH) as FIXED_REGISTER ? On the
one hand it can also be used as general register, but on the other hand
it has this special function to address the external memory.

Another problem: the 8051 has seperated memory for data and program
code: I already mentioned the data memory above, that is seperated in
internal and external RAM. The Program Code is loaded in the 64KByte
read-only Program memory (ROM). There are different instructions to
access ROM or RAM. So if the current program produces new data, this has
to be stored in the external data memory. But when there are constants,
for example a table of constant data, this generally has to be stored
together with the program code in the ROM. The Object code that is
generated by the Assembler is loaded into the ROM (mostly EEPROM), not
into the RAM. For example if there is a constant 0Ah, the GCC generates
an pseudo instruction like ".BYTE 0Ah", is this assumption right ? And
then the Assembler puts this Byte at the current location in the
programm code. But for moving this byte from program memory into the
accumulator you have to use another instruction (MOVC A, @A+DPTR) then
when moving a byte from external RAM into any register (MOVX A,@DPTR). I
have no idea, how to realize this in the Machine Description. Do you
have an idea ?

Last but not least: I don't understand exactly, what the Target Machine
Macro HARD_REGNO_MODE_OK (regno, mode) shall return. The 8051 has only
8-Bit-Register (except the DPTR). So only values of Mode QImode fit in a
8-Bit-Register, right ? Does this mean that the Macro has to return 0
when the value has any other mode ? Or do I have to consider consecutive
registers, too ?

I hope, I will get some answer from you. Thank you !!

Bye, Anja



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]