> So you are saying that a 16bit data word in IMEM is actually two 12bit
> data words (supposedly only the lower 8 bits used in each) and thus the
> array contains "padding"?
Effectively yes. The assembler handles dividing constants into their LSB
and MSB components. I have insn patterns and splitters defined that emit
the correct instructions to read and "pack" the value into a register or
generic memory location.
All I really need at this point is a means to augment how addresses (e.g.
array offsets or struct members) are calculated in a non-generic address
space. This doesn't feel like a far fetched idea as GCC currently supports
address space specific legitimization and modes.
On Mon, Jan 11, 2021 at 12:50 AM Richard Biener <richard.guent...@gmail.com>
wrote:
> On Sat, Jan 9, 2021 at 12:24 AM Tucker Kern via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > Hi,
> >
> > I'm implementing named addresses spaces for a Harvard architecture
> machine
> > to support copying data from instruction memory to data memory. This is
> > achieved via a special instruction. e.g. think AVR and progmem/__flash.
> >
> > However, the instruction memory is narrower than the data memory (12 vs
> 16
> > bits) on this machine. So a single data word is split across 2
> instruction
> > words. When copied from IMEM to DMEM the two parts are combined via
> SHIFT +
> > OR patterns.
> >
> > This is all working fine for regular variables (i.e. int som_var), but it
> > falls apart for array references (i.e. some_array[1]). Since the data is
> > stored across 2 IMEM words, I need to scale the calculated offset of each
> > array reference by 2. e.g. array[0] is actually stored in imem[0] &
> imem[1]
> > and array[1] is stored in imem[2] & imem[3].
>
> So you are saying that a 16bit data word in IMEM is actually two 12bit
> data words (supposedly only the lower 8 bits used in each) and thus the
> array contains "padding"? That's not really supported and is also not
> the scope of named address spaces. I'd suggest you go down the route
> of providing intrinsics for the transfer of data instead which could resort
> to target specific builtin functions.
>
> > e.g.
> > static __imem int imem_array[2];
> > return imem_array[1];
> >
> > // needs to generate a symbol reference like
> > &imem_array.869+2
> >
> > Similarly if the array index was a function parameter, I need to scale
> the
> > parameter by 2.
> > __imem int imem_array[2];
> > int some_func(int a)
> > {
> > // a needs to be scaled by 2 when generating RTL/ASM
> > return imem_array[a];
> > }
> >
> > I haven't found any target hooks that would allow me to override the
> offset
> > calculation. Originally I thought I could handle it in a splitter but
> this
> > approach didn't work for the function parameter example as I ended up
> > scaling the entire address instead of just the offset.
> >
> > I had another thought of using a combo of
> > TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS and
> > TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P to scale the offset and mark it as
> > adjusted but I don't think this combo will work in the end.
> >
> > Is there any way to achieve this?
> >
> > Thanks,
> > Tucker
>
