Forum Update - Announcement about May 10th, 2018 update and your password.

PNut and p2asm and other P2 tools

2»

Comments

  • David Betz wrote: »
    I'm trying to figure out if we should go ahead with porting gas or if we should try to use p2asm. Just how hard is it to parse the P2 instruction set? There is already code in tc-propeller.c to parse some of the P2 syntax. Are there a lot of tricky features beyond what we already have?

    I see we do have some support for things like "ptra++", so that's good (although I think it's bit-rotted and needs updating). There are some other things that we need to handle though, like emitting AUGD and AUGS for ##, the many instruction aliases, and the weird ANDC/ANDZ/ORC/ORZ operations on some instructions. I honestly don't know whether adding ELF to p2asm would be easier than making gas PNut compatible. I know that in P1 there were a lot of incompatibilities in the original gas, which caused headaches for programmers. The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.

  • ersmith wrote: »
    David Betz wrote: »
    I'm trying to figure out if we should go ahead with porting gas or if we should try to use p2asm. Just how hard is it to parse the P2 instruction set? There is already code in tc-propeller.c to parse some of the P2 syntax. Are there a lot of tricky features beyond what we already have?

    I see we do have some support for things like "ptra++", so that's good (although I think it's bit-rotted and needs updating). There are some other things that we need to handle though, like emitting AUGD and AUGS for ##, the many instruction aliases, and the weird ANDC/ANDZ/ORC/ORZ operations on some instructions. I honestly don't know whether adding ELF to p2asm would be easier than making gas PNut compatible. I know that in P1 there were a lot of incompatibilities in the original gas, which caused headaches for programmers. The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.
    Certainly, the code needs to be updated for the new P2 instruction set. If nothing else, the bit fields are different sizes and in different places in the current P2 instruction encoding compared with the version currently implemented in binutils. I'm inclined to separate the P1 and P2 instruction parsing into two separate files. It's pretty confusing with both mixed into the same file since there is little overlap between the two.

  • ersmith wrote: »
    The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.

    What are the missing things ?
    VT-100 Terminal and Graphics Card for the RC2014 Z80 Computer
  • macca wrote: »
    ersmith wrote: »
    The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.

    What are the missing things ?

    GAS restrictions compared to PASM
    =================================

    (1) Floating point in GAS can only occur in a .float directive, and only simple constants are accepted (no expressions).

    (2) Strings can only appear in .ascii (not byte).

    (3) No repeat counts like "long 0[32]" in literal data.

    (4) String literals not accepted in immediates.

    (5) No Spin operators like |<. Also, operator precedence in expressions is like C, which is different from Spin in some cases.

    (6) res produces zeros

    (7) org and fit are ignored (left to linker).

    (8) GAS only accepts ASCII (or UTF-8) input, not UTF-16.

    (9) conditionals like if_z cannot start the line, there must be at least one space before them

    (10) long and word directives are not automatically aligned (they must be explicitly aligned). This is actually a useful feature, since it allows you to easily define packed structures. p2asm has the same feature,
  • ersmith wrote: »
    macca wrote: »
    ersmith wrote: »
    The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.

    What are the missing things ?

    GAS restrictions compared to PASM
    =================================

    (1) Floating point in GAS can only occur in a .float directive, and only simple constants are accepted (no expressions).

    (2) Strings can only appear in .ascii (not byte).

    (3) No repeat counts like "long 0[32]" in literal data.

    (4) String literals not accepted in immediates.

    (5) No Spin operators like |<. Also, operator precedence in expressions is like C, which is different from Spin in some cases.

    (6) res produces zeros

    (7) org and fit are ignored (left to linker).

    (8) GAS only accepts ASCII (or UTF-8) input, not UTF-16.

    (9) conditionals like if_z cannot start the line, there must be at least one space before them

    (10) long and word directives are not automatically aligned (they must be explicitly aligned). This is actually a useful feature, since it allows you to easily define packed structures. p2asm has the same feature,
    Are these all difficult or impossible to "fix" or have we just not had the time to tackle them yet?

  • David Betz wrote: »
    Are these all difficult or impossible to "fix" or have we just not had the time to tackle them yet?

    It's a mixture. I think some of them are fundamental issues with gas, and would require a major re-work to get right. Others probably just require a bit of tweaking to the gas expression parser.
  • jmgjmg Posts: 11,425
    ersmith wrote: »
    macca wrote: »
    ersmith wrote: »
    The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.

    What are the missing things ?

    GAS restrictions compared to PASM
    =================================

    (1) Floating point in GAS can only occur in a .float directive, and only simple constants are accepted (no expressions).

    (2) Strings can only appear in .ascii (not byte).

    (3) No repeat counts like "long 0[32]" in literal data.

    (4) String literals not accepted in immediates.

    (5) No Spin operators like |<. Also, operator precedence in expressions is like C, which is different from Spin in some cases.

    (6) res produces zeros

    (7) org and fit are ignored (left to linker).

    (8) GAS only accepts ASCII (or UTF-8) input, not UTF-16.

    (9) conditionals like if_z cannot start the line, there must be at least one space before them

    (10) long and word directives are not automatically aligned (they must be explicitly aligned). This is actually a useful feature, since it allows you to easily define packed structures. p2asm has the same feature,

    That's quite a list :(
    On a generic MCU, my advice would usually be to focus on C, and patch GAS to 'almost tolerable' level, to allow a common/known tool chain advantage.

    However, the P2 is not a generic MCU and (very) good ASM support matters more here.

    There are already multiple very good ASM results ( & Spin and C !) being reported for P2, outside of GAS, and it is looking easier to make those Object compatible, than it is to fix the many issues in GAS.
    The Compiled Spin efforts will also give P1 a healthy boost, and anything that extends P1 life, is more income for Parallax.

    Just following the ROM posts, it seems all the ASM pathways have been given a good exercise, and are starting to show fewer caveats.
    eg Listing has improved significantly and include is supported.
  • jmg wrote: »
    ersmith wrote: »
    macca wrote: »
    ersmith wrote: »
    The most recent binutils has reduced those quite a bit, but gas is still not quite compatible with Proptool/Openspin/etc.

    What are the missing things ?

    GAS restrictions compared to PASM
    =================================

    (1) Floating point in GAS can only occur in a .float directive, and only simple constants are accepted (no expressions).

    (2) Strings can only appear in .ascii (not byte).

    (3) No repeat counts like "long 0[32]" in literal data.

    (4) String literals not accepted in immediates.

    (5) No Spin operators like |<. Also, operator precedence in expressions is like C, which is different from Spin in some cases.

    (6) res produces zeros

    (7) org and fit are ignored (left to linker).

    (8) GAS only accepts ASCII (or UTF-8) input, not UTF-16.

    (9) conditionals like if_z cannot start the line, there must be at least one space before them

    (10) long and word directives are not automatically aligned (they must be explicitly aligned). This is actually a useful feature, since it allows you to easily define packed structures. p2asm has the same feature,

    That's quite a list :(
    On a generic MCU, my advice would usually be to focus on C, and patch GAS to 'almost tolerable' level, to allow a common/known tool chain advantage.

    However, the P2 is not a generic MCU and (very) good ASM support matters more here.

    There are already multiple very good ASM results ( & Spin and C !) being reported for P2, outside of GAS, and it is looking easier to make those Object compatible, than it is to fix the many issues in GAS.
    The Compiled Spin efforts will also give P1 a healthy boost, and anything that extends P1 life, is more income for Parallax.

    Just following the ROM posts, it seems all the ASM pathways have been given a good exercise, and are starting to show fewer caveats.
    eg Listing has improved significantly and include is supported.
    Dave Hein says he will look into adding ELF/DWARF support to p2asm at some point. If it's going to happen soon it might be the best solution for the P2 GCC toolchain.

  • I think ELF should be fairly easy. I suspect PropGCC uses fixed values for most of the fields. DWARF is more involved. There is DWARF code available with a well defined API. However, it seems complex. I'll have to examine a few object files generated by PropGCC to see what's in there.
  • Dave Hein wrote: »
    I think ELF should be fairly easy. I suspect PropGCC uses fixed values for most of the fields. DWARF is more involved. There is DWARF code available with a well defined API. However, it seems complex. I'll have to examine a few object files generated by PropGCC to see what's in there.
    You don't really need DWARF unless you want to use gdb. I guess you could work on getting ELF supported first if that's easy. That would let us concentrate on the GCC part instead of binutils.

Sign In or Register to comment.