Shop OBEX P1 Docs P2 Docs Learn Events
propgcc & binutils question — Parallax Forums

propgcc & binutils question

montekkimontekki Posts: 4
edited 2014-08-22 12:47 in Propeller 1
I've been looking into propeller instruction set and playing around with propgcc and binutils a bit and i've noticed some strange behaviour of propeller-elf-objdump. Take a look at the way code is generated for a simple example and the way this code is disassembled by objdump:
nL6KvTK.jpg
. add r7, r0 turns into add r7, r7 and so on. Could this bug be fixed?
nL6KvTK.jpg
1024 x 229 - 27K

Comments

  • jazzedjazzed Posts: 11,803
    edited 2014-08-21 07:26
    What optimization level are you using?
  • montekkimontekki Posts: 4
    edited 2014-08-21 07:39
    no optimization, i think it has nothing to do with instructions turning into other instructions during assembly/disassembly since optimization is done before that stage. In fact, i can not understand the output of the objdump at all, like take a look at the follwing:

    0100bc00 rdbyte 0 <r7>, 4 <r7+0x4>

    As i've understood from the reference that in fact should be rdbyte r0,r1 since '1' is the least significant bit of src.
  • jazzedjazzed Posts: 11,803
    edited 2014-08-21 07:53
    Ok.

    I'll leave this for Eric or someone else to answer.
  • ersmithersmith Posts: 6,053
    edited 2014-08-21 22:47
    Sorry I'm traveling so haven't had time to look at this in detail, but I think what you're seeing is a side effect of how the "registers" in the propeller are really just symbols denoting memory locations in COG memory. Until the object files are linked together, these symbols are unresolved and all have the value 0. The disassembler makes some effort to look up the symbol in the symbol table, but it isn't coping correctly and shows the same symbol for source as for destination. I think this is fixed in the default branch, I'm not certain though.

    This is only an issue for disassembly of .o files. Linked .elf files should disassemble correctly.
  • montekkimontekki Posts: 4
    edited 2014-08-21 23:41
    ok, i see. There is one more issue I yet don't understand. Take a look at the following:

    2ef4fca0 mov 1e8 <__TMP0>, #46

    this is 101000001 1 1111 001111010 000101110

    So, the source immediate value #46 is ok, but the dest it's moved to (1e8) is the "dest" field shifted two bits left. Is this some kind of addr alignment or something?
  • KyeKye Posts: 2,200
    edited 2014-08-22 06:40
    I believe the assembler thinks in byte addresses. However, they have to be converted to long addresses to run correctly when inside a cog.
  • montekkimontekki Posts: 4
    edited 2014-08-22 10:15
    It looks more like a bug:
    0: f021bca0 mov 40 <sp>, 7c0 <PAR>

    where obviously PAR is not 7c0 but but 1F0. See the value for par is shifted two bits left, as is the value for the dst register which is also 0x10 and not 0x40 .
  • KyeKye Posts: 2,200
    edited 2014-08-22 12:47
    Yes,

    The value reported by GAS is a byte address. However, the actual value is a long address.
Sign In or Register to comment.