Re: binutils for processor with separate data and code space

[Alan Lehotsky <apl at alum dot mit dot edu>]

At 4:45 PM -0400 10/6/01, LeakyStain wrote:

>Alan,
>
>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
	PDP-11 terminology....)

	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

		0x10000000..0x1fffffff

	and your data sections could start at

		0x20000000..0x2fffffff

	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
	instructions!).

	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....

	Good luck,
	Al Lehotsky


	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
		http://home.earthlink.net/~qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation