Hi!
> So that's the question - does the GCC port (either the OpenRISC port or UC's
> port) fully take into account the Harvard architecture? I realise the ORP
> version doesn't have this problem as it uses the 'traffic cop' and caches
> but that's overkill for what we want.
UC's gcc-2.95.3 puts constant data in a separate section (.rodata), so
it can be used with a Harvard architecture.
I have also tested OpenCores versions for this matter, and I have found
out that gcc-2.95.2 puts constantd data and code together in .text
section. However, newer versions (OpenCores gcc-3.x) put constants in
.rodata.
> On the same note, whilst it's good to see the efforts done by Carlos and the
> University of Cantabria, surely it would be better to put effort into
> maintaining the GCC 3.2.3 port as opposed to the old 2.95.3 port? I have
> just compiled the latest eCos successfully on GCC 3.2.3 port (not run it yet
> though) but I'm wondering if UC's efforts need to be included as well. Can
> anyone give me the status on this?
As Matjaz has pointed, I need gcc-2.95.3. But it's almost finished now,
and we will join efforts to develop a gcc-3.4 port with the best of each
branch.
Regards,
Carlos
> Robert Cragie, Design Engineer
> _______________________________________________________________
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
> http://www.jennic.com Tel: +44 (0) 114 281 2655
> _______________________________________________________________
>
> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Robert Cragie
> Sent: 02 July 2003 12:01
> To: ECOS
> Subject: [ECOS] Harvard architecture MLT files
>
>
> I have an implementation of the OpenRISC core which is pure Harvard, i.e. no
> caches/mmus, separate instruction bus and memory, separate data bus and
> memory. The memories are dual-ported which means I can load them externally
> without needing the processor running. So my ultimate aim is to create two
> image files for the instruction and data memories respectively.
>
> This brings up a few questions:
>
> 1) How do I now layout the MLT files? It's no longer ROM and RAM, it's more
> like ROM(inst), ROM(data), RAM(data). Here is a stab at the .ldi file:
>
> // eCos memory layout
>
> #include <cyg/infra/cyg_type.inc>
>
> MEMORY
> {
> inst : ORIGIN = 0x00000000, LENGTH = 0x00020000
> data : ORIGIN = 0x01000000, LENGTH = 0x00020000
> }
>
> SECTIONS
> {
> SECTIONS_BEGIN
> SECTION_vectors (inst, 0x00000100, LMA_EQ_VMA)
> SECTION_ROMISC (inst, ALIGN (0x8), LMA_EQ_VMA)
> SECTION_RELOCS (inst, ALIGN (0x8), LMA_EQ_VMA)
> SECTION_init (inst, ALIGN (0x8), LMA_EQ_VMA)
> SECTION_text (inst, ALIGN (0x4), LMA_EQ_VMA)
> SECTION_fini (inst, ALIGN (0x4), LMA_EQ_VMA)
> SECTION_rodata1 (data, 0x01000000, LMA_EQ_VMA)
> SECTION_rodata (data, ALIGN (0x8), LMA_EQ_VMA)
> SECTION_fixup (data, ALIGN (0x4), LMA_EQ_VMA)
> SECTION_gcc_except_table (data, ALIGN (0x4), LMA_EQ_VMA)
> SECTION_data (data, ALIGN (0x8), FOLLOWING (.gcc_except_table))
> SECTION_eh_frame (data, ALIGN (0x8), FOLLOWING (.data))
> SECTION_ctors (data, ALIGN (0x8), FOLLOWING (.eh_frame))
> SECTION_dtors (data, ALIGN (0x8), FOLLOWING (.ctors))
> SECTION_devtab (data, ALIGN (0x8), FOLLOWING (.dtors))
> SECTION_got (data, ALIGN (0x8), FOLLOWING (.devtab))
> SECTION_dynamic (data, ALIGN (0x8), FOLLOWING (.got))
> SECTION_sdata (data, ALIGN (0x8), FOLLOWING (.dynamic))
> SECTION_lit8 (data, ALIGN (0x8), FOLLOWING (.sdata))
> SECTION_lit4 (data, ALIGN (0x8), FOLLOWING (.lit8))
> SECTION_sbss (data, ALIGN (0x8), LMA_EQ_VMA)
> SECTION_bss (data, ALIGN (0x10), LMA_EQ_VMA)
> CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
> SECTIONS_END
> }
>
> Am I anywhere close?
>
> And for the image files, is it a case of taking the literal values from
> 0x00000000 to 0x00020000 and writing them into the instruction memory and
> taking the literal values from 0x01000000 to 0x01020000 and writing them
> into the data memory? (I'm not too bothered about repeating data space in
> the rodata and data sections at the moment but would like to know how to
> avoid it if possible).
>
> Any help would be much appreciated.
>
> Robert Cragie, Design Engineer
> _______________________________________________________________
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
> http://www.jennic.com Tel: +44 (0) 114 281 2655
> _______________________________________________________________
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>
> --
> To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml
>
Esta parte del mensaje esta firmada digitalmente