public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* Labels resolving to zero
@ 2008-11-08 16:39 Brian Mokrzycki
  2008-11-11  0:07 ` Brian Mokrzycki
  0 siblings, 1 reply; 2+ messages in thread
From: Brian Mokrzycki @ 2008-11-08 16:39 UTC (permalink / raw)
  To: cgen

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




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Labels resolving to zero
  2008-11-08 16:39 Labels resolving to zero Brian Mokrzycki
@ 2008-11-11  0:07 ` Brian Mokrzycki
  0 siblings, 0 replies; 2+ messages in thread
From: Brian Mokrzycki @ 2008-11-11  0:07 UTC (permalink / raw)
  To: cgen

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-11-11  0:07 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-08 16:39 Labels resolving to zero Brian Mokrzycki
2008-11-11  0:07 ` Brian Mokrzycki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).