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]
Other format: [Raw text]

Re: pointer modes for Harvard architecture....


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

ad 1)
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
   call/jump.
     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.

ad 2)
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"
http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

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.


Johann


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