A $25 ARM board coupled with a Prop to make a cigarette packet sized
embedded system with it's own Prop dev environment. With Prop GCC and the
open source version of the Spin compiler this will be possible.
I'd just use it to run BST and go back to programming my Propeller.
Exactly. But not BST unless you can get BradC to compile it for ARM.
Sonic,
If the cognew function stays the same, would I still need an array of longs to
use as the address for the class/function I am launching into the cog?
cognew in any language would always be the same as it is a hardware feature of
the Prop. It loads 512 LONGs to COG and starts it running.
However in C those longs can come from:
a) Some C/C++ function(s) compiled for the job
b) Some assembler language code.
c) Some pre-compiled code (C/asm) that just happens to be available as a binary
"blob"
d) Perhaps some other places I have not thought of.
Ahh. Thanks so much. I think I would just use an array in C++ because that seem easiest for me. If I remember how to do it correctly.
Okay, to the textbook!
But Sonic, If you just use an array for cognew in C++ where are you going to get the content of that array from?
Probably you will write it in C or asm and away you go. Simple.
However if you have a working piece of assembler code written in the Spin Tool (say) it is possible to extract the compiled pasm code as a "binary blob" for use in an array as you say. That's probably a bit harder in the end.
True, but I remember being able to create arrays in C++, so I would do it that way and i think you can also create longs too. If not I've got seven chaos emeralds and fifty rings so.......
There are a few ways to generate cog code that can be started from a C program. You can put a PASM program in a Spin file, and assemble it with BSTC using the -c option to generate a DAT file. The DAT file is then converted to an array and put in a .o object file with propeller-load.
Another method is to write a Propeller GAS file, which is very similar to PASM code. The main differences are the GAS (Gnu ASsembler) directives and the fact that labels are treated as byte addresses instead of long addresses. GAS assembly files are compiled into object files, which can then be linked together into and ELF file. The ELF file is then "localized" and converted to an array in an object file that can be linked to another C program. It's a bit confusing, but it works.
A third method is to write the cog code in C, and compile it with the COG memory mode. It is handled similar to a GAS assembly file.
I believe it's also possible to start up another C LMM cog from a C program, sort of like starting a Spin cog from a Spin program. I'm not clear on the details of this, but it would involve starting up a cog with the C LMM interpreter and pointing it to the appropriate C function you want to start.
I would suspect that when you use C or C++ the thing you are mostly loading into COG is:
a) A copy of the LMM kernel that will the take care of executing the instructions of some C function within your program from HUB memory.
b) A copy of the native Propeller instructions, compiled from one of your programs functions, that will execute directly from within COG.
c) A binary blob of code that has been compiled by some other tool and linked to the C program you are building.
So no need to worry about any arrays ever.
BUT
You could have binary blobs of code stored in files, on a SD card say, which your program reads into some buffer array and the starts a COG with.
Parallax has been very slow to to realize and/or embrace this open source
phenomena. Luckily they are now fully behind it with the sponsoring of the GCC
tool chain and a total rewrite of the Spin compiler as an open source tool in
the near future.
Yes, these are positive developments. But what has "open source" got to do with it? That's a completely separate issue. You can provide "open standards" without "open source".
propgcc may still be in beta but I don't think "very immature" is fair. It has
handled everything I have thrown at it and performed optimizations I would
never have imagined. "C code compiled to run in a COG", your kidding me right?
Ok, I withdraw the "very" As for cog-based C, I think I may have been the first one to suggest running C in a cog! (I can't prove this, but I think it is the case - someone else is welcome to trawl back through the various forum threads and prove me wrong). I suggested someone take the tiny C compiler (which implements a subset of C and is targeted at the x86 architecture) and use it to build a cog-only C compiler. Well, this is what has happened, except that they used GCC instead. I agree this is a better approach.
As ever, C++ is a perfectly fine language for micro-controllers. Stay away from memory and time eating features and it performs as well as C code written to do the same job. In fact it can generate identical code as object oriented code written in C. You only take a hit in C++ overheads if you are doing things that would give you those overheads in C as well.
I know micro-controller C++ implementations may come with out all the big time standard library features but language wise the Arduino C++ is no "subset".
Heater, we've had this argument several times, and I refuse to get into it again. The Arduino implements a subset of the C++ standard. They say so themselves. Go argue with them
But what has "open source" got to do with it? That's a completely separate
issue. You can provide "open standards" without "open source".
Open source has got everything to do with it.
Consider Parallax and the Propeller. One of the big selling points of the Prop
is the flexibility of creating peripheral devices, UARTS, SPI etc etc in
software rather than having the rigidity of dedicated silicon functions. However
a lot of users are not going to want to spend time creating all those
peripherals themselves, so to make this idea work it is necessary to have a pool
of ready made software functionality. This is greatly aided by having a
community of users donating their creations to the cause because Parallax may
not have the resources to cover all the ground. Hence the OBEX. Which is a very
wonderful thing.
But wait a minute. Why would people want to donate their creations to an open
source pool when the very tools they have to create them are not open source
themselves? As Parallax is in the business of shipping chips and hardware, even
giving away the Prop Tool for free would it ever have hurt them to open source
the Prop Tool (Assuming we got around some licensing hinderences it has)?. Why
the one sidedness?
As it happens the Prop community has not worried about this much and the OBEX
has grown but in many other cases I believe having an open source chain from
top to bottom has been a great help. The Arduino being a case in point.
Perhaps, just perhaps, the OBEX and the PropTool would be in much better shape
now had it all been open sourced from the get go.
I think I may have been the first one to suggest running C in a cog!
As I remember it you were the first.
And I was probably the first to retort that it is a really dumb idea.
That native PASM is not suited to C, what with the lack of a stack and
indexed addresing, and the obviously far to small a space to work in etc etc.
But blimey, they did it anyway and it works and it can be useful.
I believe I created the first cog code in C that is actually useful, a C version
of FullDuplexSerial.
Heater, we've had this argument [C vs C++] several times, and I refuse to get
into it again.
Oh shucks;)
The Arduino implements a subset of the C++ standard. They say so themselves. Go
argue with them
Looks like I have to pull up an Arduino IDE and see what parts of C++ it does
not like.
As for cog-based C, I think I may have been the first one to suggest running C in a cog! (I can't prove this, but I think it is the case - someone else is welcome to trawl back through the various forum threads and prove me wrong). I suggested someone take the tiny C compiler (which implements a subset of C and is targeted at the x86 architecture) and use it to build a cog-only C compiler. Well, this is what has happened, except that they used GCC instead.
The PropGCC team decided to implement the COG mode first. By doing it this way we (mostly Eric and Ken) were able to get the compiler working fairly quickly in COG mode, and we were able to build on this to get LMM working.
Code can be written in the COG mode to not use the stack by using register variables and performing native function calls. However, the stack is available to the COG mode, which provides for stack variables and normal C function calls that allow for recursive calls.
I believe in the last couple of weeks these items have been discussed many times.
The conclusion is Parallax has not supported the Prop with software and or tools as other micro-controllers do to get there product going.
Another point is i believe the Prop is a micro-controller not a laptop. It works in embedded application and any more that that it is a stretch.
The fact it has eight cores is interesting and explains how it had been programmed by the inner circle to do amazing thinks but the memory per core and hub memory size are just toys in today's market.
What i would like is to do is play with this toy, as it is, but with Parallax getting behind Brad's BST. I wish they would pay him lots of money so i can know that native MAC OS X supports will continue.
Last point is why has not Parallax been responding on these "why not" post to reassure the community?
Be sure that Mac support is going to be there for a long time. With or without BST.
Parallax do generally pop up with reasoned statements about what is in the pipeline and what is planned. They do not respond to every thread like this that pops up, which I think is quite reasonable.
Interesting conversation. The lack of a standardized C that is integrated into the IDE that allows for quick startup has been a problem. I think the new GCC C and IDE for that will really break down barriers for lots of people to use the propeller - especially in the educational community. Although it might run slower not being fully contained in a COG, that is plenty fast enough for lots of us. Also, it should be an even better fit for PropII.
I have scanned through this thread. It has taken place while I slept. Let me add my 2c.
Parallax should have released the source of PropTool (less the bits they cannot share due to licencing). That would have sped up the development of homespun and bst, allowing both Michael and Brad to concentrate on adding more features. Parallax still has not released anything here, although I guess anyone now requiring it could ask directly. This has held back prop development enormously.
Parallax were slow to realise C was required. They are now embracing it. Personally, I am still critical they did not embrace Catalina.
Both of the above statements are however, history. However, I must make this point very clear... Parallax have been very active in helping us. Way better than any micro supplier I have ever known. And they have been very open, just not in the ways we now realise. I guess hindsignt is wonderful, but it just doesnt help to dwell. If we (as a group of forum members) realised this, we could have lobbied Ken & Chip. They would have listened to our arguments, and if convincing enough, would have acted - that I am certain about. But we did not realise either - yes we did complain - but not forcefully enough with proper arguments. So we failed too!
Now, the prop is not an arm, intel, etc. It was never designed, and still isnt designed (nor the PropII) for a full-blown tablet or pc replacement. It has other markets though where the internal hardware can be utilised to its advantage.
SPIN:
IMHO, the spin interpreter is really great. IMHO with hindsight, we needed a new front language that was simpler in syntax. While I like the forced indentation, it has led to some problems.But I think the syntax is a problem. I would liked to have seen a basic front end developed. Unfortunately, without the compiler source being open, this has not been possible without a huge development. Hobbyists are being forced into C/C++ where I do not believe they should really be. This is OK for a professional. Professionals will learn spin anyway. Spin has the advantage of being extremely tight code (small code space), although slow. But speed is not usually important for the main program objects. And where it is, pasm runs well, and so does LMM. LMM has also been held back because of a lack of an open compiler.
Now I need to get some work done, and move forward.
The PropGCC team decided to implement the COG mode first. By doing it this way we (mostly Eric and Ken) were able to get the compiler working fairly quickly in COG mode, and we were able to build on this to get LMM working.
Code can be written in the COG mode to not use the stack by using register variables and performing native function calls. However, the stack is available to the COG mode, which provides for stack variables and normal C function calls that allow for recursive calls.
Yes, that's one of the threads I remembered, but as I mentioned there, it had already been discussed previously (maybe with OBC? Not sure). By this thread I was trying to get someone to take it up as a serious project, and had in fact already investigated Tiny C as a possibility- but no one did. At the time, I seem to recall we were all still too busy arguing over whether C was really any use at all on the Propeller
I suggested Tiny C would be a good approach because the subset of C you can support in a cog is very small anyway. The GCC team chose to do it differently - and better! But even so, the code that can be run in a cog is very limited.
Parallax were slow to realise C was required. They are now embracing it. Personally, I am still critical they did not embrace Catalina.
Just to be clear - I understand Parallax's decision to adopt GCC, and I am not critical of this particular technology choice. For professional users It makes good sense. I'm just a bit concerned that Parallax may once again be heading down the path of providing only a single (and in this case somewhat impenetrable) development platform - just one that is based around C++ instead of Spin. I'd rather they concentrated on providing the basic "enabling" components, tools and technologies that would encourage people to use the chips using any languages and tools they liked.
To go back to another point raised earlier - the fact that GCC is "open source" is not a substitute for providing a good set of bullet-proof open and standard software components (implemented in PASM) that could be used from any language.
The thing I really can't understand is that the Propeller makes this so easy to do! As a hardware architecture, this chip is a software developer's dream! So why can't I run a different language on every cog, depending on what the cog has to do? Well, in fact you can - but it is currently quite difficult because Spin was never designed with this possibility in mind. Are we making the same mistake again?
To Mr. richaj45. It may not be the smartest thing to put in a laptop, put think about a microcomputer. You could get this micro computer to be as big as the educational kit, and mount it on a robot. Add a couple cables and spin code then BAM!!!!!!! how's that for an embedded micro computer application!!!!????
I'm just a bit concerned that Parallax may once again be heading down the path of providing only a single (and in this case somewhat impenetrable) development platform - just one that is based around C++ instead of Spin. I'd rather they concentrated on providing the basic "enabling" components, tools and technologies that would encourage people to use the chips using any languages and tools they liked.
Ross.
Ross, no need to worry. So much progress has been made in the development tools lately. We won't be providing a single tool, but will simply be adding C to the choices available to our customers. And as you requested, the recent conversion of the X86 compiler to C/C++ http://code.google.com/p/open-source-spin-compiler/wiki/CurrentState is also a step in the direction of providing the basic "enabling" components. This is a long-term project and results don't come too fast.
The open-sourcing isn't a ticket for us to get out of development tools, as you know. But we get to add the open-source ability for free, so why not. . .
Parallax should have released the source of PropTool (less the bits they cannot share due to licencing). That would have sped up the development of homespun and bst, allowing both Michael and Brad to concentrate on adding more features. Parallax still has not released anything here, although I guess anyone now requiring it could ask directly. This has held back prop development enormously.
Cluso99, thank you for the message. There is no reason we couldn't release the whole source, less the licensed part. It's always been our opinion that it wouldn't be that useful. It took a year to convert the compiler from X86 to C/C++ and now that this project is complete it makes more sense. Chip and I discussed a release without it on numerous occasions but felt it would do more harm than improvement. Parallax has long-term plans, and the steps we take should be done properly and not in haste, which is why it takes longer than customers expect it should sometimes.
BST couldn't be released because he also wanted an official Parallax compiler. Brad will also be a step closer to sharing his tools, should he desire to do so.
The open-sourcing isn't a ticket for us to get out of development tools, as you know. But we get to add the open-source ability for free, so why not. . .
Ken Gracey
Hi Ken,
Thanks for the response. As you know, I'm not against open source - I'm very much in favor of it! I was just pointing out that it is not really relevant to the discussion. But if you get it for free, then by all means!
Can you just confirm that there will be a Parallax-supported Spin Compiler available for the Propeller v2 (i.e, one that compiles Spin programs to Spin byte codes, that can be downloaded and executed using a single-cog Spin Interpreter)?
I won't quibble about minor language differences or whether or not it is open or closed source - I just mean something that is generally equivalent to the existing Propeller Spin Compiler and Spin Interpreter as it exists today on the Prop v1. The reason I ask is that some posters (not necessarily in this thread) seem to imply that the only Parallax-supported Prop v2 tools will be entirely built around GCC, with Spin programs having to be translated to C++ to be executed on the Prop v2.
This would be a fairly dramatic difference to the Prop v1, but at least if we know this is going to be the case then the other tool makers in these forums can plan accordingly.
Thank you for sharing Ken, as this makes me more excites to try out the prop 2, but like Mr.RossH stated, the C/C++ features would be nice, would it still use spin for backward compatibility, or would that be impractical, after all, having one highlevel language means there needs a to be C/C++ interpreter, along with one for Spin.
Can you just confirm that there will be a Parallax-supported Spin Compiler available for the Propeller v2 (i.e, one that compiles Spin programs to Spin byte codes, that can be downloaded and executed using a single-cog Spin Interpreter)?
I won't quibble about minor language differences or whether or not it is open or closed source - I just mean something that is generally equivalent to the existing Propeller Spin Compiler and Spin Interpreter as it exists today on the Prop v1. The reason I ask is that some posters (not necessarily in this thread) seem to imply that the only Parallax-supported Prop v2 tools will be entirely built around GCC, with Spin programs having to be translated to C++ to be executed on the Prop v2.
Ross.
Hello Ross - yes, I can confirm that there will be a Parallax-supported Spin compiler available for the Propeller 2 which can be downloaded into the chip. In the same way a C kernal could also be downloaded at the time of programming. It's not going to be built into ROM.
We haven't decided at this stage whether or not the Propeller 2 tools will use our Eclipse front-end or not.
Hello Ross - yes, I can confirm that there will be a Parallax-supported Spin compiler available for the Propeller 2 which can be downloaded into the chip. In the same way a C kernal could also be downloaded at the time of programming. It's not going to be built into ROM.
We haven't decided at this stage whether or not the Propeller 2 tools will use our Eclipse front-end or not.
Just to clarify a bit more for people other than yourself, the PropGCC effort will certainly use our Eclipse front-end. And depending on what we learn in the next month as we approach the beta we will know if we could use the same front-end for all other language efforts. As you will be at Parallax on Wednesday we can talk more about this [probably with Chip!].
What can I say? Several pairs of speed shoes and cans of sonic speed and I'm ready. Plus I like the propeller and will continue to have enthusiasm for what I wish to pursue as a future careeer!
Comments
The fun would be here: http://www.raspberrypi.org/
A $25 ARM board coupled with a Prop to make a cigarette packet sized
embedded system with it's own Prop dev environment. With Prop GCC and the
open source version of the Spin compiler this will be possible.
Exactly. But not BST unless you can get BradC to compile it for ARM.
Sonic,
cognew in any language would always be the same as it is a hardware feature of
the Prop. It loads 512 LONGs to COG and starts it running.
However in C those longs can come from:
a) Some C/C++ function(s) compiled for the job
b) Some assembler language code.
c) Some pre-compiled code (C/asm) that just happens to be available as a binary
"blob"
d) Perhaps some other places I have not thought of.
Okay, to the textbook!
Probably you will write it in C or asm and away you go. Simple.
However if you have a working piece of assembler code written in the Spin Tool (say) it is possible to extract the compiled pasm code as a "binary blob" for use in an array as you say. That's probably a bit harder in the end.
But what are you going to put in the cogcode array?
Another method is to write a Propeller GAS file, which is very similar to PASM code. The main differences are the GAS (Gnu ASsembler) directives and the fact that labels are treated as byte addresses instead of long addresses. GAS assembly files are compiled into object files, which can then be linked together into and ELF file. The ELF file is then "localized" and converted to an array in an object file that can be linked to another C program. It's a bit confusing, but it works.
A third method is to write the cog code in C, and compile it with the COG memory mode. It is handled similar to a GAS assembly file.
I believe it's also possible to start up another C LMM cog from a C program, sort of like starting a Spin cog from a Spin program. I'm not clear on the details of this, but it would involve starting up a cog with the C LMM interpreter and pointing it to the appropriate C function you want to start.
I would suspect that when you use C or C++ the thing you are mostly loading into COG is:
a) A copy of the LMM kernel that will the take care of executing the instructions of some C function within your program from HUB memory.
b) A copy of the native Propeller instructions, compiled from one of your programs functions, that will execute directly from within COG.
c) A binary blob of code that has been compiled by some other tool and linked to the C program you are building.
So no need to worry about any arrays ever.
BUT
You could have binary blobs of code stored in files, on a SD card say, which your program reads into some buffer array and the starts a COG with.
Heater, we've had this argument several times, and I refuse to get into it again. The Arduino implements a subset of the C++ standard. They say so themselves. Go argue with them
Ross.
Open source has got everything to do with it.
Consider Parallax and the Propeller. One of the big selling points of the Prop
is the flexibility of creating peripheral devices, UARTS, SPI etc etc in
software rather than having the rigidity of dedicated silicon functions. However
a lot of users are not going to want to spend time creating all those
peripherals themselves, so to make this idea work it is necessary to have a pool
of ready made software functionality. This is greatly aided by having a
community of users donating their creations to the cause because Parallax may
not have the resources to cover all the ground. Hence the OBEX. Which is a very
wonderful thing.
But wait a minute. Why would people want to donate their creations to an open
source pool when the very tools they have to create them are not open source
themselves? As Parallax is in the business of shipping chips and hardware, even
giving away the Prop Tool for free would it ever have hurt them to open source
the Prop Tool (Assuming we got around some licensing hinderences it has)?. Why
the one sidedness?
As it happens the Prop community has not worried about this much and the OBEX
has grown but in many other cases I believe having an open source chain from
top to bottom has been a great help. The Arduino being a case in point.
Perhaps, just perhaps, the OBEX and the PropTool would be in much better shape
now had it all been open sourced from the get go.
As I remember it you were the first.
And I was probably the first to retort that it is a really dumb idea.
That native PASM is not suited to C, what with the lack of a stack and
indexed addresing, and the obviously far to small a space to work in etc etc.
But blimey, they did it anyway and it works and it can be useful.
I believe I created the first cog code in C that is actually useful, a C version
of FullDuplexSerial.
Oh shucks;)
Looks like I have to pull up an Arduino IDE and see what parts of C++ it does
not like.
The PropGCC team decided to implement the COG mode first. By doing it this way we (mostly Eric and Ken) were able to get the compiler working fairly quickly in COG mode, and we were able to build on this to get LMM working.
Code can be written in the COG mode to not use the stack by using register variables and performing native function calls. However, the stack is available to the COG mode, which provides for stack variables and normal C function calls that allow for recursive calls.
I believe in the last couple of weeks these items have been discussed many times.
The conclusion is Parallax has not supported the Prop with software and or tools as other micro-controllers do to get there product going.
Another point is i believe the Prop is a micro-controller not a laptop. It works in embedded application and any more that that it is a stretch.
The fact it has eight cores is interesting and explains how it had been programmed by the inner circle to do amazing thinks but the memory per core and hub memory size are just toys in today's market.
What i would like is to do is play with this toy, as it is, but with Parallax getting behind Brad's BST. I wish they would pay him lots of money so i can know that native MAC OS X supports will continue.
Last point is why has not Parallax been responding on these "why not" post to reassure the community?
Cheers,
Rich
Parallax do generally pop up with reasoned statements about what is in the pipeline and what is planned. They do not respond to every thread like this that pops up, which I think is quite reasonable.
Parallax should have released the source of PropTool (less the bits they cannot share due to licencing). That would have sped up the development of homespun and bst, allowing both Michael and Brad to concentrate on adding more features. Parallax still has not released anything here, although I guess anyone now requiring it could ask directly. This has held back prop development enormously.
Parallax were slow to realise C was required. They are now embracing it. Personally, I am still critical they did not embrace Catalina.
Both of the above statements are however, history. However, I must make this point very clear... Parallax have been very active in helping us. Way better than any micro supplier I have ever known. And they have been very open, just not in the ways we now realise. I guess hindsignt is wonderful, but it just doesnt help to dwell. If we (as a group of forum members) realised this, we could have lobbied Ken & Chip. They would have listened to our arguments, and if convincing enough, would have acted - that I am certain about. But we did not realise either - yes we did complain - but not forcefully enough with proper arguments. So we failed too!
Now, the prop is not an arm, intel, etc. It was never designed, and still isnt designed (nor the PropII) for a full-blown tablet or pc replacement. It has other markets though where the internal hardware can be utilised to its advantage.
SPIN:
IMHO, the spin interpreter is really great. IMHO with hindsight, we needed a new front language that was simpler in syntax. While I like the forced indentation, it has led to some problems.But I think the syntax is a problem. I would liked to have seen a basic front end developed. Unfortunately, without the compiler source being open, this has not been possible without a huge development. Hobbyists are being forced into C/C++ where I do not believe they should really be. This is OK for a professional. Professionals will learn spin anyway. Spin has the advantage of being extremely tight code (small code space), although slow. But speed is not usually important for the main program objects. And where it is, pasm runs well, and so does LMM. LMM has also been held back because of a lack of an open compiler.
Now I need to get some work done, and move forward.
Yes, that's one of the threads I remembered, but as I mentioned there, it had already been discussed previously (maybe with OBC? Not sure). By this thread I was trying to get someone to take it up as a serious project, and had in fact already investigated Tiny C as a possibility- but no one did. At the time, I seem to recall we were all still too busy arguing over whether C was really any use at all on the Propeller
I suggested Tiny C would be a good approach because the subset of C you can support in a cog is very small anyway. The GCC team chose to do it differently - and better! But even so, the code that can be run in a cog is very limited.
Ross.
Just to be clear - I understand Parallax's decision to adopt GCC, and I am not critical of this particular technology choice. For professional users It makes good sense. I'm just a bit concerned that Parallax may once again be heading down the path of providing only a single (and in this case somewhat impenetrable) development platform - just one that is based around C++ instead of Spin. I'd rather they concentrated on providing the basic "enabling" components, tools and technologies that would encourage people to use the chips using any languages and tools they liked.
To go back to another point raised earlier - the fact that GCC is "open source" is not a substitute for providing a good set of bullet-proof open and standard software components (implemented in PASM) that could be used from any language.
The thing I really can't understand is that the Propeller makes this so easy to do! As a hardware architecture, this chip is a software developer's dream! So why can't I run a different language on every cog, depending on what the cog has to do? Well, in fact you can - but it is currently quite difficult because Spin was never designed with this possibility in mind. Are we making the same mistake again?
Ross.
Ross, no need to worry. So much progress has been made in the development tools lately. We won't be providing a single tool, but will simply be adding C to the choices available to our customers. And as you requested, the recent conversion of the X86 compiler to C/C++ http://code.google.com/p/open-source-spin-compiler/wiki/CurrentState is also a step in the direction of providing the basic "enabling" components. This is a long-term project and results don't come too fast.
The open-sourcing isn't a ticket for us to get out of development tools, as you know. But we get to add the open-source ability for free, so why not. . .
Ken Gracey
Cluso99, thank you for the message. There is no reason we couldn't release the whole source, less the licensed part. It's always been our opinion that it wouldn't be that useful. It took a year to convert the compiler from X86 to C/C++ and now that this project is complete it makes more sense. Chip and I discussed a release without it on numerous occasions but felt it would do more harm than improvement. Parallax has long-term plans, and the steps we take should be done properly and not in haste, which is why it takes longer than customers expect it should sometimes.
BST couldn't be released because he also wanted an official Parallax compiler. Brad will also be a step closer to sharing his tools, should he desire to do so.
Ken Gracey
Hi Ken,
Thanks for the response. As you know, I'm not against open source - I'm very much in favor of it! I was just pointing out that it is not really relevant to the discussion. But if you get it for free, then by all means!
Can you just confirm that there will be a Parallax-supported Spin Compiler available for the Propeller v2 (i.e, one that compiles Spin programs to Spin byte codes, that can be downloaded and executed using a single-cog Spin Interpreter)?
I won't quibble about minor language differences or whether or not it is open or closed source - I just mean something that is generally equivalent to the existing Propeller Spin Compiler and Spin Interpreter as it exists today on the Prop v1. The reason I ask is that some posters (not necessarily in this thread) seem to imply that the only Parallax-supported Prop v2 tools will be entirely built around GCC, with Spin programs having to be translated to C++ to be executed on the Prop v2.
This would be a fairly dramatic difference to the Prop v1, but at least if we know this is going to be the case then the other tool makers in these forums can plan accordingly.
Thanks,
Ross.
Hello Ross - yes, I can confirm that there will be a Parallax-supported Spin compiler available for the Propeller 2 which can be downloaded into the chip. In the same way a C kernal could also be downloaded at the time of programming. It's not going to be built into ROM.
We haven't decided at this stage whether or not the Propeller 2 tools will use our Eclipse front-end or not.
Ken Gracey
And so ends a conspiracy theory.
Thanks for the morning laugh.
Just to clarify a bit more for people other than yourself, the PropGCC effort will certainly use our Eclipse front-end. And depending on what we learn in the next month as we approach the beta we will know if we could use the same front-end for all other language efforts. As you will be at Parallax on Wednesday we can talk more about this [probably with Chip!].
Ken Gracey