P2 TOOLS: P2PASM, Fastspin, SpinGUI, VScode, etc

Cluso99

I am setting up a new (old) faster desktop to replace my slow laptop. I'm a W10 user. In the process, I am adding all the P1 & P2 tools.

My previous P1 & P2 development used PropTool almost exclusively for editing both P1 & P2 source code (I use .spin for P2 so I have the color highlighting). I mostly use pnut to compile P2 although I use P2PASM when I need a listing. I use PST as my terminal program of choice - it's very basic but works fine for what I do.

This is a point where I think a change to use new tools could help me.

So...

Editor

Choices...
* PropTool - Windoze only, works, and known entity
* Spin2Gui - What platforms, does it do highlighting, any other benefits, underlying editor ???
* Visual Studio Code - Cross-platform, has spin add-on. What are the benefits ???
* Notepad++ - Windoze only, currently no spin add-on (was an add-on done by Saphieha but lost?) - I know this quite well.
Any others?

What do you, the users recommend going forward?

Compiler

Choices...
* pnut - Windows only, currently the reference, but don't expect we will ever see the features we all want such as #ifdef, etc
* P2PASM - What platforms? Good listing output. Other benefits ???
* Fastspin - What platforms? Listing? Compiles to both P1 & P2, compiles spin to PASM 1 & 2, supports PASM, Spin, Basic, some C/C#. Other benefits ???
* OpenSpin - What platforms? Currently P1 only. Supports conditional compile, P1 spin & pasm. (listed for reference)
Any others?

What do you, the users recommend going forward?

Roy Eltham

I most likely will use fastspin as my compiler of choice, I think parallax should get behind it as the primary one. The easy mixing of languages include PASM is great, and it does both P1 and P2.

As for editors/IDE, everyone has their own preferences, I'll probably use VS Code and do mostly C/C++ (Eric has state he plans to add some C++ like features to his C fastspin stuff).

If parallax wants me to do OpenSpin for P2, then I guess I will, but it will take a while, and Chip needs to send me the x86 source he is working on for the compiler portion that PNut interfaces to. I got a very old version from him, but that's not even anywhere close to compatible with the P2-ES or new FPGA stuff. Of course, since he is heavily changing/adding to it for Spin2, I'm not sure getting it now will be benificial, if I just have to redo a bunch of stuff every time I get a new update. I'm more inclined to just try and convince them to help Eric make fastspin the standard.

Cluso99

Roy Eltham wrote: »

I most likely will use fastspin as my compiler of choice, I think parallax should get behind it as the primary one. The easy mixing of languages include PASM is great, and it does both P1 and P2.

As for editors/IDE, everyone has their own preferences, I'll probably use VS Code and do mostly C/C++ (Eric has state he plans to add some C++ like features to his C fastspin stuff).

If parallax wants me to do OpenSpin for P2, then I guess I will, but it will take a while, and Chip needs to send me the x86 source he is working on for the compiler portion that PNut interfaces to. I got a very old version from him, but that's not even anywhere close to compatible with the P2-ES or new FPGA stuff. Of course, since he is heavily changing/adding to it for Spin2, I'm not sure getting it now will be benificial, if I just have to redo a bunch of stuff every time I get a new update. I'm more inclined to just try and convince them to help Eric make fastspin the standard.

Thanks Roy.
Agreed, it would be better to put the effort into one compiler and Eric has done a splendid job as far as I can tell.

That leaves P2ASM. Any insights ???

Who will support Spin/Spin2 to bytecode ???

Roy Eltham

fastspin does P2ASM.

Wuerfel_21

I use VSCode a lot, but not for Spin (Spin 1 due to lack of P2,lol), since the Spin plugin is kindof meh, it doesn't do the funky colors and it doesn't highlight PASM mnemonics. Would be nice if someone could improve it.

What any editor really needs is the "Align" mode and the context-sensitive indenting from PropTool.

