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