This is the mail archive of the
mailing list for the GCC project.
Re: binutils for processor with separate data and code space
- To: LeakyStain <leakstan at erols dot com>
- Subject: Re: binutils for processor with separate data and code space
- From: Alan Lehotsky <apl at alum dot mit dot edu>
- Date: Sat, 6 Oct 2001 18:28:21 -0400
- Cc: * Alan Lehotsky <apl at alum dot mit dot edu>, gcc at gcc dot gnu dot org
- References: <3BBF6D71.firstname.lastname@example.org>
At 4:45 PM -0400 10/6/01, LeakyStain wrote:
>I saw in http://sources.redhat.com/ml/binutils/2001-04/msg00314.html that you are using binutils for a processor that has separate data and code spaces. I'm porting binutils to the UTMC UT69R000 (ut69r for short), which also has separate code and data spaces. I'm using the elf output format.
>I'm curious as to how you solved your problem; the followup on the mailing list didn't seem to be helpful.
There are multiple ports that have this sort of split address space (separate I/D space, to use the old
This is really easy for machines with smaller than 32-bit addresses - you simply load the TEXT and DATA
into distinct "logical" addresses, and use "virtual" addresses that are appropriately zero-origined.
For example, your text section could be linked at
and your data sections could start at
There's a little bit of magic you need to worry about so that you correctly translate between the
logical and physical addresses, but that doesn't require ANY patching of binutils. All you have to
do is write the linker script to load starting at those addresses.
Now, if you're using cgen to do the simulator and gdb support, you have to fudge those physical addresses
so that at run time everything works out ok, but that's not terribly hard....
>I've added a kludge that allows overlapping sections if one is "x" and the other is "!x", but I'd like to make it cleaner. Perhaps we can come up with a good solution.
>The ut69r is also a 16 bit addressable processor; binutils 2.11.2 has "opcodes_per_byte" to handle that, but it isn't documented, and I've had to patch it a bit. Is yours the same?
I've done one machine that's 32 bit addressable, and one that was 8 bit addressable (with an 8 bit ALU and 16 bit
The right way to do this with binutils is to assume 8-bit bytes, but scale all the relocations (there's a field
in the HOWTO structure that indicates how much to shift the relocation values). You just have to make sure that
anyone programming in assembly lnaguage understands that offsets are computed in 8 bit bytes, not 16 bit words.
It's much messier getting the compiler to deal properly with 16 bit bytes, but even that's not something
that requires special patches....
Wish I could just show you my port, but it's still under NDA.
I believe that the ip2k port is available from Ubicom, and it uses the relocated address space technique
to handle the 4kb data and 64kw instruction spaces.... (It even has a 3RD relocated address range in the
simulator to allow the debugger to access the architecturally invisible CALL stack [16 location pushdown
hw stack holding return addresses. In real HW, only the top location is accessable, but the debugger
running with the simulator can access all locations via a 32-bit address....
p.s. If you want to HIRE me to work on the port, I may have some time free in a month or two....
Quality Software Management
Software Process Improvement and Management Consulting
Language Design and Compiler Implementation