Shop OBEX P1 Docs P2 Docs Learn Events
GAS vs PASM — Parallax Forums

GAS vs PASM

kuronekokuroneko Posts: 3,623
edited 2014-09-14 17:36 in Propeller 1
How do I convince GAS (or whoever is finally responsible) to actually put cog addresses into the table which has to be at this location. 
LOOP                    call #READ_CMD

                        and cmsk, mailbox
                        max cmsk, #9                    '' avoid overflow (optional if frontend handles it)
                        add jump, cmsk

                        mov cmsk, spiFuncBits           '' restore mask (spiFuncBits == SPI_FUNC_BITS)

jump                    jmpret jump, table

[COLOR="#FF0000"]table                   long    SEND, READ, SEND_fast, READ_fast, read_sector
                        long    SET_MODE, SET_bitMode, SET_FREQ, GET_FREQ

                        long    LOOP[/color]                    '' catch all      (optional if frontend handles it)

cmsk                    long    SPI_FUNC_BITS

Right now all I get is cog_addr * 4, adding a /4 throws an error.

Comments

  • ersmithersmith Posts: 6,053
    edited 2014-09-08 05:08
    For the most recent assembler (binutils version 2.23.1) add a ".pasm" directive at the top of the file to get very PASM like behavior, including what you asked for.

    For older assemblers, like the one that ships with simpleIDE, the directive is ".cog_ram" and it's not nearly as reliable (or PASM like).
  • kuronekokuroneko Posts: 3,623
    edited 2014-09-08 07:11
    Thanks! .cog_ram doesn't seem to have any effect. I assume adding it at the top of the file like the other directives is the way to go? Will try .pasm when I get hold of a more recent assembler. For now I use a mov label, label for each table entry as a workaround.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-09-08 08:47
    which version of PropGCC (presumably the answer to this is a mercurial branch?) is needed to get 2.23.1? Is it stable enough for consumer use? If not, is there an ETA?

    Looking forward to the .pasm directive. Sounds like it could be a great improvement! :)
  • ersmithersmith Posts: 6,053
    edited 2014-09-08 10:34
    2.23.1 is on the default mercurial branch, so if you're building from source that's probably what you have (unless you deliberately chose the release_1_0 branch). I think it's stable enough for consumer use; it's what I've been using myself for more than a year. I don't know when/if it will be released "officially"; that depends on Parallax's requirements and schedule, The release_1_0 branch is "good enough" for most peoples' purposes, evidently. I do encourage anyone who is up for building from source to try the default branch out; the more experience it gets in the field, the more comfortable everyone can be with putting it into an official release.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-09-08 10:38
    ersmith wrote: »
    2.23.1 is on the default mercurial branch, so if you're building from source that's probably what you have (unless you deliberately chose the release_1_0 branch). I think it's stable enough for consumer use; it's what I've been using myself for more than a year. I don't know when/if it will be released "officially"; that depends on Parallax's requirements and schedule, The release_1_0 branch is "good enough" for most peoples' purposes, evidently. I do encourage anyone who is up for building from source to try the default branch out; the more experience it gets in the field, the more comfortable everyone can be with putting it into an official release.

    Great :) that's exactly what I was hoping for. I'll go ahead and rebuild PropWare's Linux PropGCC release based on the default branch instead of release_1_0. Time to give cross-compiling a try as well it seems so that our Windows/Mac users aren't lagging behind.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-09-08 10:38
    ersmith wrote: »
    2.23.1 is on the default mercurial branch, so if you're building from source that's probably what you have (unless you deliberately chose the release_1_0 branch). I think it's stable enough for consumer use; it's what I've been using myself for more than a year. I don't know when/if it will be released "officially"; that depends on Parallax's requirements and schedule, The release_1_0 branch is "good enough" for most peoples' purposes, evidently. I do encourage anyone who is up for building from source to try the default branch out; the more experience it gets in the field, the more comfortable everyone can be with putting it into an official release.
    FYI, the default branch also moves to a different interface to external memory drivers. The bad news is that the old XMM drivers will no longer work. The good news is that the important drivers have been ported to the new interface and writing new drivers is much easier now since they only need read/write block. The cache logic has all been moved to the XMM kernel. Anyway, that's something to keep in mind if you decide to move to the default branch and are currently using XMM. Also, the default branch supports multiple COGs running XMM code at the same time. This is not true of the release_1_0 branch.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-09-08 10:42
    David Betz wrote: »
    FYI, the default branch also moves to a different interface to external memory drivers. The bad news is that the old XMM drivers will no longer work. The good news is that the important drivers have been ported to the new interface and writing new drivers is much easier now since they only need read/write block. The cache logic has all been moved to the XMM kernel. Anyway, that's something to keep in mind if you decide to move to the default branch and are currently using XMM. Also, the default branch supports multiple COGs running XMM code at the same time. This is not true of the release_1_0 branch.

    I have no experience with any of the XMM modes (no supporting hardware currently). Do you see your above comments posing a problem for what is supposed to be a portable and robust build system that is hopefully compatible with as many different existing projects as possible?

    It certainly isn't the end of the world if a few people have issues. PropWare does allow for multiple installations of PropGCC and each project (or all PropWare projects) can select whichever one they please - they don't have to use PropWare's default version.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-09-08 10:45
    SwimDude0614 wrote: »
    I have no experience with any of the XMM modes (no supporting hardware currently). Do you see your above comments posing a problem for what is supposed to be a portable and robust build system that is hopefully compatible with as many different existing projects as possible?

    It certainly isn't the end of the world if a few people have issues. PropWare does allow for multiple installations of PropGCC and each project (or all PropWare projects) can select whichever one they please - they don't have to use PropWare's default version.
    The only potential problem I can see with adopting the default branch is that someone with a custom XMM driver will have to rework it for the new interface. That mostly involves removing code. Also, you *do* have a hardware platform that can use XMM if you have a Propeller board with at least 64k of EEPROM. Steve wrote an EEPROM XMM driver a while back that will let you run larger programs on stock Propeller boards. I think almost every board that Parallax sells now has a 64k EEPROM.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-09-08 10:49
    David Betz wrote: »
    The only potential problem I can see with adopting the default branch is that someone with a custom XMM driver will have to rework it for the new interface. That mostly involves removing code.

    Custom XMM driver? Doesn't sound like an issue for 99% of users.
    David Betz wrote: »
    Also, you *do* have a hardware platform that can use XMM if you have a Propeller board with at least 64k of EEPROM. Steve wrote an EEPROM XMM driver a while back that will let you run larger programs on stock Propeller boards. I think almost every board that Parallax sells now has a 64k EEPROM.

    Great! I'll give it a try on my Quickstart then. That will be very cool :)
  • kuronekokuroneko Posts: 3,623
    edited 2014-09-09 18:42
    OK, .pasm works with the exception that e.g. jmpret $, $+1 doesn't. While $ is recognized, $+1 is rounded down to $. This only has the intended effect when I use $+4 but that's GAS style, not PASM.
  • ersmithersmith Posts: 6,053
    edited 2014-09-12 13:19
    kuroneko wrote: »
    OK, .pasm works with the exception that e.g. jmpret $, $+1 doesn't. While $ is recognized, $+1 is rounded down to $. This only has the intended effect when I use $+4 but that's GAS style, not PASM.

    Thank you for finding that... jmpret $, #$+1 worked, but we weren't processing non-immediate source registers (and for that matter destinations). I've checked in a fix for that.

    Regards,
    Eric
  • kuronekokuroneko Posts: 3,623
    edited 2014-09-14 17:36
    ersmith wrote: »
    ... I've checked in a fix for that.
    Appreciated.
Sign In or Register to comment.