PropellerIDE was cool but like SimpleIDE it seems to have been abandoned.

When we say it's abandoned, people will think it is abandoned. I've used it recently and it works fine.

Did you request some changes or fixes to the developer but received no reply?

Ken Gracey

Not me. I've never really used either one. I'm more of a command line guy. I've just heard people in the forum talk about needing updates to both. By "abandoned" I didn't mean they weren't still usable. They're just not being actively developed.

Cluso99,
I agree that it's a mistake to update PropTool for P2. It will be a roadblock to all other tool/compiler development, because everyone will just use it instead of better tools because it's what Parallax provides. And then anyone not on Windows will complain about the lack of official tools that are cross platform, just like they do now with the P1 (even though there are cross platform solutions all over, including on parallax's site), because most people seem to see PropTool as the official standard and everything else as not official.

It's a real problem that the only official compiler for P2 is hand written in x86 asm and won't run on anything but windows, and we can't do anything about it until Chip's done and then it gets ported to C/C++ so that it can be build for any platform.
It will take far too long if you all rely on me to do it in my spare time, it needs to be a group effort or be officially funded/built by parallax. I think they should focus on getting the compiler to work cross platform as a command line tool, and leverage the plethora of existing IDEs that are way way way better than PropTool or SimpleIDE or PropellerIDE. Why waste time updating and supporting your own IDE?

Ken,
Sad to say it, but PropellerIDE and SimpleIDE are abysmal to use for anything beyond the most basic stuff. They actively get in the way of the coder writing code. Reformatting things as I type, getting into states where I am forced to hit escape or tab or something to get back to being able to type what I want, incorrectly hilighting the code making the hilighting useless since I can't rely on it to be right, etc. etc. etc. For C++, I literally edit all my code in VS Code or Notepad++, then switch over to SimpleIDE to just compile and load it into the prop, because it's so much less frustrating.

If we had GCC, I think I'd use Visual Studio Professional to edit code...
I think there's a free "Community" version too now...
I used it before with Catalina and GCC for P1.
I may try it with Catalina and/or FastSpin …

I've always said I'd switch from Spin to C when P2 came out... Guess it's about time to see if that's true or not... I am having some second thoughts...

The SpinEdit program I wrote is skeletal, but does show how one program could generate code for P1 and P2 with several different languages and compilers (mostly from FastSpin) (and probably could be made to run on other OS's using Wine)...

I would be in favor of making C (NOT C++) the index language for P2. The main problem with C on P1 was that C assumes a hardware stack which P1 didn't have, and P1 had to load a custom interpreter since the Spin byte code interpreter also wasn't appropriate. But with native support for its implementation quirks C isn't really that much different from Spin. It was also after all originally developed for efficient use of limited resources.

I don't think this C implementation needs to be or even should be generic or open-source; I think the editor should work like the PropTool with tight integration to the platform. The Prop version should be fully documented, like Spin is, with appropriate libraries for common hardware functions like serial, PASM and C cog control, and features like string handling. Library source should pop up in the editor with a single click, like Obex files do in the PropTool, so one doesn't have to go digging through multiple directories or on the Internet to figure out what functions and arguments are supported (*cough* I'm lookin' at you, Arduino *cough*).

There should be no goddamn header files. It's 2019, we can write a forward referencing compiler today.

Do this, you essentially have the same thing you do now for P1 except with brackets and parentheses instead of white space and you can tell people "and it can be programmed in C" without adding that it's awkward and crippling to do so.

I don't know the level of effort would be required, but Visual Studio Code + Eric's FlexBASIC, C, and FastSpin + Chip's Spin2 interpreter would be a winning combination.
It is cross platform. It plugs you into the git ecosystem. You might be able to wire it up to the debugger.

It may be too far fetched, but it aligns with:
Use of github.
The requirement to not own the editor.
Being cross platform.
Being community based.
Being familiar to users.

I am ignorant of the challenges of wiring all of that together, but I think it would make for a sexy, robust build system.

I don't know the level of effort would be required, but Visual Studio Code + Eric's FlexBASIC, C, and FastSpin + Chip's Spin2 interpreter would be a winning combination.
It is cross platform. It plugs you into the git ecosystem. You might be able to wire it up to the debugger.

It may be too far fetched, but it aligns with:
Use of github.
The requirement to not own the editor.
Being cross platform.
Being community based.
Being familiar to users.

I am ignorant of the challenges of wiring all of that together, but I think it would make for a sexy, robust build system.

Yes, that has already been suggested a number of times, and I think the 'wire it up to the debugger' is a very crucial step that Parallax needs to give some priority to .
There are choices for editors, but if Parallax want to play with the grown-ups, some full GUI/Editor integrated debug support is going to be needed on P2, on all Languages.

It appears VS Code is being used now with Cortex and RISC-V, so there must be debug-paths in there.

I don't know the level of effort would be required, but Visual Studio Code + Eric's FlexBASIC, C, and FastSpin + Chip's Spin2 interpreter would be a winning combination.
It is cross platform. It plugs you into the git ecosystem. You might be able to wire it up to the debugger.

It may be too far fetched, but it aligns with:
Use of github.
The requirement to not own the editor.
Being cross platform.
Being community based.
Being familiar to users.

I am ignorant of the challenges of wiring all of that together, but I think it would make for a sexy, robust build system.

I assume you're talking about Chip's rewrite of his x86 compiler in Spin? Certainly the x86 compiler won't be cross platform.

I think the big thing with debugging is we have to admit debugging is single-cog, and that the other cogs are gonna spin along if the debugger breaks execution. That has implications that aren't ordinary for debugging, so it's not quite as simple as it is on other platforms. But a working single-cog debugger would still be a big help for application business logic.

I assume you're talking about Chip's rewrite of his x86 compiler in Spin? Certainly the x86 compiler won't be cross platform.

My understanding is Chip is working on an interpreter, not a compiler. But yes, it would re-written in spin to be self hosted. Even if it is an x86 executable, with the exception of the ARM Pi platform, everything worth using these days is X86/X64.

Chip is working on a compiler to byte code which would then be executed by a cog loaded interpreter on the Propeller. The interpreter would be written in PASM, but Chip is writing the byte code compiler in x86 ASM because I guess he's just a masochist (ducks) OK it's a familiar development path for him.

That's my plan. I've just been stuck on silicon issues. I think I'm free again, though, now that ON Semi has probably found the cause of the latch-up problem and they will make some simple layout changes to remedy it.

I'm working on a new Google doc for the new silicon, since RDxxxx/WRxxxx encodings have changed, along with several other things, like new smart pin modes. I want to get that out of the way and get back onto Spin2. Spin2 is the context in which I plan to demonstrate how to use the chip. Anyone writing a C compiler will be able to easily translate that stuff, if they wish.

I know that Spin2 does not get favorable consideration here for what may be perfectly valid reasons, but what I want to achieve just isn't going to happen with a huge compiler. I want to make a very nimble development system that is at least as fast as a person can think, and very interactive. There is no current frame of reference for what this would be like. If this can be achieved, it would be more significant than whatever language it uses, because it would allow inventors to work way faster and have a lot more fun than what the current methodology affords. I realize that some people are just going to demand C, and I'm glad that you guys are tackling that. I am supportive, but only passively, at the moment, because I don't have unlimited bandwidth. I'm trying to realize what I've been thinking about for a long time.

I think this Spin2 compiler idea is a great plan. We can do all sorts of things from there.

Also, the P2 forum is full of develop types, but I suspect there is a large silent group out there that are just happy they can still build stuff in PropellerTool, a decade and a half on. I remember the tool size/complexity was an issue when I started using the prop around 2008

Totally. I am one of those, though having it is not a requirement for me. FastSpin is amazing. I hope to see collaboration / support between Parallax and Eric. I also hope it stays simple, and or the simple options, like msrobots simple linker / overlay remain.

The nice thing about Prop Tool is the dead simple operation and constant feature set. It is a great build system that just works with a minimum of fuss. Once a person gets themselves bootstrapped onto it, they are done. Just go anytime it is needed. At times, I need that. Just get everything together, build, code, test, done. Being simple, contained and not changing is worth gold.

That is like a little cul de sac. Does not lead anywhere, but the neighborhood is nice, clean.

These other roads under discussion are all important too. Potential travellers on all of them.

Honestly, once Chip has Spin 2 out of his head, that can be a nice baseline for drivers and objects.

This time, having a more powerful chip and no fixed ROM, like P1, we will see a similar thing happen with C and such...

Those local maxima centers of gravity will be "the obex" and people will go where they need or want.

All that leaves this vision Chip has. He needs to bootstrap himself onto the P2, leaving x86 behind, and will finally be able to build on a Prop natively.

Awesome. I am sure many will be eager to see how that all goes. I am, and it has been nearly 2 decades getting here. He needs to just do it. Seriously. The rest will sort right out as the various centers of gravity out there now gain mass and attract others.

I know that Spin2 does not get favorable consideration here for what may be perfectly valid reasons, but what I want to achieve just isn't going to happen with a huge compiler. I want to make a very nimble development system that is at least as fast as a person can think, and very interactive. There is no current frame of reference for what this would be like. If this can be achieved, it would be more significant than whatever language it uses, because it would allow inventors to work way faster and have a lot more fun than what the current methodology affords. I realize that some people are just going to demand C, and I'm glad that you guys are tackling that. I am supportive, but only passively, at the moment, because I don't have unlimited bandwidth. I'm trying to realize what I've been thinking about for a long time.

So true, but I've been doing this all along with TAQOZ although I think I've been a bit lazy/busy and I still need to write a little text editor to make it truly stand-alone.

One person complains the text editor is too simple. Another claims the auto complete gets in their way (having to hit tab or escape). Some don't want to use and IDE at all and prefer command line. The silent majority wants Windows, but a very vocal group of VIP contributors wants anything but Windows. Some people want no install at all and want web browser based.

Guess what, the Propeller has options for ALL of these viewpoints!

Is the major concern that just because Chip Gracey doesn't use a particular IDE or compiler or language, that somehow it's invalid?

Would a "parallax approved" logo and webpage link help with this? Click the link and it says something like, this software product has been reviewed and is suitable for use with the parallax propeller line of multicore microcontrollers.

I think the big thing with debugging is we have to admit debugging is single-cog, and that the other cogs are gonna spin along if the debugger breaks execution. That has implications that aren't ordinary for debugging, so it's not quite as simple as it is on other platforms. But a working single-cog debugger would still be a big help for application business logic.

OzProp's created this really neat debugger in Python. When debugging a cog, both the cog being debugged ('the debugee?') and the cog doing the debugging both need to be started in 'debug' mode.

Given the cogs can run full steam until a debug interrupt occurs, it brings up possibility of why not start everything in debug mode, and any cog can then debug any other? This is technically fine but becomes quite nightmare of how you present/multiplex that information to a user. A single serial terminal doesn't seem the optimal way

The silent majority wants Windows, but a very vocal group of VIP contributors wants anything but Windows.

A bold statement that I don't actually see evidence for: Just because some of us prefer to use platforms other than Windows doesn't mean we want tools that exclude Windows users.
Perhaps it would be better stated as "Based on installed base of computers, it is likely that there is a silent majority that wants Windows, and a very vocal group of contributors wants support for tools on non-Windows platforms."

Is the major concern that just because Chip Gracey doesn't use a particular IDE or compiler or language, that somehow it's invalid?

Would a "parallax approved" logo and webpage link help with this? Click the link and it says something like, this software product has been reviewed and is suitable for use with the parallax propeller line of multicore microcontrollers.

For business purposes, "Parallax Approved" is not even close to "Parallax Official". If it doesn't come from the Parallax website, with Parallax branding then it is third-party and an evaporation risk. Even if the engineer designing it wants to use Parallax product with a third-party toolset, the manager is likely to say no before the engineer can even get started.

I think the big thing with debugging is we have to admit debugging is single-cog, and that the other cogs are gonna spin along if the debugger breaks execution. That has implications that aren't ordinary for debugging, so it's not quite as simple as it is on other platforms. But a working single-cog debugger would still be a big help for application business logic.

OzProp's created this really neat debugger in Python. When debugging a cog, both the cog being debugged ('the debugee?') and the cog doing the debugging both need to be started in 'debug' mode.

Given the cogs can run full steam until a debug interrupt occurs, it brings up possibility of why not start everything in debug mode, and any cog can then debug any other? This is technically fine but becomes quite nightmare of how you present/multiplex that information to a user. A single serial terminal doesn't seem the optimal way

The planned (hardware supported) debugging concept is meant to engage ALL cogs, as independent systems, sharing a serial link to a host that manages conversations with each cog.

I'd imagine most cogs will be serving as virtual hardware, doing things like USB and VGA, etc. and not need debugging...
It's just the one or two cogs doing new things that will need debugging. As I see it anyway...

I'd imagine most cogs will be serving as virtual hardware, doing things like USB and VGA, etc. and not need debugging...
It's just the one or two cogs doing new things that will need debugging. As I see it anyway...

True, but anytime a cog (re)starts, it will message the host and the host will have the option to let it run without setting any future break condition, set a breakpoint, single-step, poll memory, etc. It's going to be cool. You will see everything going on, if you'd like.