Pnut is going to be written in x86 ASM again? Why though? Considering how """slow""" PropTool sometimes is when compiling large programs on an almost 3.9 GHz CPU over a decade after it was written, I don't think it helped much there.

Cluso99

I've spent the afternoon looking at improving the spin extension for VS Code. While I can wrangle my way around the extension there are some basics missing. The tutorials from MS refer to commands in VS Code which just don't exist. Obviously I am missing something serious here!

Cluso99

Roy Eltham wrote: »

fastspin does P2ASM.

Thanks Did not know that.

Roy Eltham

Wuefel_21,
Chip basically took the P1 x86 compiler/assembler and morphed over time into the P2 one he is working on now. That is what he prefers. The slowness you are referring to is because of how his code looks up symbols. If you have a lot of symbols it gets slower. OpenSpin does not suffer from this issue, and compiles most programs much faster than the x86 code does. Mainly because I use a hash table with fast lookups for the symbols, but also because it's compiled with a modern C++ compiler that takes advantage of the latest CPU instructions and features.

Cluso99,
You might need to install some extra stuff intended for extension development in order to get those commands? I haven't looked into any of that yet, but I will when I have time.

Cluso99

Here is VS Code extension(s) for P2 spin & pasm. Spin2 & Theme2 fo want of better names.
It's a wip and has nasty colors so I can ensure they work.
Currently I am highlighting the pasm opcodes, conditional execution (if_nz etc) and set codes (wcz etc). The others came from the base code that I used.

BTW I used the current spin extension from https://github.com/Entomy/Spin-vscode as the starting point, so thanks to "entomy" for the work done previously

Install the unzipped files in %userprofile%\.vscode\extensions\

cgracey

Wuerfel_21 wrote: »

I use VSCode a lot, but not for Spin (Spin 1 due to lack of P2,lol), since the Spin plugin is kindof meh, it doesn't do the funky colors and it doesn't highlight PASM mnemonics. Would be nice if someone could improve it.

What any editor really needs is the "Align" mode and the context-sensitive indenting from PropTool.

Pnut is going to be written in x86 ASM again? Why though? Considering how """slow""" PropTool sometimes is when compiling large programs on an almost 3.9 GHz CPU over a decade after it was written, I don't think it helped much there.

Yes. Roy discovered during a rewrite to C that the PNut compiler was slow because it was always looking up symbols. He changed the symbol table to use a 128KB hash table, and things sped WAY up.

I'm still in x86 land with PNut because that's what my code base is in. A lot of this work was done in 1992 for the BASIC Stamp, and has been modified ever since for every other assembler/compiler I've made. It's a pain, at this point, but it's KNOWN to me.

My intention now is to finish the Spin2 compiler in this x86 framework, meld it into the PropTool, and then rewrite the Spin2 compiler in Spin2, making the whole thing stand-alone, so that it can ultimately run on the P2. I want to make it all work with minimal overhead, so that some really tight development and debugging can be achieved. The goal is to make something that is super efficient and fun to work on. I want to cut the code-change/response loop time by at least 90% and enable very clear feedback to the programmer. I want the programmer to know exactly where he stands and be able to get any info he needs easily. I want it to be an experience that can't be replicated on PC's.

It may be that Eric's and Ross's tools become the standard for most developers. That would be great, but I still want to follow through with what I've been thinking about for so long. It's an experiment, of sorts, and I don't know where it will lead, but I want to pursue it.

Roy Eltham

The main hashtable could be 1/8th the size and still gain most of the speed up benefit. I just chose that size since 128KB is tiny on most modern PCs, and it gave a small improvement for the worst cases.
Also, technically it's 3 hashtables, one for the built in symbols (4KB), the main one for user symbols (128KB), and one for temporary symbols that gets wiped during the compiles (16K). You could shrink the main one to 16KB, and the temp one to 4KB, and still be quite a bit faster than the linear array search.

Rayman

I couldn't find a Spin2 editor I liked, so I made my own!
SpinEdit (work in progress)

Has all the Spin 1 compilers, and Basic and C too...

