This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Porting GCC to 8051-Microcontroler: memory layout
- To: Anja Müller <Mueller-Lehnitz at t-online dot de>
- Subject: Re: Porting GCC to 8051-Microcontroler: memory layout
- From: Stephane Carrez <stcarrez at worldnet dot fr>
- Date: Sat, 08 Jan 2000 23:05:55 +0100
- CC: gcc at gcc dot gnu dot org, "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>, Joern Rennecke <amylaar at cygnus dot co dot uk>, Richard Hadsell <hadsell at blueskystudios dot com>
- References: <3877691B.EFBEF49E@t-online.de>
Hi!
Anja Müller wrote:
> [...]
> 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
> ?
In theory, you can do that because GCC knows how to use several
registers to put values largers than a basic register. In theory,
this is possible if all basic registers have the same size. In theory...
> 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 ?
>
That's the problem of the reload pass and of your movhi pattern.
In theory, the reload would reject the constant and would obtain
the DPTR register as a reload reg. Then, it would load it with your
movhi pattern the constant in the register. It's up to you to
load DPTR correctly.
Your biggest problem is not that DPTR is split in two subregs.
You only have one pointer register and this is quite impossible
for GCC to go with that.
The only way is to simulate pointer registers for gcc and put the
DPH and DPL as fixed registers. You define those registers as 16-bit
and put them anywhere you want (memory or some register bank).
If you put them in a register bank, you must mark those registers
as fixed.
Then in the machine description (code generation), each time GCC uses
your pointer register, you generate a load of that pointer in DPTR.
(This is a kind of hidden instruction). After that, you generate the
code for the corresponding operation.
This is easy if you have only 2 operands (like not, neg).
You can, at most, have two different pseudo pointer registers
(one input {load it first}, one output {load it last}).
If you have 3 operands (like add, sub, ...), this is more complicated.
This depends on what low level arithmetic you can do.
You have to load the DPTR with first operand;
then load the value pointed to by DPTR in accumulator (ACC?)
register; then load DPTR with second operand; compute; load DPTR
with result pointer and save.
Something like (pseudo asm):
mov dptr, <ptr reg in operands[1]> [split in 2 sub-moves DPL/DPH]
mov a, @dptr
mov dptr, <ptr reg in operands[2]>
add a, @dptr
mov dptr, <ptr reg in operands[0]>
mov @dptr, a
If you go in this direction, you must also put the ACC and any
register that you use internally in code generation as a fixed reg.
The problem with this is that you generate a lot of instructions
and that GCC does not optimize the load of DPTR (as it would in
a normal situation).
I had this similar problem on the 68HC11 port but I was much
more lucky because I have 2 pointer registers (X and Y). I have simulated
a third pseudo pointer register for GCC (Z). In the machine reorg pass,
I walk the insns and replace the fake register with a good one.
This is not easy because I have to save and restore the value of
the replacement register. Saving registers changes the flags so I
had to be careful of tst/cmp instructions.
Now, the advantage is that GCC knows the 2 main registers and
we get quite reasonable optimisation.
You could do the same but you have to simulate at least 2 registers.
The replacement could be a nigthmare too...
> [...]
>
> 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 ?
>
The macro is also used for GCC pseudo registers and they
must accept all modes. So, if (regno >= FIRST_PSEUDO_REGISTER) return 1
regards,
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France