This is the mail archive of the cgen@sourceware.org mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Labels resolving to zero


I already solved my problem. I'm sure the developers already know this but for anyone else trying to do a port it wasn't exactly clear. Turns out that the address fields are filled in with zeros if they can't be resolved during the assembly of relocatable object files. These unresolved addresses are then calculated and filled in during the linking phase. I had my BFD definitions wrong for the absolute and relative relocatable addresses and it would spit out a bit pattern that didn't line up with the field in question. This caused the disassembler to see an *unknown* instruction and messed up the alignment of the other instructions. So I fixed all that and it appears to be working.

-Brian


On Nov 8, 2008, at 10:38 AM, Brian Mokrzycki wrote:


I'm currently trying to port binutils to a custom digital signal processing architecture. I've run into a couple issues but I can't seem to figure this one out. I am trying to implement a branching instruction such as in the example below.

_START:
		LD		R4, 8
		NOP
LOOP: 	ADD 	R1,R2,R3
		SUB 	R4,R4,1
		BNEZ	LOOP

The LOOP label argument for BNEZ is a 24-bit absolute address (well actually 26-bit but I wanted to make sure byte boundaries weren't causing more hidden problems). When I assemble this, the LOOP label always resolves to 0 <_start>. Furthermore when I go and actually link the object file, the disassembly of BNEZ becomes this very very long sequence of bytes and is an *unknown* instruction.

Here's what I think are the relevant lines in my .cpu file to describe the branch instruction. Please note that I haven't implemented the flags yet so the PC is updated unconditionally for now.

; Field Definition

(df f-abs24 "Absolute 24-bit Jump Address" ((ISA wvfe-cop) ABS- ADDR) 44 24 INT
((value pc) (sra WI pc (const 2)))
((value pc) (sll WI value (const 2))))


....


; Enumeration of branch codes and tests


; Branch Codes : bits 50-47
(define-normal-insn-enum insn-cnd-code "Control Unit Condition Code Enums" () CND_ f-50-4
("UNC" "POS" "NEG" "ZER" "OVF" "BLI" "BCE" "7" "8" "9" "10" "11" "12" "13" "14" "15")
)


(define-normal-insn-enum insn-cnd-test "Control Unit Condition Test Enums" () TST_ f-51-1
("EQ" "NE")
)
....


(dnop uimm24 "Absolute 24-bit Address" () h-iaddr f- abs24)

....

(dni bneza "branch if not equal zero (absolute address)"
()
"bnez ${uimm24}"
(+ COP_BRCH (f-58-6 0) (f-52-1 0) TST_NE CND_ZER (f-46-2 0) uimm24 (f-20-21 0))
(set pc uimm24)
()
)


From looking at other ports I'm fairly confident that this is what's required in the .opc file. So this makes me believe that there is another file that I need to modify/implement to get the address of the label. Any ideas?

-Brian






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]