can find it here:
http://forums.parallax.com/discussion/169259/spinedit-editor-for-spin-spin2-and-fastbasic/p1

dgately

Cluso99 wrote: »

Here is VS Code extension(s) for P2 spin & pasm. Spin2 & Theme2 fo want of better names.
It's a wip and has nasty colors so I can ensure they work.

Using Visual Studio Code works quite well and with your spin2 extension and theme2, it's much better than just using a Terminal for editing (lot's of code developer options in the VSC editor)!

With the Terminal window displayed at the bottom, I can use fastspin, p2asm, loadp2 or a python script I wrote that keeps me from having to remember loadp2's options

And, VSC works on Win, macOS & Linux!

I'm a convert! Thanks, Cluso99!

dgately

Wuerfel_21

cgracey wrote: »

I want to cut the code-change/response loop time by at least 90% and enable very clear feedback to the programmer.

A very noble endeavor. I'm currently working with/on XMM on P1 and the "code-change/response loop"
looks like this:
1. Change code
2. Compile
4. Reset board (don't want to pull out the card while it's being used)
3. Fumble microSD out of the board and into the PC
4. Copy XMM file to card
5. (sometimes) get told the card is write protected, pull it out and move that pesky slider, go back to step 3
5. Unmount card
6. Fumble card back into board
7. Compile/Upload Kernal from PropTool
8. Wait for it to do the thing
9a. Notice you made a dumb mistake, go back to step 1
9b. Get completely baffling problem, bang head against wall, go back to step 1

I'd love to get 90% off of that!

This particular scenario would be significantly less annoying if I could edit and compile the code directly on the Prop (which has all the necessary peripherals connected to it, anyways). OTOH, I like being able to view the code and the label<->address mappings and such while the code is running....

David Betz

Wuerfel_21 wrote: »

cgracey wrote: »

I want to cut the code-change/response loop time by at least 90% and enable very clear feedback to the programmer.

A very noble endeavor. I'm currently working with/on XMM on P1 and the "code-change/response loop"
looks like this:
1. Change code
2. Compile
4. Reset board (don't want to pull out the card while it's being used)
3. Fumble microSD out of the board and into the PC
4. Copy XMM file to card
5. (sometimes) get told the card is write protected, pull it out and move that pesky slider, go back to step 3
5. Unmount card
6. Fumble card back into board
7. Compile/Upload Kernal from PropTool
8. Wait for it to do the thing
9a. Notice you made a dumb mistake, go back to step 1
9b. Get completely baffling problem, bang head against wall, go back to step 1

I'd love to get 90% off of that!

This particular scenario would be significantly less annoying if I could edit and compile the code directly on the Prop (which has all the necessary peripherals connected to it, anyways). OTOH, I like being able to view the code and the label<->address mappings and such while the code is running....

Why can't you just let propeller-load write the file to the SD card while it is still inserted in the Propeller board?

Wuerfel_21

I should probably do that, but I must say that I've never gotten anything that isn't PropTool to reliably boot the Prop. (also I've never gotten the automatic reset circuit to work quite right, so I've got that disconnected and have to push reset manually when uploading).
Does propeller-load try to keep the file in contiguous clusters? That is quite important to me.
(Further discussion of this should be moved to another thread...)

cgracey

Wuerfel_21 wrote: »

cgracey wrote: »

I want to cut the code-change/response loop time by at least 90% and enable very clear feedback to the programmer.

A very noble endeavor. I'm currently working with/on XMM on P1 and the "code-change/response loop"
looks like this:
1. Change code
2. Compile
4. Reset board (don't want to pull out the card while it's being used)
3. Fumble microSD out of the board and into the PC
4. Copy XMM file to card
5. (sometimes) get told the card is write protected, pull it out and move that pesky slider, go back to step 3
5. Unmount card
6. Fumble card back into board
7. Compile/Upload Kernal from PropTool
8. Wait for it to do the thing
9a. Notice you made a dumb mistake, go back to step 1
9b. Get completely baffling problem, bang head against wall, go back to step 1

