Shop Learn P1 Docs P2 Docs
Spin Tools IDE — Parallax Forums

Spin Tools IDE

maccamacca Posts: 483
edited 2022-03-07 07:58 in Propeller 2

Hello,

Sometimes ago I proposed a new enhanced IDE for spin programs. Despite the low interest, I continued to develop the tool for my own needs, it is still a bit rough on some aspects but I believe it is now ready for an official presentation.

Here is the new Spin Tools IDE:

The interface shows the file browser, the code editor with syntax highlight and the code outline view.

The code is compiled in realtime while it is typed and errors are shown immediately, without the need to push a compile button. The code can be easily navigated by ctrl-clicking on a method to move to its definition.

Hovering on a method name shows the description if available:

Code assist shows the linked object methods and descriptions:

The outline view shows the sections and public labels, PUB/PRI methods are shown with the parameters and return values. Comments on the section keyword line are also displayed for easy navigation.

Compared to Propeller Tools there are some differences:

  • Local variables can have the same name as global variables, there is a warning highlight when a local variable hides a global variable so you know what happens.
  • All constants are calculated as 64 bit integers and masked as 32 bit when the result is used.
  • Integer and floating point values can be used on the same expression.
  • The F8 information window also shows the bytecode listing.
  • Debug statements are not yet supported.

The binary packages for Linux, Windows and MacOS can be downloaded from here (requires the Java SE 8 or later runtime already installed).

The source code is not yet published.

Beware that this is a work in progress, while I do my best to make the compiler working, I'm certain that there are still some bugs so if something appears to not work as expected, try with Propeller Tools or PNut. All libraries and examples included in the package are tested to produce byte-exact binaries with Propeller Tools, with some exceptions due to floating point approximations or expression operations sequence that doesn't alter the results.

As usual, use at your own risk!

Hope you enjoy!

