pointer modes for Harvard architecture....

[Georg-Johann Lay]

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