Not that it matters much, however I think jmg is quite correct in pointing out some serious, fundamental issues that should be carefully considered.
Parallax needs to recoup some investment money on the P2, and to do that they need new users.
Making it easier for new people to get spun up on the P2 should be something looked at not just from a technical POV.
Like it or not, interested newcomers are going to look at example code, and the more human readable or similar it is to existing 'standard' ASM, the perceived barrier to entry will be lower.
Making the P2 a bit more 'standard' vs 'red-headed step-child'-like seems like it could lead to better exposure and uptake/$$.
We all do want that, right?
Agreed, this does not have to 'break' anything either - just deprecate some features, with more standard syntax as the preferred one, and try to create new examples in the more human readable / portable / maintainable syntax.
Many tools have deprecated features, replaced with a better way.
That usually varies with each deprecated feature, but most deprecated features I recall seeing in tools, were replaced by a more human readable / portable / maintainable syntax.
Example: Even with something as trivially simple as a line-comment, I've seen a general trend to supporting // in non-C languages.
Why ?
Just a little thing, that helps more human readable / portable / maintainable syntax & syntax highlighters usually already understand it.
No I dont. Gas can do those examples just fine, no worries, right?
As for the stepchild... Perhaps the P2 effort should be abandoned. Maybe P1 should have never been done.
Why go through the trouble to make such a sweet package?
The trouble is I completely reject the idea that having one unified assembler syntax at this stage is going to make any bit of difference that is worth more than the great SPIN/PASM environment is. And there are different assembler syntax is all over the place for every chip there ever was.
And they have their purpose too. Just like SPIN / PASM do. People will use the tools that make the most sense to them.
And the code is compelling they will deal with it.
I personally was drawn to the p1 by @Mparks beautiful Sphinx thing.
It was like been thrown back to my Atari times.
Type in, compile and run on the same small device. I really liked it.
I was hooked on the p1. Not because I do need a microcontroller a all, but because of how simple it was to get things running.
I am programming computers since about 32 years for a living. Coming from the mainframe side and COBOL, them PC's where already a challenge.
But Spin/Pasm was fun. I tried C on the p1 and - hmm - it was like being at work again.
I still do not get the point of @jmg that the p2 needs to conform to standards or parallax will go down.
If it would, it would be just another one. But it is not. It is some different way to look at things and @Chip is quite good at that.
Sure the p2 will be a 'niche product', but Parallax is not going 'public' and end up as big as IBM. I guess they never wanted to. Them brothers are quite a pair.
So I think the p2 will be a success for Parallax as the Stamps and the P1 are BECAUSE they are different. And a small company like Parallax do not need to sell hundreds of thousands of units a year to survive.
Every place I worked for as a programmer had different coding styles, naming conventions, compilers and languages to preferable use. Usually it took me a couple of days to adjust. And if you have to write #label or @label or #@label or whatever is just the notation of the code. Like naming conventions for stuff.
Programming is the art of solving problems you would not have without computers. It happens in your head. It does not matter at all in what language you finally write the code. At least not for me. Once the problem is solved I can do it in COBOL, ALGOL, BASIC, C, C#, Assembler, whatever language you throw at me. It really does not matter.
But Spin/Pasm was fun. I tried C on the p1 and - hmm - it was like being at work again.
I still do not get the point of @jmg that the p2 needs to conform to standards or parallax will go down.
You need to re-read my posts.
Parallax have already done a C port to P1, so they do understand the need to follow the users out there.
Nor is it a question of PASM/Spin or C/gas et al
There are a lot of users out there with experience of other MCUs, they need to find P2 easy to start, and a larger portion of P2 users will be using C, and coming from C, than was true for P1.
I thought our goal here was to test and proof and verify and enhance the Verilog design and the P2 architecture to make it the best it can be.
Squabbles over PASM syntax, compiler needs and the future growth of Parallax belong elsewhere.
It was noted there was a problem with alignment, a workaround was provided that seems to work until Chip can update PNUT with something more permanent.
Just like all of us testing code for the P2 are using PNUT, I imagine our first programming tools for P2 programming in PASM or Spin will be derived from PNUT and OpenSpin.
Whoever is going to set out to write the open source macro assembler for the P2 will have authors discretion to define the syntax as they see fit. May the best tool win and all that.
Those of us that are here now actually testing just need to come up with tool workarounds so we can keep writing code and testing stuff. We accepted the invitations to the dance, we kinda just need to dance with what brung us for now. Anything else is non-productive and distracting to our main purpose are this time.
These syntax issues are ergonomic issues for the programmer. We need everything to be comfortable and clean, making programming a joy. I feel that what we have right now is a ways from that ideal. The trouble is mainly coming from addressing complexities. If we could establish some basic rules, maybe based on cog/lut vs. hub context, perhaps we could simplify things greatly.
These syntax issues are ergonomic issues for the programmer. We need everything to be comfortable and clean, making programming a joy. I feel that what we have right now is a ways from that ideal. The trouble is mainly coming from addressing complexities. If we could establish some basic rules, maybe based on cog/lut vs. hub context, perhaps we could simplify things greatly.
Agreed - and it would be real nice if all the great ASM examples people will create, did not have to be re-written again, just to use with P2-C.
Because P2-ASM is not compatible with P1-ASM, there is a chance here to converge P2-ASM, and reduce future work.
(NB Spin is not affected )
The smart question here, is
"Do you want to re-write (& debug) ASM twice ? "
Let's face it, the Propeller (P1 or P2) is a Spin+PASM machine. We may have a C/C++ compiler but none of the real Propeller wizards really care to use it as far as I can tell. That means that the C/C++ support is suboptimial which in turn ends up meaning that potential customers either reject the Propeller or, if they are open-minded enough, embrace Spin/PASM because that is where they can get help on the forums. Most seem to have rejected P1. It's all well and good to say that it's good to have lots of options but if all of the potential "expert help" here favors Spin+PASM, C or any other language is going to seem like an afterthought. How about if all of you Propeller experts help us to make C/C++ the prefered language for the Propeller? Write cool drivers, help us improve the tools and libraries, help us to make Parallax successful with P2. Because we know from the experience with P1 that we will only attract a small number of "converts" to Spin+PASM. Just offering a token C/C++ compiler without support from the most knowledgable Propeller users is not going to make P2 a success in my opinion. Parallax is doing a great job with their C educational material but no one is really addressing the needs of already advanced C/C++ programmers.
I've always thought C/C++ will win on P2 because of the larger programming space...
Depends, of course, on the application. But, big programs are easier in C/C++.
Not sure I can justify that assertion, but that's my feeling anyway...
It won't win unless the people who really know the Propeller inside and out use C/C++ and write cool stuff in it. I'm, as I'm sure you're all aware, not a Propeller expert. Most of you know a lot more than I do.
I think trying to orient programming towards hub exec has been the downer. Living in the cog is more fun.
So remove hub exec and go back to a 16 COG P1 with 64 pins?
No. It's too bad it couldn't be introduced as an advanced topic in learning the Prop2, though. It just invokes some complexities that are not nice to front-load.
I think when a number of us get to start checking out the instructions, a better method will evolve. Most of the discussions today seem to be about the syntax - this can be settled later as long as the instruction set performs the purpose that we require.
Chip,
Yes, perhaps hubexec shouldn't be driving the programming model. The easiest part will still be to use cog/lut. Then if required, hubexec can be used. My guess is there will only be a few cogs running hubexec. With the advantages of the really fast hub loading, some will use overlays (like me). Hubexec should be considered the icing on the cake.
That doesn't mean that we shouldn't be able to start in hubexec. I like this too, and we have a single case usage for starting in the cog too.
I still believe there is some simplification in the jmp/call/ret instructions, and that long-alignment should be forced such that the goto/return addresses only require 18bits. But that can be a discussion for later.
IMHO Hub exec mode is the icing on the cake and shouldn't be the driving force.
I use all sorts of micros depending on the task at hand, the Propeller is by far the easiest and most fun to use.
I really hope P2 can continue that tradition.
I think trying to orient programming towards hub exec has been the downer. Living in the cog is more fun.
So remove hub exec and go back to a 16 COG P1 with 64 pins?
No. It's too bad it couldn't be introduced as an advanced topic in learning the Prop2, though. It just invokes some complexities that are not nice to front-load.
Actually, I think it would be better to introduce hub exec first and COG/LUT as an advanced topic. Hub execution will seem most natural to people I think and it allows for much larger programs before running out of program space. The whole idea of having to load bunch of data from hub into another address space just to execute it seems more complex and it is only required for code that has tight timing requirements. That is most likely to be driver code that beginners will get from OBEX anyway. Later, when they want to write their own drivers and when hub exec isn't good enough for those drivers, they can learn the complexity of running entirely out of COG memory. Even later, when they run out of space in COG memory, you can introduce the COG+LUT model.
I agree with David. I don't think HUBEXEC will be hard to introduce to beginners. It gives hardware component layer to the "glue" that makes Spin/PASM work so well together. Just as Spin and PASM flow together to support one another, HUBEXEC and COGEXEC mesh together nicely and compliment each other.
Just like we all jumped into LUT execution knowing it wouldn't be the most common way to write code, we all wanted to try it since it was one of the most novel features. We all jumped on the bandwagon with HUBEXEC since it is new and a powerful feature we've all been waiting for. With all the rapid early exposure come the early visible warts. Those are all being worked out and we're digging deeper into the P2.
I think it is all explainable to a newcomer once the architecture model freezes and we can all visualize it. What we're getting is simple, elegant and becoming pretty consistent in operation. Once the hardware is solid, the tools can adapt and help out with any remaining points of confusion.
Hubexec:
Remove hubexec? Absolutely not! But yes, in hindsight, a 16 cog P1 with 64 pins, or just the P1 with more hub and 64 pins would have been a better interim solution.
If every cog runs hubexec I expect that the P2 will be "hot" chip! We will need to run inside cog/lut for most cogs to reduce the power.
Hubexec, while it's icing on the cake, its also a definite requirement for a few programs.
I can see how hubexec might look easier for new users familiar with other micros. But if you remember, cog (PASM) was not difficult.
Spin hides the fact that the code resides in hub and the interpreter resides in cog. But in the P1 it was quite slow. It will be much faster in the P2 because we have the RFxxxx instructions (a cache) and we have lut for additional code space (to speed up execution) and also for the stack.
Spin2 will be an interesting animal
Chip
It seems the "bug radar" is being jammed here with "chaff"
Not sure if you saw an earlier post highlighting an issue with INB operations. See "INB issue" here
Comments
Many tools have deprecated features, replaced with a better way.
That usually varies with each deprecated feature, but most deprecated features I recall seeing in tools, were replaced by a more human readable / portable / maintainable syntax.
Example: Even with something as trivially simple as a line-comment, I've seen a general trend to supporting // in non-C languages.
Why ?
Just a little thing, that helps more human readable / portable / maintainable syntax & syntax highlighters usually already understand it.
As for the stepchild... Perhaps the P2 effort should be abandoned. Maybe P1 should have never been done.
Why go through the trouble to make such a sweet package?
The trouble is I completely reject the idea that having one unified assembler syntax at this stage is going to make any bit of difference that is worth more than the great SPIN/PASM environment is. And there are different assembler syntax is all over the place for every chip there ever was.
And they have their purpose too. Just like SPIN / PASM do. People will use the tools that make the most sense to them.
And the code is compelling they will deal with it.
You are going to find very different considerations and those people buy chips.
So do the ones using the big boy gcc tools.
Having both is only a good thing. And like I said, it will happen anyway.
It was like been thrown back to my Atari times.
Type in, compile and run on the same small device. I really liked it.
I was hooked on the p1. Not because I do need a microcontroller a all, but because of how simple it was to get things running.
I am programming computers since about 32 years for a living. Coming from the mainframe side and COBOL, them PC's where already a challenge.
But Spin/Pasm was fun. I tried C on the p1 and - hmm - it was like being at work again.
I still do not get the point of @jmg that the p2 needs to conform to standards or parallax will go down.
If it would, it would be just another one. But it is not. It is some different way to look at things and @Chip is quite good at that.
Sure the p2 will be a 'niche product', but Parallax is not going 'public' and end up as big as IBM. I guess they never wanted to. Them brothers are quite a pair.
So I think the p2 will be a success for Parallax as the Stamps and the P1 are BECAUSE they are different. And a small company like Parallax do not need to sell hundreds of thousands of units a year to survive.
Every place I worked for as a programmer had different coding styles, naming conventions, compilers and languages to preferable use. Usually it took me a couple of days to adjust. And if you have to write #label or @label or #@label or whatever is just the notation of the code. Like naming conventions for stuff.
Programming is the art of solving problems you would not have without computers. It happens in your head. It does not matter at all in what language you finally write the code. At least not for me. Once the problem is solved I can do it in COBOL, ALGOL, BASIC, C, C#, Assembler, whatever language you throw at me. It really does not matter.
So I have to agree with @potatohead.
Enjoy!
Mike
Parallax have already done a C port to P1, so they do understand the need to follow the users out there.
Nor is it a question of PASM/Spin or C/gas et al
There are a lot of users out there with experience of other MCUs, they need to find P2 easy to start, and a larger portion of P2 users will be using C, and coming from C, than was true for P1.
Squabbles over PASM syntax, compiler needs and the future growth of Parallax belong elsewhere.
It was noted there was a problem with alignment, a workaround was provided that seems to work until Chip can update PNUT with something more permanent.
Just like all of us testing code for the P2 are using PNUT, I imagine our first programming tools for P2 programming in PASM or Spin will be derived from PNUT and OpenSpin.
Whoever is going to set out to write the open source macro assembler for the P2 will have authors discretion to define the syntax as they see fit. May the best tool win and all that.
Those of us that are here now actually testing just need to come up with tool workarounds so we can keep writing code and testing stuff. We accepted the invitations to the dance, we kinda just need to dance with what brung us for now. Anything else is non-productive and distracting to our main purpose are this time.
Agreed - and it would be real nice if all the great ASM examples people will create, did not have to be re-written again, just to use with P2-C.
Because P2-ASM is not compatible with P1-ASM, there is a chance here to converge P2-ASM, and reduce future work.
(NB Spin is not affected )
The smart question here, is
"Do you want to re-write (& debug) ASM twice ? "
Depends, of course, on the application. But, big programs are easier in C/C++.
Not sure I can justify that assertion, but that's my feeling anyway...
No. It's too bad it couldn't be introduced as an advanced topic in learning the Prop2, though. It just invokes some complexities that are not nice to front-load.
Jmg, would you really be in favor of that?
Chip,
Yes, perhaps hubexec shouldn't be driving the programming model. The easiest part will still be to use cog/lut. Then if required, hubexec can be used. My guess is there will only be a few cogs running hubexec. With the advantages of the really fast hub loading, some will use overlays (like me). Hubexec should be considered the icing on the cake.
That doesn't mean that we shouldn't be able to start in hubexec. I like this too, and we have a single case usage for starting in the cog too.
I still believe there is some simplification in the jmp/call/ret instructions, and that long-alignment should be forced such that the goto/return addresses only require 18bits. But that can be a discussion for later.
We can get the syntax good, and iron out stuff in the compiler.
I use all sorts of micros depending on the task at hand, the Propeller is by far the easiest and most fun to use.
I really hope P2 can continue that tradition.
Just like we all jumped into LUT execution knowing it wouldn't be the most common way to write code, we all wanted to try it since it was one of the most novel features. We all jumped on the bandwagon with HUBEXEC since it is new and a powerful feature we've all been waiting for. With all the rapid early exposure come the early visible warts. Those are all being worked out and we're digging deeper into the P2.
I think it is all explainable to a newcomer once the architecture model freezes and we can all visualize it. What we're getting is simple, elegant and becoming pretty consistent in operation. Once the hardware is solid, the tools can adapt and help out with any remaining points of confusion.
Of course it could. But why?
Hubexec:
Remove hubexec? Absolutely not! But yes, in hindsight, a 16 cog P1 with 64 pins, or just the P1 with more hub and 64 pins would have been a better interim solution.
If every cog runs hubexec I expect that the P2 will be "hot" chip! We will need to run inside cog/lut for most cogs to reduce the power.
Hubexec, while it's icing on the cake, its also a definite requirement for a few programs.
I can see how hubexec might look easier for new users familiar with other micros. But if you remember, cog (PASM) was not difficult.
Spin hides the fact that the code resides in hub and the interpreter resides in cog. But in the P1 it was quite slow. It will be much faster in the P2 because we have the RFxxxx instructions (a cache) and we have lut for additional code space (to speed up execution) and also for the stack.
Spin2 will be an interesting animal
It seems the "bug radar" is being jammed here with "chaff"
Not sure if you saw an earlier post highlighting an issue with INB operations.
See "INB issue" here