As I see it "Beginners" maybe can accept "Single core" solution with 7 others COG's as Drivers ---> BUT I'm are sure that more advanced ones Wait much more from Propeller.
Okay, I see that as a challenge! :-)
I'll think about this over the weekend and see what I can do. Thanks!
So then it follows that if you give each xBasic External (LMM) COG an offset (base address) to a chunk of space into the BIG memory and size for that chunk so it could range check things, each/any COG could run xBasic HUB, xBasic External or PASM drivers?
So then it follows that if you give each xBasic External (LMM) COG an offset (base address) to a chunk of space into the BIG memory and size for that chunk so it could range check things, each/any COG could run xBasic HUB, xBasic External or PASM drivers?
{sorry, I'll crawl back under my rock......}
It isn't that they need their own chunk of external memory. That part is easy. The problem is that the code to interface to external memory uses a cache to avoid having to go off-chip for every single access. It's hard to share that cache between COGs unless you use locks and that will slow things down dramatically.
"Will having 1 COG xBasic (HUB or External) + 7 COGs of xBasic (HUB) be worth the extra effort?
Will many more users adopt xBasic because of that feature or does it not matter?"
That is the big question, at this point you are not even sure if more "...users adopt xBasic..." as it is today. I guess the bigger question is, why are you coding xBasic to begin with, to see how many users you can get, or do you want to come with a piece of software that is really great, regardless of how many people end up using it. At least you will be losing some time and effort, not like ICC where they lost a lot more.
Ok, thanks, I understand now. Ugliness would prevail!!
Ugliness would prevail cache or no cache
The problems incurred by using external memory are:
All 8 threads would behave like one big serialized thread
(one can argue that this happens anyway with HUB access).
Independent COG hardware would have to share memory with locks.
Cache if any would thrash more often (page fault + buffer swap).
Locks and some HUB memory (1KB to 8KB selectable) may be needed for cache, but using one solves several problems too:
Only one COG talking to the hardware.
Not all requests need to hit the hardware.
Cache drivers can easily be set at load time instead of compile time.
For synchronous back-store devices, the data rate is higher.
For my mini project I am using Spin, but I have a great fear that either I will run out of cog memory or hub memory or both.
So, it's not really about having lots of users. It's not some kind of weird nerdy competition.
It is simply easier to continue working on a project that is "appreciated" by users.
Will users get anything out of it? That's why I asked the questions you quoted.
This version has fixes to several problems identified by Mazzini and others.
PM me your address if you want a free SpinSocket 4MB Flash module.
I have removed bean.bas from samples and added the GameBaby sources.
Please download and install the new version and report any errors.
Thanks.
Feature Requests TBD:
Add Project Workspace for user source files - Sapieha
Add "last folder" memory to open dialog - JM
Add zoom to compiler file/line error - David
Other:
Research starting Spin programs from xBasic.
Add Advanced mode for building hardware and cache drivers.
Think about ways to start xBasic programs in COGs.
I downloaded last zip file.
In it it show version "xBasicIDE_0_17_setup.exe" -- BUT after install in About it still show 0.16 -- and in preferences I can't find workspace
I'm not sure what you mean but we have used Cygwin GCC, Linux GCC, Mac OS X Xcode (which is based on LLVM), Microsoft Visual C++ and the compiler that comes with Qt to build the xbasic compiler. The IDE is built with Qt.
Thanks to all of you! I just downloaded it and I am excited to test it....... having the chance (for me) to choose between Spin (that I like) and Basic (at least two flavors) is really great!!!!!
Comments
Okay, I see that as a challenge! :-)
I'll think about this over the weekend and see what I can do. Thanks!
{sorry, I'll crawl back under my rock......}
It isn't that they need their own chunk of external memory. That part is easy. The problem is that the code to interface to external memory uses a cache to avoid having to go off-chip for every single access. It's hard to share that cache between COGs unless you use locks and that will slow things down dramatically.
Will many more users adopt xBasic because of that feature or does it not matter?"
That is the big question, at this point you are not even sure if more "...users adopt xBasic..." as it is today. I guess the bigger question is, why are you coding xBasic to begin with, to see how many users you can get, or do you want to come with a piece of software that is really great, regardless of how many people end up using it. At least you will be losing some time and effort, not like ICC where they lost a lot more.
Ray
The problems incurred by using external memory are:
All 8 threads would behave like one big serialized thread
(one can argue that this happens anyway with HUB access).
Independent COG hardware would have to share memory with locks.
Cache if any would thrash more often (page fault + buffer swap).
Locks and some HUB memory (1KB to 8KB selectable) may be needed for cache, but using one solves several problems too:
Only one COG talking to the hardware.
Not all requests need to hit the hardware.
Cache drivers can easily be set at load time instead of compile time.
For synchronous back-store devices, the data rate is higher.
So, it's not really about having lots of users. It's not some kind of weird nerdy competition.
It is simply easier to continue working on a project that is "appreciated" by users.
Will users get anything out of it? That's why I asked the questions you quoted.
Cog0 - instruction 0
Cog1 - instruction 0
Cog2 - instruction 0
Cog3 - instruction 0
Cog4 - instruction 0
Cog5 - instruction 0
Cog6 - instruction 0
Cog7 - instruction 0
Cog0 - instruction 1
Cog1 - instruction 1
Cog2 - instruction 1
Cog3 - instruction 1
Cog4 - instruction 1
Cog5 - instruction 1
Cog6 - instruction 1
Cog7 - instruction 1
xBasic is a multi-platform open source project.
This version has fixes to several problems identified by Mazzini and others.
PM me your address if you want a free SpinSocket 4MB Flash module.
I have removed bean.bas from samples and added the GameBaby sources.
Please download and install the new version and report any errors.
Thanks.
Feature Requests TBD:
Add Project Workspace for user source files - Sapieha
Add "last folder" memory to open dialog - JM
Add zoom to compiler file/line error - David
Other:
Research starting Spin programs from xBasic.
Add Advanced mode for building hardware and cache drivers.
Think about ways to start xBasic programs in COGs.
I downloaded last zip file.
In it it show version "xBasicIDE_0_17_setup.exe" -- BUT after install in About it still show 0.16 -- and in preferences I can't find workspace
Good Day,
Is cygwin gcc your compiler ?
Best regards
I'm not sure what you mean but we have used Cygwin GCC, Linux GCC, Mac OS X Xcode (which is based on LLVM), Microsoft Visual C++ and the compiler that comes with Qt to build the xbasic compiler. The IDE is built with Qt.
Actually, an much earlier version of xbasic compiled and ran on the Propeller under either Catalina C or ZOG but it was very sluggish.
Carlo