I'd love to get 90% off of that!

This particular scenario would be significantly less annoying if I could edit and compile the code directly on the Prop (which has all the necessary peripherals connected to it, anyways). OTOH, I like being able to view the code and the label<->address mappings and such while the code is running....

I think in that torturous case, the savings would be more like 99%. I've found that faster turnaround times enable your brain to keep working, while long waits cause your brain to dump and then it must respool, which is always lossy. I really think the P2 hardware development could have been years faster if I didn't have to wait 15 minutes, or more, just to try a change on the FPGA. You can get old and loose your mind in such a scenario.

To make things even better, there needs to be fast, full-screen 60fps debug information available. No sucking data through a straw with multi-second latencies. If the development experience can keep pace with your brain, productivity would be improved by at least one order of magnitude.

ke4pjw

David Betz wrote: »

Why can't you just let propeller-load write the file to the SD card while it is still inserted in the Propeller board?

I do something similar where a secondary boot image is located in the upper 32K of the EEPROM. I update it via a special character sequence on the FT-245 interface and send the data via xmodem. When the P1 boots, it looks to see if an image exists in the upper 32K and then boots from that. The base image is special, and is the only image that knows to look for a secondary image. It allows you to revert to the base image by holding a pin low at power on.

Cluso99

For P1, use my OS. It can download to SD and can run any binary from SD. There is a whole set of DOS like functions.

Also, there is a P1 compiler that Michael Park originally wrote that runs on P1. I converted it to run on my OS, but not highly tested. It was based on his homespun P1 compiler as used in Catalina with small mods. Alas there is no editor unless you resort to CPM

Cluso99

Chip,
How is spin2 coming along?

Been distracted for a few weeks so getting P1 spin running on P2 stalled. If you’re close then maybe not worth continuing ???

cgracey

Cluso99 wrote: »

Chip,
How is spin2 coming along?

Been distracted for a few weeks so getting P1 spin running on P2 stalled. If you’re close then maybe not worth continuing ???

It's coming along. I'm working from the outside inwards, so that the last thing to do will be the bytecode generation. Today I'm getting all the Spin2 operators sorted out, so that I can get the expression resolver working.

Cluso99

cgracey wrote: »

Cluso99 wrote: »

Chip,
How is spin2 coming along?

Been distracted for a few weeks so getting P1 spin running on P2 stalled. If you’re close then maybe not worth continuing ???

It's coming along. I'm working from the outside inwards, so that the last thing to do will be the bytecode generation. Today I'm getting all the Spin2 operators sorted out, so that I can get the expression resolver working.

Is any of the spin2 bytecode the same as spin1?

msrobots

I am using spin2gui mostly since it is one download to have all together.

Since I am hammered with real work I do need to reload all my tools every time I start working on the P2 again.

Sometimes Eric does 3-5 changes per week. Like @"Roy Eltham" I think Parallax should fully support @ersmith for doing so, fastspin is a wonderful concept, not just the multi-language and P1/P2 support but also his Spin2-extensions.

The only thing missing would be P1 and P2 byte code generation, but I am way to in AWE what Eric has done so far to even ask for.

@Cluso99, your extension is super cool. I normally use Visual Studio so VS code was not on my radar for a while and has matured a lot since I looked last. You mentioned CP/M again, last time I asked you, you said you are redoing your boards. Can I buy one P1 CP/M able board from you now?

And, yes I think a Spin1 byte code Interpreter for the P2 is a valuable tool, because Chips new Spin2 byte code interpreter might not be able to run Spin1 code.

Somehow @Heater is missing for a while now, I would like to tease him to write another emulator, something like gears for the P2, a P1 emulator for the P2.

That would solve any upgrade issue...

Anyways,

Mike

cgracey

Cluso99 wrote: »

cgracey wrote: »

Cluso99 wrote: »

Chip,
How is spin2 coming along?