Comments

  • PublisonPublison Posts: 12,340

    @macca
    Thank you for you efforts! I'm sure this will be useful.

  • Wuerfel_21Wuerfel_21 Posts: 2,996
    edited 2022-03-04 13:03

    Begets this on startup, but seems to work otherwise. There is no log file created, so IDK what it's on about.

    LED blinker works, so, yeah, cool.

    Immediate "criticism" from messing around for 10 minutes:

    • no DEBUG (if you need a reference on how to generate debug bytecode, I've done it before)
    • no Align mode
    • no block-select/multi-cursor
    • no preprocessor (and seems to choke on trying to parse #directives)
    • Spin compiler doesn't take @"string" syntax
    • has the same issue as proptool where it will only compile a P2 program after saving it to a file
    • PTRx/Px use the same highlighting class as instructions. In proptool they're bold black, not red. Perhaps a taste issue.
    • Spin compiler is just as intelligent as PNut (I guess that's a feature-not-a-bug tho). At least there's unused method elimination
  • maccamacca Posts: 483

    @Wuerfel_21 said:
    Begets this on startup, but seems to work otherwise. There is no log file created, so IDK what it's on about.

    I should have known, a small first-time use issue. Will fix soon.

    Immediate "criticism" from messing around for 10 minutes:

    Yes, I wrote that, I'll look at your code.

    • no Align mode

    If you mean the alignl/w keywords, they should work. Otherwise what you mean ?

    • no block-select/multi-cursor
    • no preprocessor (and seems to choke on trying to parse #directives)

    Not planned to be added in the near future. Of course unsupported syntax can cause all sort of issues.

    • Spin compiler doesn't take @"string" syntax

    That's a new feature introduced with one of the most recent versions of PNut (does Propeller Tools already supports that ? I don't know), I'll add it when I understand what it is used for.

    • has the same issue as proptool where it will only compile a P2 program after saving it to a file

    Nope, it all depends on the file extension even when not saved. There are 3 new file commands, new P1 template compiles for P1, new P2 template compiles for P2, but if you use the new alone it attempts to create a new file based on the currently opened editor (p1 or p2), of course if there are no open editors it has to select a default which is p1. This may be a selection in the future preferences dialog.

    • Spin compiler is just as intelligent as PNut (I guess that's a feature-not-a-bug tho). At least there's unused method elimination

    Keep in mind that I did that by reverse engineering the generated code, even now that the PNut source is available I find more easy to reverse engineer it rather than looking at the assembler code, so the first goal was to produce the same binaries. Further optimizations may be added in the future if there is enough interest and/or collaboration.

  • maccamacca Posts: 483

    @Wuerfel_21 said:

    • Spin compiler doesn't take @"string" syntax

    I found the description of that. With my compiler you don't need the @ just use the string:
    ser.str("Hello, World")

    Should also work for P1 sources.

  • @macca said:

    • no Align mode

    If you mean the alignl/w keywords, they should work. Otherwise what you mean ?

    I mean the "Align" editor mode you can get in proptool by pressing Insert twice. When it is enabled, typing while there are at least two spaces after the cursor will overwrite the first space and when deleting a character, a space is added to the next run of two or more spaces. Invaluable for ASM, I think.

    • Spin compiler doesn't take @"string" syntax

    That's a new feature introduced with one of the most recent versions of PNut (does Propeller Tools already supports that ? I don't know), I'll add it when I understand what it is used for.

    It's been in flexspin for ages, just recently convinced Chip to add it, too. It's basically the same thing as string("string")

    Keep in mind that I did that by reverse engineering the generated code, even now that the PNut source is available I find more easy to reverse engineer it rather than looking at the assembler code, so the first goal was to produce the same binaries. Further optimizations may be added in the future if there is enough interest and/or collaboration.

    Yeah the PNut source is basically indecipherable. I tried to get binary matches with flexspin's P1 bytecode at first, too, but gave up on that because the frontend just isn't built for that. The most obvious/easy-to-implement bytecode optimizations, off the top off my head. They're all really simple no-brainers:

    • On P1, emit the 8 bit constant opcode instead of the bit constant opcode when both are possible (such as with 2,4,8,etc). The former is a few cycles faster.
    • If branch condition is a constant expression (which should be easy to tell if you can fold them), compile to unconditional branch/no branch
    • For REPEAT N on P1 (not sure if it applies to P2, too), omit the TJZ bytecode if the repeat count is constant and not zero.
    • If an unconditional branch goes to a small terminal opcode like a return OR another unconditional branch, replace the branch with that.
    • If a conditional branch jumps over one unconditonal branch, replace with the opposite conditional branch.
    • After the function is compiled, delete all code between a terminal opcode (unconditional branch, return, etc) and a branch target (depending on your IR, you have to remove unused labels first).
    • All bytecode level optimizations should be repeated until nothing changes anymore.
  • @macca said:

    @Wuerfel_21 said:

    • Spin compiler doesn't take @"string" syntax

    I found the description of that. With my compiler you don't need the @ just use the string:
    ser.str("Hello, World")

    Should also work for P1 sources.

    That is very very wrong. An unqualified string literal is supposed to be an integer.

  • maccamacca Posts: 483

    @Wuerfel_21 said:

    @macca said:

    @Wuerfel_21 said:

    • Spin compiler doesn't take @"string" syntax

    I found the description of that. With my compiler you don't need the @ just use the string:
    ser.str("Hello, World")

    Should also work for P1 sources.

    That is very very wrong. An unqualified string literal is supposed to be an integer.

    Yes, but it is confusing only when the string is one character.
    Maybe I'll add the @ syntax to cover what I believe is an edge case of a single char string passed as argument.

  • @macca said:
    Yes, but it is confusing only when the string is one character.

    I was about to say that you can actually have constants of up to four characters in an integer, but I guess there's some sort of mandela effect Smile going on, because it doesn't seem to actually work that way in proptool. I remember it working that way, but apparently not.

  • maccamacca Posts: 483

    Posted version 0.11:

    • Added support for spin floating point
    • Initial support for debug statements
    • Implemented @"String" for compatibility
    • Command line compiler
    • Some general fixes
Sign In or Register to comment.