PNut and p2asm and other P2 tools

Comments

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.

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.

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,

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?

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.

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.

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.