Been distracted for a few weeks so getting P1 spin running on P2 stalled. If you’re close then maybe not worth continuing ???

It's coming along. I'm working from the outside inwards, so that the last thing to do will be the bytecode generation. Today I'm getting all the Spin2 operators sorted out, so that I can get the expression resolver working.

Is any of the spin2 bytecode the same as spin1?

No, It's quite a different animal.

Cluso99

VS Code Spin2/PASM2 update attached.
As above, unzip to %userprofile%/.vscode/extensions

This is best viewed using the theme Cobalt2

I'll start a new VS Code thread soon.

Here is a pic

Roy Eltham

@Cluso99 no update was attached? Just the picture.

ozpropdev

Cluso99
BTW There also is Seairth's thread here with more VScode stuff.

dgately

Cluso99 wrote: »

VS Code Spin2/PASM2 update attached.
As above, unzip to %userprofile%/.vscode/extensions

on macOS & Linux, unzip to: ~/.vscode/extensions

Cluso99

Oops. Here is the code

hinv

cgracey wrote: »

Wuerfel_21 wrote: »

I use VSCode a lot, but not for Spin (Spin 1 due to lack of P2,lol), since the Spin plugin is kindof meh, it doesn't do the funky colors and it doesn't highlight PASM mnemonics. Would be nice if someone could improve it.

What any editor really needs is the "Align" mode and the context-sensitive indenting from PropTool.

Pnut is going to be written in x86 ASM again? Why though? Considering how """slow""" PropTool sometimes is when compiling large programs on an almost 3.9 GHz CPU over a decade after it was written, I don't think it helped much there.

Yes. Roy discovered during a rewrite to C that the PNut compiler was slow because it was always looking up symbols. He changed the symbol table to use a 128KB hash table, and things sped WAY up.

I'm still in x86 land with PNut because that's what my code base is in. A lot of this work was done in 1992 for the BASIC Stamp, and has been modified ever since for every other assembler/compiler I've made. It's a pain, at this point, but it's KNOWN to me.

My intention now is to finish the Spin2 compiler in this x86 framework, meld it into the PropTool, and then rewrite the Spin2 compiler in Spin2, making the whole thing stand-alone, so that it can ultimately run on the P2. I want to make it all work with minimal overhead, so that some really tight development and debugging can be achieved. The goal is to make something that is super efficient and fun to work on. I want to cut the code-change/response loop time by at least 90% and enable very clear feedback to the programmer. I want the programmer to know exactly where he stands and be able to get any info he needs easily. I want it to be an experience that can't be replicated on PC's.

It may be that Eric's and Ross's tools become the standard for most developers. That would be great, but I still want to follow through with what I've been thinking about for so long. It's an experiment, of sorts, and I don't know where it will lead, but I want to pursue it.

I've been away for a while and can't get BST to work right anymore on linux. I just don't do windows, and wine doesn't look that good. Though fastspin and fastbasic sound's good, I really like the self hosting dev environment idea. I would love to have everything I need on a P2 demoboard, and for the P1 as well, even if I don't get emacs . I get your vision, Chip, and am fully on board with it as long as I can load other P2's and P1's with it as well.

evanh

hinv wrote: »

I've been away for a while and can't get BST to work right anymore on linux. I just don't do windows, and wine doesn't look that good. Though fastspin and fastbasic sound's good, ...

Dave Hein's "loadp2" comes with Fastspin Spin2gui (Actually, I've always compiled from Dave's sources directly). Loadp2's -t terminal is a huge help the way it immediately starts after program download. I still check in with Pnut on occasion (Pnut runs on Wine) to verify I'm making compatible code but once I was confident in accuracy of Fastspin it was much easier to use that because it could be combined with loadp2 in a single action.

https://forums.parallax.com/discussion/comment/1461005/#Comment_1461005

I'm happily using a generic text editor so I haven't even tried Spin2Gui yet. I wouldn't be surprised if I'm missing out on something handy there as well.