This is the mail archive of the
mailing list for the GCC project.
Re: pointer modes for Harvard architecture....
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: apl at alum dot mit dot edu
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 29 Jan 2012 15:04:39 +0100
- Subject: Re: pointer modes for Harvard architecture....
- References: <EA829523-0E4A-4C0F-AD2F-8859FB9F0CAC@earthlink.net>
Alan Lehotsky schrieb:
I'm working on a port to a Harvard architecture where the data memory
addresses are only 14 bits wide (e.g. 16kb) and the instruction
address space is 21 bits wide.
I do not want to define Pmode as PSImode; the machine has separate
address registers for data memory AND with such limited data memory,
I really want data pointers to stay HImode.
I've noticed that some generated function calls are appearing as
(call (mem:SI (symbol_ref:HI ("function_name") ...
which I suspect is wrong for code addresses outside of the first 65kb
of instruction memory.
What is FUNCTION_MODE?
Anyways, you don't know where function_name will be located, so as this
is a direct call it's more about the address range of your call instruction.
It would be helpful to see an existing port with wider function
pointers to help me avoid stumbling over some of these issues. Is
there a current port that has larger instruction memory addresses
than data addresses?
You have different flavour of calls
1) direct calls
2) indirect calls
As mentiones above, that's about address range of your call/jump
instruction. If it can address the whole address space you are done.
If not, there are several approaches:
a) Always load the address and perform an indirect call/jump.
b) Assume that the target symbol is in the address range of the
If not, the linker has to fix it. This can be done
by calling a small, auto-generated jump pad at the and of
the function which loads the address and performs an indirect
jump to the target function. Notice that you need a register
here which is call-clobbered and must not be used as argument
register: The compiler must assume the worst case.
Some targets provide longcall/long_call function attribute,
i.e. in general there is the assumption that call offsets
are short and in the range of call instruction. If not,
this attribute triggers a) and you don't need a jump pad.
AVR has similar problem: Pmode is HImode but there are devices that
need addresses wider then 16 bits for indirect calls.
Here is an outline of how avr-tools solve this, but the solution
depends on hardware capabilities and linker features:
"EIND and Devices with more than 128 Ki Bytes of Flash"
The idea is that indirect calls/jumps are redirected to a jump pad in
the 16-bit address range and the jump pad forwards to the desired target
by means of a direct jump. Direct jumps on AVR can target all addresses.
Jump pad generation is triggered by avr-specific gs() address modifier.
You con focus on gs() when reading the link above; probably your machine
has not the complexity of EIND: a special function register to hold the
high part of address when long-jumping, so you can ignore EIND.