Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #20065

Re: MicroBlaze program memory vs data memory

From al.basili@gmail.com (alb)
Newsgroups comp.arch.embedded
Subject Re: MicroBlaze program memory vs data memory
Date 2015-02-12 07:36 +0000
Message-ID <ck33fsF9macU1@mid.individual.net> (permalink)
References <c5478350-2bcb-4334-9fb4-55841d6bd07a@googlegroups.com> <BSVCw.1930$0s4.717@fx08.iad>

Show all headers | View raw


Hi Richard,

Richard Damon <Richard@damon-family.org> wrote:
[]
> First, if you are just specifying addresses without some qualifier for 
> which address space, and the linker is accepting them, then the linker 
> isn't working in "Harvard" mode. You will need to read the Fine 
> documentation to see how (if it is possible) to use it in a "Harvard" mode.

The docs do not seem to refer in anyway to a 'Harvard' architecture. The 
microblaze uses gcc and AFAIK the same issue appears on AVRs where the 
toolchain takes care about 'adding' an offset for data memory in order 
not to overlap instruction and data memory.

> A Harvard architecture linker will need to have addresses somehow 
> modified by being code or data space.

IMO the OP would be better off defining an offset which is beyond the 
address space handled by the hardware. Let's say the hardware handles 
20bit address for both instructions and data, it would be sufficient to 
specify the ORIGIN for the data memory to 0x100000 to fool the linker 
into thinking that there's only one address space, yet have the data 
memory aligned at 0x00000 (only 20 LSB considered).

> The issue might be that even though the processor uses a Harvard 
> architecture, it is commonly used (and the tools thus configured) in a 
> mode combining the two address spaces to make it more like "traditional" 
> processors. In this configuration, you can't have data and code at the 
> same address space.

Another possibility would be to disable the check for overlapping 
sections, but I would not recommend that approach.

Al

Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

MicroBlaze program memory vs data memory charles.ingels@syderal.ch - 2015-02-05 01:04 -0800
  Re: MicroBlaze program memory vs data memory Richard Damon <Richard@Damon-Family.org> - 2015-02-11 23:20 -0500
    Re: MicroBlaze program memory vs data memory al.basili@gmail.com (alb) - 2015-02-12 07:36 +0000

csiph-web