I really miss the old catalogs! Parallax will always look like a small company compared to the competition.
Why try to act like a big one. A website simply doesn't draw you in or keep your attention like the catalogs
did.
I can't understand why Spin is being dismissed so lightly sometimes and it complements the Prop so nicely too and is very easy to learn and very easy
to get started even if you have little programming knowledge.
It has indentation instead of curly braces, and people keep talking about how sloooww it is. It doesn't compile
down to assembly, and if you talk about assembly elsewhere you are treated like a leper and accused of trying
to reinvent the wheel. Why do people want to buck the status quo and try the Propeller?
If the propeller 1 runs at 80mhz and has 8 cores/cogs (whatever) that is big Horsepower. The same analogy
can be applied to the accessories. It doesn't have an adc, or a conventional debugger incorporated into the
propeller tool. Spin is slow, they might need to learn assembly. That sounds like the Propeller is low on torque.
People have lots of plans and intentions for upcoming projects. They are collectors, and their wives call them
Hoarders. They spend a lot of time noodling on the internet with the attention span of a little kid, looking at
horsepower and torque specs, bouncing around on forums searching for info and asking other people for advice.
Spin is so much better IMO than Arduino C\C++, but who is spreading that word. Perhaps someday it will catch
on fire and more people will share their good fortunes with other sites.
I certainly don't advocate a Spin-only release; we've already made that mistake. I was only pointing out that all P1 commercial designs use Spin/ASM. P2 could only be released if we have Spin and C, both complete. The former is a necessity for the inventor and many existing customers; the latter is to grow a market much larger than we have at present.
There's so much more to consider than these tools, though. We will need to segment our customers properly for education and commercial, speaking to each of them directly.
Ken, I really think you are underestimating the importance of C and C++ in commercial applications. When a company decides on a processor that they want to use for a new project they look at several attributes of each processor. Language support is one of the major things that is looked at. If a vendor doesn't fully support a standard language such as C/C++ it reduces the probability that a chip will be selected. Most companies will not even consider Spin. It's a proprietary language that none of their engineers are familiar with.
I'm not saying that Spin isn't important to the P2. I just saying that C/C++ is just as important or more important to the P2. If Parallax is really serious about making the P2 they should be developing C/C++ now instead of waiting till later. Since the C/C++ development doesn't involve Chip it can be done in parallel with the chip development. I really can't understand why the chip development has been put on hold while Spin2 is being developed and Parallax is spending zero effort on C/C++. It really boggles the mind.
I was one of the folks who ignored the Propeller for years due to Spin. I had already programmed PIC and AVR in C and SX in assembly, why learn another language, especially one that is only used on one chip? Perceived vendor lock-in.
Specs matter! Numbers like MHz and MIPS. 80,000 Spin instructions per second didn't impress me. I considered that an unacceptable penalty for using a high level language. I'd expect Arduino is in the millions. P2 should do very well in this department.
What changed my mind? P2 delays and $7 Quickstarts. Of course, I started with C and learned Spin as needed to modify other programs. I'm glad I did. The Propeller is fun to program. I mostly use assembly.
Something to consider would be supporting P2 (and maybe P1 as well) in Arduino IDE. Mostly for more publicity. I think it helped the ESP8266, but there are a lot of other platforms supported that didn't benefit at much.
I really miss the old catalogs! Parallax will always look like a small company compared to the competition.
Why try to act like a big one. A website simply doesn't draw you in or keep your attention like the catalogs
did.
I think that is something Radioshack missed. The Parallax store is just small enough to look through all the categories in one sitting. With radioshack.com you can't do that, so less chance of finding stuff you weren't looking for.
Ken, I really think you are underestimating the importance of C and C++ in commercial applications. When a company decides on a processor that they want to use for a new project they look at several attributes of each processor. Language support is one of the major things that is looked at. If a vendor doesn't fully support a standard language such as C/C++ it reduces the probability that a chip will be selected. Most companies will not even consider Spin. It's a proprietary language that none of their engineers are familiar with.
I might not be choosing the best words and that's why you have this impression. If we had to choose Spin or C, I'd take C. Having been part of a team that worked closely in Spin for many years, developing books (I managed many of the printed resources we produced), I am fully aware of how engineers receive the idea of learning a new language - not well. Some accepted it and produced products with Spin; others refused to take a deeper look.
If we had all the resources we needed, I'd be fully funding you and the team on the development of a P2 C compiler right now. Today.
Ken, I really think you are underestimating the importance of C and C++ in commercial applications. When a company decides on a processor that they want to use for a new project they look at several attributes of each processor. Language support is one of the major things that is looked at. If a vendor doesn't fully support a standard language such as C/C++ it reduces the probability that a chip will be selected. Most companies will not even consider Spin. It's a proprietary language that none of their engineers are familiar with.
I might not be choosing the best words and that's why you have this impression. If we had to choose Spin or C, I'd take C. Having been part of a team that worked closely in Spin for many years, developing books (I managed many of the printed resources we produced), I am fully aware of how engineers receive the idea of learning a new language - not well. Some accepted it and produced products with Spin; others refused to take a deeper look.
If we had all the resources we needed, I'd be fully funding you and the team on the development of a P2 C compiler right now. Today.
It seems like people think that the resources being used to make Spin2 are the same resources that could be used to create GCC for P2. As far as I know, that is not true. Chip will make Spin2 on his own. GCC will be done by people who aren't Parallax employees. So the two projects could happen in parallel but there would be no advantage to stopping work on Spin2. It wouldn't advance work on GCC because that will be done by different people.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
I would like to share some toughts about this matter.
First of all I'm an hobbyst so my point of view may not correspond to the reality, I believe that official support for anything is mandatory for the industry. You can't tell someone that the C compiler is supported by a couple of volunteers that may or may not be available in the future and expect that it uses your chip for big rewarding projects. Don't get me wrong, the work done on PropellerGCC by the volunteers so far was great, but it needs to be officially supported by Parallax in the long term to be desirable by the industry. People like you, me and most of the users on this forum may not care about official support, but that won't be true when you invest hundreds of thousands money in a project.
About Spin... well, I'm one of those that don't like it much, and I think I'll never have continued with the Propeller without C support. Spin resides in rom, unless something changed recently, so it must be completed well before the silicon is fabricated and must be well tested because bugfixes will be nearly impossible afterward. Now, I think that a rom language was useful back when P1 was first developed, considered also the unique processor architecture, but nowadays does it makes sense ? I don't think that any other processor out there has a rom language built in, all compilers will generate assembler code and I believe that P2 should do just that, start executing PASM at the first available location with hubexec, then you can have spin, c, forth, javascript and whatever available as a compiler.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
That's my interpretation.
I do not know of anyone who wants Spin to cease to exist. Also, just because people outside of Parallax do the GCC development does not mean it won't be a Parallax product. The current P1 version of GCC was developed outside of Parallax and it is an official Parallax product.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
I would like to share some toughts about this matter.
First of all I'm an hobbyst so my point of view may not correspond to the reality, I believe that official support for anything is mandatory for the industry. You can't tell someone that the C compiler is supported by a couple of volunteers that may or may not be available in the future and expect that it uses your chip for big rewarding projects. Don't get me wrong, the work done on PropellerGCC by the volunteers so far was great, but it needs to be officially supported by Parallax in the long term to be desirable by the industry. People like you, me and most of the users on this forum may not care about official support, but that won't be true when you invest hundreds of thousands money in a project.
About Spin... well, I'm one of those that don't like it much, and I think I'll never have continued with the Propeller without C support. Spin resides in rom, unless something changed recently, so it must be completed well before the silicon is fabricated and must be well tested because bugfixes will be nearly impossible afterward. Now, I think that a rom language was useful back when P1 was first developed, considered also the unique processor architecture, but nowadays does it makes sense ? I don't think that any other processor out there has a rom language built in, all compilers will generate assembler code and I believe that P2 should do just that, start executing PASM at the first available location with hubexec, then you can have spin, c, forth, javascript and whatever available as a compiler.
Just my toughts.
The P1 Spin VM resides in ROM. The P2 Spin VM will not. There is no need to finish Spin2 before fabricating the P2 chip.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
That's my interpretation.
I have said in the past the Spin was a mistake, but I was wrong. Spin is a good learning language because it is a limited language. A novice can master Spin in a month. It would be good if the Spin compiler would generate warnings when doubtful syntax is being used, such as the use of the >= and <= operators. Spin should be kept simple, otherwise it loses its advantage as good learning language.
I have heard no one say that they preferred Spin to not exist on the P2. That certainly is not my view. Spin is important on the P2. People that program the P1 in Spin will be able to program the P2 as well without having to learn a new language. I do feel that Spin2 should have an interoperability mode, so that P1 Spin code can be ported directly to the P2 with minimal changes.
Yes, I felt that C should have been completed last year at the latest, but that's because I believed that the P2 would be completed last year also. When I look back at posts from early 2016 there was some hope that the design would be complete by the end of 2016. However, as I look at posts around March 2016 it became obvious that that wasn't going to happen. My view isn't so much that C should be available before the end of last year, or this year, or even next year. My view is that C should be available before the design goes into synthesis. I don't know if that will be this year, or 2018 or 2019 or ever.
C support should not be a product, but should just be included with the P2 just like Spin support will be included. It would be nice to have a debugger. I hardly ever use debuggers, but it is a big consideration when companies decide on which chip to use for their next project. A simulator would be nice also. I do like to use simulators. They provide detail that you just can't get any other way. Also, a simulator allows testing code when you don't have hardware available. You could be flying over the middle of the Atlantic and run some P2 code on a laptop if you have a P2 simulator.
is a good learning language because it is a limited language
.
Yes, exactly!
Less is more for some use cases. P1 Spin is just enough to do really great things. Had it and the P1 been capable of in line PASM, it would have been just about as potent as possible.
This SPIN has the inline, and ideally a few, and I mean FEW, additions to flesh out known gaps. That and no more, would be my preference.
There are two dynamics in play here I feel get overlooked.
One is how much one has to know in terms of state and or language mechanics to attempt a solution. SPIN is lean in this way. For people jumping in, they can often do monkey see monkey do cut, paste, tweak and get somewhere. Great! Once they do, they get invested and will seek more. Everyone benefits from this eventually.
The other is about choices. Where there are enough, but not a luxurious or excessive set, how to do things is more obvious. There just are not that many possibilities. What this does is get people to their problem space solution quickly and it leaves room in their head to handle the actual problem. Simple may not be the most efficient, but it doesn't get in the way either.
I have been dismayed and confused over the SPIN 2 discussion. It largely ignores these things, and they are a big part of why SPIN should exist.
In my view, it is not necessary to improve the appeal of SPIN to experienced and or C programmers. They will use the tools of their experience, and should!
Instead, SPIN should reflect the design of the P2 and present in a lean, compelling, simple, potent way. It's there to suck people into this stuff.
No joke on that.
Also, this is all about people doing things. Their own things. SPIN, with that focus, will grow the number of people doing those things, and we all benefit from that activity and often the products of it.
Having explored various solutions, nothing made today approaches the accessibility of P1, Prop Tool, SPIN, PASM. I was doing stuff in a day. A few days saw great progress, and in that month Dave mentioned, I was competent, getting things I wanted to do done.
The best thing is being away from it, returning after a time only to find the stuff that didn't stick was just as easy to review and use as it ever was. That has helped me in the professional projects I have done.
The most recent one was very telling. I got the basics, proofs of concept working quickly. People far more seasoned and capable than I am see kind of stunned.
Honestly, I just applied what I have learned here, how to think from here, and solved the problems. The target performed and proved out bigger and better. Was able to take one of those guys, despite some protests about "why not C?", and put them in my place, and they were effective in mere hours.
Cool, if you ask me. And yes, "but it doesn't have...." came up a lot. I would just write a few lines, run it and say, "so what? Is this about the code, or the science and research we are doing?"
End of discussion. Science got done.
Now, the "real test bed" is a higher complexity thing. Lots of C code, and it's on a device that has interrupts, etc... getting the kernel, the concurrency part of things working has taken longer than my original build did, inclusive. I started with a Proto Board, soldered all the bits I needed, then wrote code, until I built up what was needed.
That other device is capable of a lot more, but still is not advancing the science as much as it is requiring a lot of investment.
Frankly, had P2 been done, I would have done another quick build up, used SPIN, and got the second set of proofs done, then probably set them loose on C, minus a lot of Smile we know will be done with COGS and events now.
Super easy by comparison to what is being used now.
We just need the silicon.
Make SPIN better, but no more lean, limit choices. That's a serious strength.
P2 if more roomy, and C will rock. Momentum on that will build the moment people can really trust the investment will get them off an FPGA.
The which is better discussion is largely a distraction.
So is the which gets done first discusdion. SPIN will happen as an artifact of how Chip does things. It's not worth changing that. In fact, it's a detriment.
Everything else is a matter of who puts some time in at this point.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
I would like to share some toughts about this matter.
First of all I'm an hobbyst so my point of view may not correspond to the reality, I believe that official support for anything is mandatory for the industry. You can't tell someone that the C compiler is supported by a couple of volunteers that may or may not be available in the future and expect that it uses your chip for big rewarding projects. Don't get me wrong, the work done on PropellerGCC by the volunteers so far was great, but it needs to be officially supported by Parallax in the long term to be desirable by the industry. People like you, me and most of the users on this forum may not care about official support, but that won't be true when you invest hundreds of thousands money in a project.
About Spin... well, I'm one of those that don't like it much, and I think I'll never have continued with the Propeller without C support. Spin resides in rom, unless something changed recently, so it must be completed well before the silicon is fabricated and must be well tested because bugfixes will be nearly impossible afterward. Now, I think that a rom language was useful back when P1 was first developed, considered also the unique processor architecture, but nowadays does it makes sense ? I don't think that any other processor out there has a rom language built in, all compilers will generate assembler code and I believe that P2 should do just that, start executing PASM at the first available location with hubexec, then you can have spin, c, forth, javascript and whatever available as a compiler.
Just my toughts.
The P1 Spin VM resides in ROM. The P2 Spin VM will not. There is no need to finish Spin2 before fabricating the P2 chip.
Absolutely agree David. Unfortunately though, Chip requires Spin2 for his P2 validation programs. I dare say though, it does not need to be a complete Spin2 for his testing (ie not with all bells and whistles).
While P2 continues to add features, many of us are just sitting on the sidelines waiting for a frozen P2 before we invest any time testing the P2. We have wasted so much time over the years on P2.
As I have said many times since P2HOT, I just want a better P1. This could be done in a week by Chip, and while it would no longer be what we all really would like, we would be elated to see a better P1 this year, and, I at least, would then be happier to wait just a little longer for that elusive P2.
Just think about it...
Chip spends 4weeks and takes a few bits from P2 for a better compatible P1...
* P1 compiler compatible (not necessarily binary compatible, but PASM compatible
* 160+ MHz
* maybe 2 clock instructions (dual port COG RAM)
* maybe 2KB LUT (no streamer, just extended cog ram) - requires extended jump/call method or relative jmp/call
* 512KB HUB RAM (1:8 instead of 1:16 access)
* maybe 16 COGs
* possible encryption
* use P2 frame - could this add ADC ?
* 64 I/O
* SPI Flash
Advantages...
* PASM software compatible (require recompile)
* Spin1 compatible, soft (not in ROM), permits faster spin plus later extensions using LUT
* PropGCC C compiler compatible
* BlocklyProp compatible
* Proves the ONSEMI process while yielding a saleable chip that most commercial customers wanted for years
I suggest that the Parallax board of directors include a member from the Prop community. I nominate Cluso to be that board member.
Everything that you said makes sense. Maybe Chip and Ken will seriously consider your suggestions.
EDIT: Oh wait. You didn't mention hub exec. We have to have hub exec. And Smart Pins. They're basically done. Why not just freeze the P2 design as it stands today, and go with that. I think if we know that the instruction set and encoding will not change dramatically people will get more enthused about testing and developing tools. Only bug fixes should be allowed in the P2 design from now on, and no more new instructions and instruction shuffling.
It sounds like Parallax is in a holding pattern right now trying to figure out how they're going to fund the rest of the project. Given the salaries, services, equipment and supplies that they've used on the P2 project so far they must have spent 2 or 3 million dollars on P2 development to date. I'm guessing the final push will cost them another half million dollars. I suppose it's easier to dribble out $200k per year for 10 years than to do a final $500k in one year.
Cluso, 4 weeks. more like 4 years. You seem to think whipping up a completely redesigned with changes in almost every way version of P1 will be trivial, but it's just not.
You ask for almost everything in the P2... What you ask for would take many months at a minimum, and likely multiple years to actually complete, and it would not be compatible with anything, new tools/compilers/etc. would all need to be written.
Others,
Chip won't consider the P2 done until he has Spin2/PASM2 done, stop trying to argue against that. Ken won't consider it a product he can ship until it has cross platform support for building both Spin2/PASM2 and C/C++ code. These both have been state by them many times over the years of development.
Roy, Ken has indicated that funding is the issue at this point. I think we've all conceded that Chip is focused on finishing the Spin interpreter and associated tools before he freezes the chip design and goes into synthesis. People are not motivated to test the P2 FPGA because their assuming it will change again. I think once the funding comes in things will begin to happen again. So it seems like funding is the real roadblock at this point. The amount of bells and whistles in Spin2 before synthesis probably depends on when the funding happens. I can't see Chip delaying the project to put in all the bells and whistles that people have proposed once the funding comes in. The bells and whistles can happen after synthesis. Time will tell.
Hopefully, the funding issue will be resolved soon. Once this happens we're probably a year away from product launch. So it seems like the launch countdown is at T minus one year and holding right now.
It would be nice if Spin and C/C++ could co-exist. A lot of really good work was done in Spin/PASM before C came along for the P1, but no Spin objects could be called from C programs, so they had to be translated -- either by hand or assisted by translation software. Allowing Spin and C code to work together in the same program would prevent redesigning the wheel in many cases, and it would also help to heal the divide that exists now between Spin and C programmers.
Unfortunately, with Chip doing Spin for the P2 and outside contractors doing C, I don't see this happening.
It would be nice if Spin and C/C++ could co-exist. A lot of really good work was done in Spin/PASM before C came along for the P1, but no Spin objects could be called from C programs, so they had to be translated -- either by hand or assisted by translation software. Allowing Spin and C code to work together in the same program would prevent redesigning the wheel in many cases, and it would also help to heal the divide that exists now between Spin and C programmers.
Unfortunately, with Chip doing Spin for the P2 and outside contractors doing C, I don't see this happening.
-Phil
This isn't really true. You can compile Spin objects to C or C++ using spin2cpp. You can also use spinwrap to call binary Spin objects files from C code.
David, understood. However, that does not say that Spin objects can exist as-is in a program that also includes C code. That's what would complete the fusion between the two languages: two languages, one IDE, one program, no intermediate translation step required, seamless compile-and-run.
spin2cpp does a good job of handling the programming tricks that people do in Spin, such as accessing the method parameter list and/or local variables as an array. I think spin2cpp can handle most objects that are in the OBEX. Of course, there is some Spin code that can't be translated, such as code that directly interacts with the Spin interpreter in cog RAM. There's also Spin code that takes advantage of the relocatability of Spin binaries, and maybe uses other obscure features of Spin. However, that is a very tiny subset of all the Spin code that's been done.
Spin that is compiled using spin2cpp with execute using hub exec instead of using an interpreter running out of cog memory. I think hub exec will be the normal mode of operation on the P2. There won't be much of a need for a Spin interpreter that execute bytecodes. A bytecode program that fits in 32K on the P1 will probably take less than 100K on the P2. There will still be over 400K left for data. The only time someone will need to resort to byte codes is when they will need almost all of the 512K for data or they have a huge Spin program that has 16 times as much code as the largest P1 program. I would hope that PropGCC for the P2 will have a CMM mode that can handle those situations as well.
David, understood. However, that does not say that Spin objects can exist as-is in a program that also includes C code. That's what would complete the fusion between the two languages: two languages, one IDE, one program, no intermediate translation step required, seamless compile-and-run.
-Phil
What do you mean by "as-is"? Do you mean Spin and C in the same source file? That certainly can't be done. However, code compiled with OpenSpin can be used in binary form using spinwrap.
I've been using Propeller 1 for about 8 years now (on and off). I have almost zero knowledge of the Spin language. Literally the only Spin I use is the mandatory CogInit() that I need to fire up the Cogs. The rest I write in PASM and enjoy the decadence of such absolute power.
I have no predjudice against Spin, for code-space efficiency it is unbeatable! And not everybody's projects require the blistering speed of PASM all the time.
My projects though, DO always require the blistering speed of PASM and I'm absolutely happy with the status quo with the Prop 1. It is good to know that if I ever need to do some high-level stuff in Spin, then that option is instantly available. That is a seriously brilliant feature.
Phil,
What you are asking for barely works in any other coding land (even PC/Mac/Linux), and even then only for stuff like .NET based languages and runtime.
Having C/C++ call out to Spin is not as trivial as just calling some PASM hubexec code, it has to fire up the spin runtime/interpreter in another cog. Probably a better solution is to have the Spin code compiled to PASM and run in HUBEXEC then the C code can just call it. The other way around is a little simpler, since Spin2 will be able to just call into PASM hubexec code pretty easily. You still have to manage passing arguments, and each of them does it very differently (e.g. the C code can't get at the Spin COGs internal registers or stack.
I think the existing methods that work for P1 (spinwrap, etc.) are probably good enough, maybe just make it simpler to setup and use via the IDE?
What Phil wants is to be able to have an IDE with a Spin file in one tab, and a C file in another, and hit compile and it all gets put together into one binary. On top of that the spin or C can just call functions on either side, and I presume access global variables across the boundary (since that would be kind of required in his scenario). It's a fantasy land that doesn't really exist anywhere except in .NET languages (and even then with limitations and caveats).
I just don't think that is feasible or required. As long as C/C++ code can utilized "drivers" written in PASM with Spin glue (which we have already), then that's the primary need. Going the other way is probably way less desired, but also significantly easier since the compile C/C++ code is just PASM, and Spin2 having inline PASM should allow you to connect up to the C functions as long as you have the addresses (which can be handled with some simple link like step).
It's a fantasy land that doesn't really exist anywhere except in .NET languages (and even then with limitations and caveats).
Is there no way that we can make this happen? It would eliminate a lot of redundant development and help to unite two heretofore warring Prop dev factions. I think that alone makes it important enough to pursue.
To clear up the bewilderment around the apparent pace and focus of development on Parallax' part...
We are waiting to see how we are going to pay for the next steps, which are going to cost maybe $250k. We are being conservative in our approach here. While these expenses occur, Parallax needs to maintain positive cash flow. Until certain doors close/open, we are not sure about how we are going to address this matter. So, for now, I am working on the Spin interpreter, making little changes to the Verilog, along the way. I really can't imagine that there will be any more disruptive changes to the design between now and when we synthesize the final version. Meanwhile, all the analog layout changes have been made in the pad frame, based on the shortcomings of the last test chip. OnSemi will have a shuttle in July/August that we will run our new analog test chip on. That will probably come back in October. If everything is "go", we can proceed to make the final commitments to getting the silicon into production around or before that time frame.
To clear up the bewilderment around the apparent pace and focus of development on Parallax' part...
We are waiting to see how we are going to pay for the next steps, which are going to cost maybe $250k. We are being conservative in our approach here. While these expenses occur, Parallax needs to maintain positive cash flow. Until certain doors close/open, we are not sure about how we are going to address this matter. So, for now, I am working on the Spin interpreter, making little changes to the Verilog, along the way. I really can't imagine that there will be any more disruptive changes to the design between now and when we synthesize the final version. Meanwhile, all the analog layout changes have been made in the pad frame, based on the shortcomings of the last test chip. OnSemi will have a shuttle in July/August that we will run our new analog test chip on. That will probably come back in October. If everything is "go", we can proceed to make the final commitments to getting the silicon into production around or before that time frame.
Chip,
Do you mean another test chip like the previous one? ie not a usable chip, just a test of the outer ring??? If so, it seems a waste not to be able to test the rest of the chip, even if part has to have test pins instead of io pins.
Comments
Why try to act like a big one. A website simply doesn't draw you in or keep your attention like the catalogs
did.
It has indentation instead of curly braces, and people keep talking about how sloooww it is. It doesn't compile
down to assembly, and if you talk about assembly elsewhere you are treated like a leper and accused of trying
to reinvent the wheel. Why do people want to buck the status quo and try the Propeller?
If the propeller 1 runs at 80mhz and has 8 cores/cogs (whatever) that is big Horsepower. The same analogy
can be applied to the accessories. It doesn't have an adc, or a conventional debugger incorporated into the
propeller tool. Spin is slow, they might need to learn assembly. That sounds like the Propeller is low on torque.
People have lots of plans and intentions for upcoming projects. They are collectors, and their wives call them
Hoarders. They spend a lot of time noodling on the internet with the attention span of a little kid, looking at
horsepower and torque specs, bouncing around on forums searching for info and asking other people for advice.
Spin is so much better IMO than Arduino C\C++, but who is spreading that word. Perhaps someday it will catch
on fire and more people will share their good fortunes with other sites.
Bill M.
I'm not saying that Spin isn't important to the P2. I just saying that C/C++ is just as important or more important to the P2. If Parallax is really serious about making the P2 they should be developing C/C++ now instead of waiting till later. Since the C/C++ development doesn't involve Chip it can be done in parallel with the chip development. I really can't understand why the chip development has been put on hold while Spin2 is being developed and Parallax is spending zero effort on C/C++. It really boggles the mind.
Specs matter! Numbers like MHz and MIPS. 80,000 Spin instructions per second didn't impress me. I considered that an unacceptable penalty for using a high level language. I'd expect Arduino is in the millions. P2 should do very well in this department.
What changed my mind? P2 delays and $7 Quickstarts. Of course, I started with C and learned Spin as needed to modify other programs. I'm glad I did. The Propeller is fun to program. I mostly use assembly.
Something to consider would be supporting P2 (and maybe P1 as well) in Arduino IDE. Mostly for more publicity. I think it helped the ESP8266, but there are a lot of other platforms supported that didn't benefit at much.
I think that is something Radioshack missed. The Parallax store is just small enough to look through all the categories in one sitting. With radioshack.com you can't do that, so less chance of finding stuff you weren't looking for.
I might not be choosing the best words and that's why you have this impression. If we had to choose Spin or C, I'd take C. Having been part of a team that worked closely in Spin for many years, developing books (I managed many of the printed resources we produced), I am fully aware of how engineers receive the idea of learning a new language - not well. Some accepted it and produced products with Spin; others refused to take a deeper look.
If we had all the resources we needed, I'd be fully funding you and the team on the development of a P2 C compiler right now. Today.
However, it seems to me, those that are yelling the hardest for immediate C support (completed last year at the latest) also want it as an official Parallax product and as the central focus of the official IDE (including full debugging support and better throw in simulation too) ... and they'd also prefer Spin not exist at all.
That's my interpretation.
I would like to share some toughts about this matter.
First of all I'm an hobbyst so my point of view may not correspond to the reality, I believe that official support for anything is mandatory for the industry. You can't tell someone that the C compiler is supported by a couple of volunteers that may or may not be available in the future and expect that it uses your chip for big rewarding projects. Don't get me wrong, the work done on PropellerGCC by the volunteers so far was great, but it needs to be officially supported by Parallax in the long term to be desirable by the industry. People like you, me and most of the users on this forum may not care about official support, but that won't be true when you invest hundreds of thousands money in a project.
About Spin... well, I'm one of those that don't like it much, and I think I'll never have continued with the Propeller without C support. Spin resides in rom, unless something changed recently, so it must be completed well before the silicon is fabricated and must be well tested because bugfixes will be nearly impossible afterward. Now, I think that a rom language was useful back when P1 was first developed, considered also the unique processor architecture, but nowadays does it makes sense ? I don't think that any other processor out there has a rom language built in, all compilers will generate assembler code and I believe that P2 should do just that, start executing PASM at the first available location with hubexec, then you can have spin, c, forth, javascript and whatever available as a compiler.
Just my toughts.
I have heard no one say that they preferred Spin to not exist on the P2. That certainly is not my view. Spin is important on the P2. People that program the P1 in Spin will be able to program the P2 as well without having to learn a new language. I do feel that Spin2 should have an interoperability mode, so that P1 Spin code can be ported directly to the P2 with minimal changes.
Yes, I felt that C should have been completed last year at the latest, but that's because I believed that the P2 would be completed last year also. When I look back at posts from early 2016 there was some hope that the design would be complete by the end of 2016. However, as I look at posts around March 2016 it became obvious that that wasn't going to happen. My view isn't so much that C should be available before the end of last year, or this year, or even next year. My view is that C should be available before the design goes into synthesis. I don't know if that will be this year, or 2018 or 2019 or ever.
C support should not be a product, but should just be included with the P2 just like Spin support will be included. It would be nice to have a debugger. I hardly ever use debuggers, but it is a big consideration when companies decide on which chip to use for their next project. A simulator would be nice also. I do like to use simulators. They provide detail that you just can't get any other way. Also, a simulator allows testing code when you don't have hardware available. You could be flying over the middle of the Atlantic and run some P2 code on a laptop if you have a P2 simulator.
Oh, ok, I was wrong on that. Good.
Yes, exactly!
Less is more for some use cases. P1 Spin is just enough to do really great things. Had it and the P1 been capable of in line PASM, it would have been just about as potent as possible.
This SPIN has the inline, and ideally a few, and I mean FEW, additions to flesh out known gaps. That and no more, would be my preference.
There are two dynamics in play here I feel get overlooked.
One is how much one has to know in terms of state and or language mechanics to attempt a solution. SPIN is lean in this way. For people jumping in, they can often do monkey see monkey do cut, paste, tweak and get somewhere. Great! Once they do, they get invested and will seek more. Everyone benefits from this eventually.
The other is about choices. Where there are enough, but not a luxurious or excessive set, how to do things is more obvious. There just are not that many possibilities. What this does is get people to their problem space solution quickly and it leaves room in their head to handle the actual problem. Simple may not be the most efficient, but it doesn't get in the way either.
I have been dismayed and confused over the SPIN 2 discussion. It largely ignores these things, and they are a big part of why SPIN should exist.
In my view, it is not necessary to improve the appeal of SPIN to experienced and or C programmers. They will use the tools of their experience, and should!
Instead, SPIN should reflect the design of the P2 and present in a lean, compelling, simple, potent way. It's there to suck people into this stuff.
No joke on that.
Also, this is all about people doing things. Their own things. SPIN, with that focus, will grow the number of people doing those things, and we all benefit from that activity and often the products of it.
Having explored various solutions, nothing made today approaches the accessibility of P1, Prop Tool, SPIN, PASM. I was doing stuff in a day. A few days saw great progress, and in that month Dave mentioned, I was competent, getting things I wanted to do done.
The best thing is being away from it, returning after a time only to find the stuff that didn't stick was just as easy to review and use as it ever was. That has helped me in the professional projects I have done.
The most recent one was very telling. I got the basics, proofs of concept working quickly. People far more seasoned and capable than I am see kind of stunned.
Honestly, I just applied what I have learned here, how to think from here, and solved the problems. The target performed and proved out bigger and better. Was able to take one of those guys, despite some protests about "why not C?", and put them in my place, and they were effective in mere hours.
Cool, if you ask me. And yes, "but it doesn't have...." came up a lot. I would just write a few lines, run it and say, "so what? Is this about the code, or the science and research we are doing?"
End of discussion. Science got done.
Now, the "real test bed" is a higher complexity thing. Lots of C code, and it's on a device that has interrupts, etc... getting the kernel, the concurrency part of things working has taken longer than my original build did, inclusive. I started with a Proto Board, soldered all the bits I needed, then wrote code, until I built up what was needed.
That other device is capable of a lot more, but still is not advancing the science as much as it is requiring a lot of investment.
Frankly, had P2 been done, I would have done another quick build up, used SPIN, and got the second set of proofs done, then probably set them loose on C, minus a lot of Smile we know will be done with COGS and events now.
Super easy by comparison to what is being used now.
We just need the silicon.
Make SPIN better, but no more lean, limit choices. That's a serious strength.
P2 if more roomy, and C will rock. Momentum on that will build the moment people can really trust the investment will get them off an FPGA.
The which is better discussion is largely a distraction.
So is the which gets done first discusdion. SPIN will happen as an artifact of how Chip does things. It's not worth changing that. In fact, it's a detriment.
Everything else is a matter of who puts some time in at this point.
Absolutely agree David. Unfortunately though, Chip requires Spin2 for his P2 validation programs. I dare say though, it does not need to be a complete Spin2 for his testing (ie not with all bells and whistles).
While P2 continues to add features, many of us are just sitting on the sidelines waiting for a frozen P2 before we invest any time testing the P2. We have wasted so much time over the years on P2.
As I have said many times since P2HOT, I just want a better P1. This could be done in a week by Chip, and while it would no longer be what we all really would like, we would be elated to see a better P1 this year, and, I at least, would then be happier to wait just a little longer for that elusive P2.
Just think about it...
Chip spends 4weeks and takes a few bits from P2 for a better compatible P1...
* P1 compiler compatible (not necessarily binary compatible, but PASM compatible
* 160+ MHz
* maybe 2 clock instructions (dual port COG RAM)
* maybe 2KB LUT (no streamer, just extended cog ram) - requires extended jump/call method or relative jmp/call
* 512KB HUB RAM (1:8 instead of 1:16 access)
* maybe 16 COGs
* possible encryption
* use P2 frame - could this add ADC ?
* 64 I/O
* SPI Flash
Advantages...
* PASM software compatible (require recompile)
* Spin1 compatible, soft (not in ROM), permits faster spin plus later extensions using LUT
* PropGCC C compiler compatible
* BlocklyProp compatible
* Proves the ONSEMI process while yielding a saleable chip that most commercial customers wanted for years
Everything that you said makes sense. Maybe Chip and Ken will seriously consider your suggestions.
EDIT: Oh wait. You didn't mention hub exec. We have to have hub exec. And Smart Pins. They're basically done. Why not just freeze the P2 design as it stands today, and go with that. I think if we know that the instruction set and encoding will not change dramatically people will get more enthused about testing and developing tools. Only bug fixes should be allowed in the P2 design from now on, and no more new instructions and instruction shuffling.
It sounds like Parallax is in a holding pattern right now trying to figure out how they're going to fund the rest of the project. Given the salaries, services, equipment and supplies that they've used on the P2 project so far they must have spent 2 or 3 million dollars on P2 development to date. I'm guessing the final push will cost them another half million dollars. I suppose it's easier to dribble out $200k per year for 10 years than to do a final $500k in one year.
You ask for almost everything in the P2... What you ask for would take many months at a minimum, and likely multiple years to actually complete, and it would not be compatible with anything, new tools/compilers/etc. would all need to be written.
Others,
Chip won't consider the P2 done until he has Spin2/PASM2 done, stop trying to argue against that. Ken won't consider it a product he can ship until it has cross platform support for building both Spin2/PASM2 and C/C++ code. These both have been state by them many times over the years of development.
Hopefully, the funding issue will be resolved soon. Once this happens we're probably a year away from product launch. So it seems like the launch countdown is at T minus one year and holding right now.
Unfortunately, with Chip doing Spin for the P2 and outside contractors doing C, I don't see this happening.
-Phil
-Phil
Spin that is compiled using spin2cpp with execute using hub exec instead of using an interpreter running out of cog memory. I think hub exec will be the normal mode of operation on the P2. There won't be much of a need for a Spin interpreter that execute bytecodes. A bytecode program that fits in 32K on the P1 will probably take less than 100K on the P2. There will still be over 400K left for data. The only time someone will need to resort to byte codes is when they will need almost all of the 512K for data or they have a huge Spin program that has 16 times as much code as the largest P1 program. I would hope that PropGCC for the P2 will have a CMM mode that can handle those situations as well.
I have no predjudice against Spin, for code-space efficiency it is unbeatable! And not everybody's projects require the blistering speed of PASM all the time.
My projects though, DO always require the blistering speed of PASM and I'm absolutely happy with the status quo with the Prop 1. It is good to know that if I ever need to do some high-level stuff in Spin, then that option is instantly available. That is a seriously brilliant feature.
There are many reasons why, but hubexec is a big one.
What you are asking for barely works in any other coding land (even PC/Mac/Linux), and even then only for stuff like .NET based languages and runtime.
Having C/C++ call out to Spin is not as trivial as just calling some PASM hubexec code, it has to fire up the spin runtime/interpreter in another cog. Probably a better solution is to have the Spin code compiled to PASM and run in HUBEXEC then the C code can just call it. The other way around is a little simpler, since Spin2 will be able to just call into PASM hubexec code pretty easily. You still have to manage passing arguments, and each of them does it very differently (e.g. the C code can't get at the Spin COGs internal registers or stack.
I think the existing methods that work for P1 (spinwrap, etc.) are probably good enough, maybe just make it simpler to setup and use via the IDE?
Yeah, hubexec changes everything! So does the LUT.
Yeah, I figured as much.
What Phil wants is to be able to have an IDE with a Spin file in one tab, and a C file in another, and hit compile and it all gets put together into one binary. On top of that the spin or C can just call functions on either side, and I presume access global variables across the boundary (since that would be kind of required in his scenario). It's a fantasy land that doesn't really exist anywhere except in .NET languages (and even then with limitations and caveats).
I just don't think that is feasible or required. As long as C/C++ code can utilized "drivers" written in PASM with Spin glue (which we have already), then that's the primary need. Going the other way is probably way less desired, but also significantly easier since the compile C/C++ code is just PASM, and Spin2 having inline PASM should allow you to connect up to the C functions as long as you have the addresses (which can be handled with some simple link like step).
Is there no way that we can make this happen? It would eliminate a lot of redundant development and help to unite two heretofore warring Prop dev factions. I think that alone makes it important enough to pursue.
-Phil
We are waiting to see how we are going to pay for the next steps, which are going to cost maybe $250k. We are being conservative in our approach here. While these expenses occur, Parallax needs to maintain positive cash flow. Until certain doors close/open, we are not sure about how we are going to address this matter. So, for now, I am working on the Spin interpreter, making little changes to the Verilog, along the way. I really can't imagine that there will be any more disruptive changes to the design between now and when we synthesize the final version. Meanwhile, all the analog layout changes have been made in the pad frame, based on the shortcomings of the last test chip. OnSemi will have a shuttle in July/August that we will run our new analog test chip on. That will probably come back in October. If everything is "go", we can proceed to make the final commitments to getting the silicon into production around or before that time frame.
Do you mean another test chip like the previous one? ie not a usable chip, just a test of the outer ring??? If so, it seems a waste not to be able to test the rest of the chip, even if part has to have test pins instead of io pins.