If you were willing to join the effort, you could have some influence.
Hmmmm. Except as a potential tester, I was never actually asked to join the effort - despite volunteering as soon as I heard about it.
But that's fine - my circumstances have now changed, and in any case I think I can now contribute best just by making Catalina the compiler that others will have to beat!
... I think I can now contribute best just by making Catalina the compiler that others will have to beat!
Oh boy: where to begin -- and I'm not even a C programmer!
Ross, with all due respect, without your active participation, the resulting C compiler probably won't beat Catalina. And the sad fact of the matter is: It. Won't. Matter. Whichever compiler receives Parallax's blessing will become the standard, and new users will have no clue that something better once shone in the limelight for its brief flicker of fame. So I would urge you to put aside any initially-dashed expectations of an invitation to participate, and to secure a well-deserved place at the table in the GCC development.
Here's the email transaction record I have for all to see.
By the time we were ready to recruit you (3 days after the GCC announcement), you had already publicly announced your intention to not be involved. How am I supposed to ask you to participate in a development role knowing that ???
Seems to me you were maybe disturbed by something other than your lack of time.
Usual story - when I had loads of time and also the inclination,
Parallax was completely uninterested - and now that they're interested,
I no longer have the time.
I'll be happy to help out wherever I can, except that for the next few
weeks I'll be a bit busy settling into my new job. But I'm happy to
offer advice if you want it - as you know, I'm not short on opinions
Ross.
On 16/06/2011 2:28 PM, Steve Denson wrote:
> Hi Ross,
>
> You probably noticed Ken Gracey's post in the ParallaxSemiconductor forum announcing specific details of proceeding with the GCC project.
> http://forums.parallax.com/showthread.php?131477-GCC-Eclipse-and-Propeller-2-seeking-developers&p=1009317&viewfull=1#post1009317
>
> This is an official invitation for you to participate in the project. At this point we are looking for demo coders and testers.
>
> Please respond with a brief email outlining the contributions you might make to the GCC project.
>
> -- end form letter --
>
> Since you have already announced some intention to not participate, I would understand if you are not interested. Still, I think you can add value, so I would appreciate it if you give it some thought.
>
> Thank you for your support.
> --Steve
>
Some interesting points from Heater on the previous page. I've been briefly distracted from C with the task of porting code from VGA to TV, but I'm bursting with some ideas that could be relevant for Zog, GCC and Catalina.
The external memory driver that the dracblade uses runs with 12 pins. Moving to TV from VGA saves 5 pins. And Ross says that the SD card is independent of external memory, saving another 4 pins. And I think that once the eeprom has finished loading, one of those pins could be H = external memory select, L = SD card select plus a bunch of uncommitted pins. The number of pins I think goes from 12 to 21.
Now with 21 pins, programs running in external ram can be a lot faster. Take 8 for data and 11 for address and one for /Rd and one for /Wr. Data is in blocks of 2k. Change blocks by changing the status of the eeprom pin, then latch out a high 8 bytes. I think this can be reduced to one latch for external ram.
In terms of code speed, maybe reduce from 20 pasm instructions to 3 or 4 per compiled instruction?
I've been using Ross' plugins for a while, as well as 'cogjects' which are pure pasm code separated out from their associated spin code. Cogjects end up being arrays in C which you store in external ram.
And now, with integrated Spin programs, these can be arrays as well. Pull them into a cog, run them, throw them away.
Free up virtually all hub ram for anything you want (for me, I'd like to use hub ram for a screen buffer).
One small snag I've run up against is that for really big C programs (200k) they do take a while to download. But with a nifty board that has just arrived, I think I can flip the SD between the propeller and being a disk drive on the PC. So downloads can be fast too.
And that means that you can start to add large libraries of spin code into a C program. Even obex code that you might only need infrequently.
All sorts of exciting possibilities.
One question I thought of reading the last few posts - Ross said something about adding your own spin interpreter. You could have many of these (they are just C arrays), but how would you go about making one? (I am still dreaming of a Big Spin interpreter running in a flat memory space of many hundreds of k, but this idea is becoming less and less relevant as Catalina morphs into a better and better software tool).
I've been using Ross' plugins for a while, as well as 'cogjects' which are pure pasm code separated out from their associated spin code. Cogjects end up being arrays in C which you store in external ram.
Glad you like the idea. I introduced it for ICC in 2008 and have been using it ever since. You should see what the latest Propeller loader does with this Need a memory manager for a new platform? Just add it to the platform .cfg file and use it - no screwing around with "target" files.
One small snag I've run up against is that for really big C programs (200k) they do take a while to download.
This is why I like the 10 pin 5MB/s read 4MB Flash solution - it comes on "instantly" after booting from the EEPROM. It's one of my Catalina target hardware devices to finish by end of summer ... assuming i don't have to screw with memory modes again to make something work ....
Here's the email transaction record I have for all to see.
By the time we were ready to recruit you (3 days after the GCC announcement), you had already publicly announced your intention to not be involved. How am I supposed to ask you to participate in a development role knowing that ???
Seems to me you were maybe disturbed by something other than your lack of time.
Usual story - when I had loads of time and also the inclination,
Parallax was completely uninterested - and now that they're interested,
I no longer have the time.
I'll be happy to help out wherever I can, except that for the next few
weeks I'll be a bit busy settling into my new job. But I'm happy to
offer advice if you want it - as you know, I'm not short on opinions
Ross.
On 16/06/2011 2:28 PM, Steve Denson wrote:
> Hi Ross,
>
> You probably noticed Ken Gracey's post in the ParallaxSemiconductor forum announcing specific details of proceeding with the GCC project.
> http://forums.parallax.com/showthread.php?131477-GCC-Eclipse-and-Propeller-2-seeking-developers&p=1009317&viewfull=1#post1009317
>
> This is an official invitation for you to participate in the project. At this point we are looking for demo coders and testers.
>
> Please respond with a brief email outlining the contributions you might make to the GCC project.
>
> -- end form letter --
>
> Since you have already announced some intention to not participate, I would understand if you are not interested. Still, I think you can add value, so I would appreciate it if you give it some thought.
>
> Thank you for your support.
> --Steve
>
Your timeline is only out by about a month and a half, but that's ok - you weren't to know. As I said before, I offered my services to Parallax and they chose not to respond at the time. After that (more than a month after) my circumstances changed - so that when you wrote your email (offering, as I said, the opportunity to be a tester only) I truly didn't have the time available (exactly as I said at the time). These things happen - don't feel offended.
I know this is a "Spin running from C" thread but this still could be a relevant question, as it is likely that when you are running lots of spin programs you would be running from XMM mode. So the question becomes one of optimising speed. The 512k memory chip is great but it does need one NOP as pasm is just a bit too fast. Would your 32mb memory chip solution run faster with more pins available? (how many pins is it using now?)
So this idea that one can strip the PASM out of Spin/PASM object and use it as a binary blob with another language has been around for a long time and dreamed up by people independently:
Jazzed has done it for ICC.
Ross has done it for his Catalina plugins
Dr_A has done it with his "cogjects" as C array declarations.
I implemented some such objects for Zog when I discovered BST could do the PASM assembling and extracting. I use the raw binary blob and link it with the C object files but it could as well load the binaries form files or elsewhere at run time.
Bill Henning has also discussed this idea with respect to an operating system of his.
Seems a sure bet that the Prop II GCC compiler will be using this technique as well.
Which reinforces my point that all objects being given the "Gold Standard" now should be checked that they can be used in that manner. For example the Spin part does not POKE into the PASM DAT section prior to launching as this is rather hard to link with C or other language code later.
I would suggest that such binary PASM blobs be referred to as "firmware" as that is in line with terminology in the industry. I.e an OS loads "firmware" into you WIFI chipset on your computer. We are doing exactly that here.
Ross, with all due respect, without your active participation, the resulting C compiler probably won't beat Catalina. And the sad fact of the matter is: It. Won't. Matter. Whichever compiler receives Parallax's blessing will become the standard, and new users will have no clue that something better once shone in the limelight for its brief flicker of fame. So I would urge you to put aside any initially-dashed expectations of an invitation to participate, and to secure a well-deserved place at the table in the GCC development.
Thanks,
-Phil
I disagree. You forget that there is already a C compiler that has Parallax's blessing - but you don't hear too much about it anymore. The company no longer even posts in these forums (as far as I am aware). The point is that if you stick to the ANSI standards, C is a commodity language - the actual C compiler is unimportant. A poor compiler will sink without trace - and a good one will succeed - whether or not Parallax supports it.
In any case, I developed Catalina primarily for my own purposes. I'm pleased (and flattered) if others find it useful, but if they don't then I don't take it as a personal affront.
So this idea that one can strip the PASM out of Spin/PASM object and use it as a binary blob with another language has been around for a long time and dreamed up by people independently
Yes, of course. But credit where credit is due - jazzed did develop the spinc utility, which simplified what we were all doing anyway (and he gets due credit on page 82 of the Catalina Reference Manual).
One day I must find time to look at Spinc. No idea what it is about.
Wait for Catalina 3.1 - it now does a lot more than just extract the first DAT segment as an array - and it is not specific to Catalina. It should work for any C compiler.
IMHO, the standard for "firmware", "cogjects", etc... simply should be a SPIN, C, FORTH, etc... component demonstrates how to launch the driver, and nothing more. "the driver" then operates stand alone, as PASM in a COG, or COGS, depending.
Support code, or library code, is optional, and should also be differentiated from "the driver", giving us, "the driver", which can simply be .cog file, or array to be fetched, used, stopped, removed, and "the library" which presents a interface to "the driver", where said library is SPIN, C, whatever, with higher level functions typically associated with use of "the driver".
@Phil, with SPIN + PASM, it's fairly easy to have "the standard" be a Parallax tool, as the ecosystem surrounding it is sourced by Parallax. We have Prop Tool and BST, for example, where people use both, but Prop tool is considered the reference platform.
Where the language exists outside of or is not sourced by Parallax the dynamics are different. There will be various environments, each with trade-offs. IMHO, this is a very good thing for Propeller users, as competing tool chains will shake out the better means and methods for doing things. Propeller chips present unique challenges! I've followed the development of Catalina, seeing those things worked through to good result. IMHO, we will find some of those things to be "the best" and others to be "a option", IF there is some competition in play.
Without that, then we simply have "the tools", which may or may not actually bring us the best means and methods. I submit that we don't realize all of "the best" ways to employ the chip, though we have now come very far, compared to the early, "hey! We need C" discussions. That Dr_A is employing a C environment in the fashion he is regularly, with performance even, is brilliant, and necessary.
Some of what has been done was due to lack of building blocks. A lot of what has been done to date is simply a artifact of how Props work, their memory model, COGS, etc... and that has to be boot-strapped, because it is new, and with the future chips, will be NEW AGAIN, in many ways. Having more than one effort is actually vital to seeing great tools for people to use.
Frankly, I'm eager to see what can be done differently, what should be done differently, and what that means for Propeller users, more than I am eager to see "the standard", largely because I do not see standards as productive, when the implications of the technology to be employed are not yet fully realized. IMHO, we are a whole lot closer to that on P1 today than we were when the C journey began. My point here is not to say we still don't understand P1. I think we mostly do, but that some competition was important. Imagecraft took one approach, Ross another, and over time, we saw where that all played out.
On P2, it's gonna have to happen again, because that chip is going to be "new" again, and we will all benefit AGAIN.
The existing efforts were hobbled somewhat. I'm sure others can comment more specifically, but I clearly saw the lack of a open SPIN compiler, and macro-assembler as barriers to this kind of development. Frankly, I'm most excited about seeing a full assembler that operates stand alone, and that is memory model aware as "the tool" needed, more than I am C, but that's just me, and my preference for SPIN + PASM, and no need to do C, though I do have interest.
Finally, there is the very real unresolvable conflict in play here between things being open and flexible enough to allow software people to "just do it", if they need to, and standard tools that constrain things, simplify and streamline. These goals are mutually exclusive, though it is very clearly possible to split the middle and give people some of both worlds, should they need it. IMHO, that is as good as it ever gets, if the technology is to see broad acceptance, outside the community of people who are alpha, early adopter types, who will invest far more than the average user would.
So let the games begin! It is just not a bad thing. In the end, as Ross points out, the community of Propeller users only stand to benefit longer term. There is very little loss, other than some unavoidable duplication of effort in the shorter term.
The real lesson here is open vs closed development. Imagecraft was closed, and really couldn't contribute to the ecosystem needed to build the better tools. As we got basic blocks out in the open, things took off. Remember the SPIN discussion way back when? Closed was good, but... when Hippy started to crack the SPIN nut, with Chip seeing what was going to happen, showing us Pnut, that kicked off a ton of things.
Finally, IMHO, the only real potential tragedy would be either, some closed development endorsed as standard, or a turf war, which ends up being the same constraint. If that is avoided, the product of the work to come will benefit everybody in the end.
IMHO, the standard for "firmware", "cogjects", etc... simply should be a SPIN, C, FORTH, etc... component demonstrates how to launch the driver, and nothing more. "the driver" then operates stand alone, as PASM in a COG, or COGS, depending.
Er.. not really. When we talk about "cogjects" or "firmware" we are talking about the binary code that gets loaded into a COG when the COG is started. As it stands now most of those COG binaries are written in PASM but potentially they could be written in any language. I believe we already have a version of BASIC that generates COG code.
The "cogject" or "firmware" idea has a number of facets:
1) That those COG binaries can be fetched from anywhere. Maybe built into your program as Spin does it now. Maybe read from EEPROM, or FLASH or SD card etc. Where ever it comes from it is used to start a COG. Hopefully the buffer space used to do this can be reused later, saving precious HUB memory.
2) Those COG binaries can be used from any language, Spin, C, Forth etc etc without having to make special versions for each language.
Now 2) imposes some requirements on the COG code:
3) There should be a clearly defined and well documented interface for the COG code. This at least includes a) What parameters it expects to get via PAR on start up. b) What the interface between it and the user program is through HUB memory. Typically there are commands, status and data to be exchanged when running. So a "mailbox" or some such must be clearly spelled out for those who want to drive the thing from different languages.
4) There should be no tweaking of values within the DAT section prior to using it to start a COG. Currently it is often the case that Spin code sets up some values into the DAT section that is loaded to COG by way of configuration prior to starting the COG. That's OK from Spin at the moment as Spin and PASM are "linked" at compile time in the prop Tool or BST or whatever. However when working from C, for example, there is no "linkage" between the code and vars in the COG binary blob and setting such configuration items is not possible. Well you can do it if you know the offsets into the binary but then if a new version comes that moves things around it breaks your code.
As it stands many objects fall down on requirements 2) 3) and 4). For example FullDuplexSerial has an interface through HUB memory between the public Spin methods and the running COG. That interface is not documented. In addition it has at least one DAT item that must be set prior to launching. Obviously my C code knows nothing about that items location.
Currently before you can use an exiting object you need to stdy it very carefully, figure out how params get into it via PAR, figure out how the Spin/PASM interface works when running, and look for any values POKED into it prior to launching. Often changes to the PASM have to be made.
So, here we have the criteria I am looking for in "Gold Standard" objects that can support arbitrary languages. Perhaps there are some others I have not thought of yet.
I over simplified, really focusing only on the fact that "the driver" needs to run without higher level language dependencies. That's primary in my mind.
I did a search on spinc, but I couldn't find the source code for it. It turns out that I wrote a similar program for it that I call getdat. It extracts the DAT bits from the top object of a Spin binary file up to the first 496 longs. It writes the data out as a raw binary file, but it could be modified to format it as C data or any other format.
getdat reads the PBASE and PCURR values from the 16-byte header to determine the starting address of the object and the first PUB. PBASE is always $10, but I allow for it to be something else. It then extracts the number of methods and referenced objects from the method table to determine the start of the DAT section. The source file is attached below.
Cool. Looks like there may be a problem there if the PASM start address given to cognew is not the beginning of the DAT section. I guess that is true of all the tools we have to do this currently.
Which means there is a rule five for language neutral COG firmware.
5) The entry point of the COG firmware must be at offset zero into the DAT section.
It's much easier to write with those rules in mind, knowing the PASM must run on it's own, than it is to parse through something, hoping to find and correct dependencies.
I'm kind of there on the use of "firmware" for such a construct. Interesting how "micro-code" makes great sense for LMM / XMM style work. "firmware" is a excellent parallel. This is such a interesting chip!
I find, limiting "variables" in the DAT for COG code to either:
constants - where a value is needed for runtime
, or
reserved working or uninitalized longs, where space is needed at run-time helps to make the firmware stand alone. I now try to use res as much as possible, thinking hard about whether or not anything else is really just a constant, or a potential dependency.
On that note, I still struggle with the lexicon. At times, I'll refer to a working long as a "register", because it's easy to think of it as such. Other times, like for a constant, I will say "constant", or more simply "long", or "cog-long".
With a instruction, I most often say "address" too. Would be nice to have one word that works in more contexts, simply because then new users could simply adopt one definition, and be understanding documentation better. Maybe there is one, and I've just not grokked it yet.
Dave, RossH's version of spinc.c/h are in the Catalina distribution.
I was able to find an old copy of spinc.cpp using google "site:forums.parallax.com spinc"
BSTC -c is a nice tool for extracting PASM also.
BTW, this idea of PASM blob loading is as old as the hills ... kind of like overlays
In any event, having a header file that describes the SPIN Binary structure has value and I've used spinc.h several times for that. Maybe a more formal header with data structures should be made.
A PASM driver mailbox needs a lock pointer parameter. Some drivers may want to share pins with hardware. I have run into this by trying to squeeze every ounce out of a Propeller's hardware. Most of the time like in the case of I2C all drivers can be put into the cog (EEPROM, RTC, Accelerometer, others where SCL is clock), but there are other times when devices may all want to use P0..7 as data for example and COG will not have enough memory.
Dave, RossH's version of spinc.c/h are in the Catalina distribution.
I was able to find an old copy of spinc.cpp using google "site:forums.parallax.com spinc"
BSTC -c is a nice tool for extracting PASM also.
BTW, this idea of PASM blob loading is as old as the hills ... kind of like overlays
Jazzed, spinc.c looks good -- much more professional looking than getdat. I like the way you defined structs to handle the various data fields in the Spin binary header and method table. However, I did see a goto in your well-structured code. I also like my program's name better than yours.
Most of the ideas of loading PASM blobs and starting up Spin cogs from a DAT area or from an SD file seem to have been developed during the first couple of years of the Prop. However, it's nice to see new applications of these ideas such as cogjects and starting up Spin cogs from Catalina.
The "starting up Spin cogs from Catalina" seems like a new idea. I've never seen a non-Spin program start a Spin COG before. PASM COGs, yes, but not Spin COGs. It's a neat trick.
However, I did see a goto in your well-structured code. I also like my program's name better than yours.
Three gotos if i remember correctly
Nasty habit i picked up from linux device drivers that forces one exit point so i didn't have to add multiple fclose calls. There are nicer C-ish ways to do it, and reviewers don't twitch.
The "starting up Spin cogs from Catalina" seems like a new idea. I've never seen a non-Spin program start a Spin COG before. PASM COGs, yes, but not Spin COGs. It's a neat trick.
I honestly don't know if its new or not. I knew it could be done, but I had not bothered doing it because I hadn't needed it. When I decided to actually do it, it turned out to be so simple that I don't think anyone can really justify claiming credit for it (other than Chip, since it's his original design for the Spin interpreter that makes it possible).
When I get home tonight I'll post the updated source for spinc, and also the spin_utlities (which is really just a wrapper around a simple call to _coginit(). Given that every C compiler on the Prop must have an equivalent to _coginit() (which is itself just a simple wrapper function around a COGINIT instruction) the code generated by spinc will be portable to all C compilers.
Potatohead is right. It is a shame we didn't have an open sourced compiler. Rather than Michael and Brad wasting their time redeveloping the compiler, their efforts (and others help) could have been put to much better use in adding conditional compliation (which both their versions now have) and macros (which we still don't have). Parallax is very open with many things, but this was/is a huge mistake, no matter how bad the code was. But, that is past history, although we still do not have an open compiler yet.
Parallax, why not release the code to Propellant (now) ??? It would still be of benefit now, even with the new compiler going to be available soon.
As for standards, there are some advantages and some disadvantages. IBM's PC standard was a disadvantage because they chose the 8088/8086 platform causing all sorts of problems in address space. The 68000 was a much better solution. We have suffered from processor bloat and software bloat ever since because of that basic incorrect choice. I point this out because it was the most basic of all problems. The other classic surely must be the bus. IBM chose to make the successor to the ISA a closed bus (can't even remember its name). Fortunately the like of Compaq etc realised this and made their own open bus and that took off. I do realise here we are talking about software. We will see different methods in the Prop II.
I do find it a shame that Catalina and bst were not welcomed, for whatever reason, into the frey of the new push by Parallax.
We are however, on the cusp of real progress in the software evolution of the Prop 1. Much progress has been made mainly by a few really dedicated fans off the prop. It is the tying together of these pieces that seem to me to be the most benefit, instead of racing off towards another parallel development of openness. Just IMHO.
Parallax want's a GCC compiler tool chain for Propeller. Catalina has a different role. Ross' contribution to stressing the importance of C for Propeller MCUs will be celebrated. Catalina will still be relevant for customers that don't care for Eclipse, etc... and Makefiles.
Parallax want's a GCC compiler tool chain for Propeller. Catalina has a different role. Ross' contribution to stressing the importance of C for Propeller MCUs will be celebrated. Catalina will still be relevant for customers that don't care for Eclipse, etc... and Makefiles.
I can agree with this - Catalina will be used by C programmers who want to write embedded software for the Propeller. GCC will be used by everybody else.
Catalina will still be relevant for customers that don't care for Eclipse, etc... and Makefiles.
Hmmm. I just noticed this bit. Seems to be some serious confusion about Catalina here. Catalina can be used with Eclipse, or with any other configurable IDE - all that is needed is a suitable plugin file. I do not provide an Eclipse plugin since I do not use Eclipse - but I do provide one for Code::Blocks, which is an IDE preferred by many C/C++ programmers.
As for using Makefiles, I can't understand this comment at all. Catalina uses makefiles to build many of the catalyst demo programs. For example, the Lua scripting language, the vi editor and the Infocom game interpeter are all built using makefiles. Typically, you simply need to modify a couple of lines in the makefile - exactly as you would have to do for any new platform or compiler.
Comments
But that's fine - my circumstances have now changed, and in any case I think I can now contribute best just by making Catalina the compiler that others will have to beat!
Ross.
Oh boy: where to begin -- and I'm not even a C programmer!
Ross, with all due respect, without your active participation, the resulting C compiler probably won't beat Catalina. And the sad fact of the matter is: It. Won't. Matter. Whichever compiler receives Parallax's blessing will become the standard, and new users will have no clue that something better once shone in the limelight for its brief flicker of fame. So I would urge you to put aside any initially-dashed expectations of an invitation to participate, and to secure a well-deserved place at the table in the GCC development.
Thanks,
-Phil
By the time we were ready to recruit you (3 days after the GCC announcement), you had already publicly announced your intention to not be involved. How am I supposed to ask you to participate in a development role knowing that ???
Seems to me you were maybe disturbed by something other than your lack of time.
Whatever blows your dress up.
============================================================
Hi Steve,
Usual story - when I had loads of time and also the inclination,
Parallax was completely uninterested - and now that they're interested,
I no longer have the time.
I'll be happy to help out wherever I can, except that for the next few
weeks I'll be a bit busy settling into my new job. But I'm happy to
offer advice if you want it - as you know, I'm not short on opinions
Ross.
On 16/06/2011 2:28 PM, Steve Denson wrote:
> Hi Ross,
>
> You probably noticed Ken Gracey's post in the ParallaxSemiconductor forum announcing specific details of proceeding with the GCC project.
> http://forums.parallax.com/showthread.php?131477-GCC-Eclipse-and-Propeller-2-seeking-developers&p=1009317&viewfull=1#post1009317
>
> This is an official invitation for you to participate in the project. At this point we are looking for demo coders and testers.
>
> Please respond with a brief email outlining the contributions you might make to the GCC project.
>
> -- end form letter --
>
> Since you have already announced some intention to not participate, I would understand if you are not interested. Still, I think you can add value, so I would appreciate it if you give it some thought.
>
> Thank you for your support.
> --Steve
>
============================================================
The external memory driver that the dracblade uses runs with 12 pins. Moving to TV from VGA saves 5 pins. And Ross says that the SD card is independent of external memory, saving another 4 pins. And I think that once the eeprom has finished loading, one of those pins could be H = external memory select, L = SD card select plus a bunch of uncommitted pins. The number of pins I think goes from 12 to 21.
Now with 21 pins, programs running in external ram can be a lot faster. Take 8 for data and 11 for address and one for /Rd and one for /Wr. Data is in blocks of 2k. Change blocks by changing the status of the eeprom pin, then latch out a high 8 bytes. I think this can be reduced to one latch for external ram.
In terms of code speed, maybe reduce from 20 pasm instructions to 3 or 4 per compiled instruction?
I've been using Ross' plugins for a while, as well as 'cogjects' which are pure pasm code separated out from their associated spin code. Cogjects end up being arrays in C which you store in external ram.
And now, with integrated Spin programs, these can be arrays as well. Pull them into a cog, run them, throw them away.
Free up virtually all hub ram for anything you want (for me, I'd like to use hub ram for a screen buffer).
One small snag I've run up against is that for really big C programs (200k) they do take a while to download. But with a nifty board that has just arrived, I think I can flip the SD between the propeller and being a disk drive on the PC. So downloads can be fast too.
And that means that you can start to add large libraries of spin code into a C program. Even obex code that you might only need infrequently.
All sorts of exciting possibilities.
One question I thought of reading the last few posts - Ross said something about adding your own spin interpreter. You could have many of these (they are just C arrays), but how would you go about making one? (I am still dreaming of a Big Spin interpreter running in a flat memory space of many hundreds of k, but this idea is becoming less and less relevant as Catalina morphs into a better and better software tool).
This is why I like the 10 pin 5MB/s read 4MB Flash solution - it comes on "instantly" after booting from the EEPROM. It's one of my Catalina target hardware devices to finish by end of summer ... assuming i don't have to screw with memory modes again to make something work ....
HI jazzed,
Your timeline is only out by about a month and a half, but that's ok - you weren't to know. As I said before, I offered my services to Parallax and they chose not to respond at the time. After that (more than a month after) my circumstances changed - so that when you wrote your email (offering, as I said, the opportunity to be a tester only) I truly didn't have the time available (exactly as I said at the time). These things happen - don't feel offended.
I'm still happy to offer advice if you want it.
Ross.
I know this is a "Spin running from C" thread but this still could be a relevant question, as it is likely that when you are running lots of spin programs you would be running from XMM mode. So the question becomes one of optimising speed. The 512k memory chip is great but it does need one NOP as pasm is just a bit too fast. Would your 32mb memory chip solution run faster with more pins available? (how many pins is it using now?)
Jazzed has done it for ICC.
Ross has done it for his Catalina plugins
Dr_A has done it with his "cogjects" as C array declarations.
I implemented some such objects for Zog when I discovered BST could do the PASM assembling and extracting. I use the raw binary blob and link it with the C object files but it could as well load the binaries form files or elsewhere at run time.
Bill Henning has also discussed this idea with respect to an operating system of his.
Seems a sure bet that the Prop II GCC compiler will be using this technique as well.
Which reinforces my point that all objects being given the "Gold Standard" now should be checked that they can be used in that manner. For example the Spin part does not POKE into the PASM DAT section prior to launching as this is rather hard to link with C or other language code later.
I would suggest that such binary PASM blobs be referred to as "firmware" as that is in line with terminology in the industry. I.e an OS loads "firmware" into you WIFI chipset on your computer. We are doing exactly that here.
I disagree. You forget that there is already a C compiler that has Parallax's blessing - but you don't hear too much about it anymore. The company no longer even posts in these forums (as far as I am aware). The point is that if you stick to the ANSI standards, C is a commodity language - the actual C compiler is unimportant. A poor compiler will sink without trace - and a good one will succeed - whether or not Parallax supports it.
In any case, I developed Catalina primarily for my own purposes. I'm pleased (and flattered) if others find it useful, but if they don't then I don't take it as a personal affront.
Ross.
Yes, of course. But credit where credit is due - jazzed did develop the spinc utility, which simplified what we were all doing anyway (and he gets due credit on page 82 of the Catalina Reference Manual).
Ross.
Wait for Catalina 3.1 - it now does a lot more than just extract the first DAT segment as an array - and it is not specific to Catalina. It should work for any C compiler.
Ross.
Support code, or library code, is optional, and should also be differentiated from "the driver", giving us, "the driver", which can simply be .cog file, or array to be fetched, used, stopped, removed, and "the library" which presents a interface to "the driver", where said library is SPIN, C, whatever, with higher level functions typically associated with use of "the driver".
@Phil, with SPIN + PASM, it's fairly easy to have "the standard" be a Parallax tool, as the ecosystem surrounding it is sourced by Parallax. We have Prop Tool and BST, for example, where people use both, but Prop tool is considered the reference platform.
Where the language exists outside of or is not sourced by Parallax the dynamics are different. There will be various environments, each with trade-offs. IMHO, this is a very good thing for Propeller users, as competing tool chains will shake out the better means and methods for doing things. Propeller chips present unique challenges! I've followed the development of Catalina, seeing those things worked through to good result. IMHO, we will find some of those things to be "the best" and others to be "a option", IF there is some competition in play.
Without that, then we simply have "the tools", which may or may not actually bring us the best means and methods. I submit that we don't realize all of "the best" ways to employ the chip, though we have now come very far, compared to the early, "hey! We need C" discussions. That Dr_A is employing a C environment in the fashion he is regularly, with performance even, is brilliant, and necessary.
Some of what has been done was due to lack of building blocks. A lot of what has been done to date is simply a artifact of how Props work, their memory model, COGS, etc... and that has to be boot-strapped, because it is new, and with the future chips, will be NEW AGAIN, in many ways. Having more than one effort is actually vital to seeing great tools for people to use.
Frankly, I'm eager to see what can be done differently, what should be done differently, and what that means for Propeller users, more than I am eager to see "the standard", largely because I do not see standards as productive, when the implications of the technology to be employed are not yet fully realized. IMHO, we are a whole lot closer to that on P1 today than we were when the C journey began. My point here is not to say we still don't understand P1. I think we mostly do, but that some competition was important. Imagecraft took one approach, Ross another, and over time, we saw where that all played out.
On P2, it's gonna have to happen again, because that chip is going to be "new" again, and we will all benefit AGAIN.
The existing efforts were hobbled somewhat. I'm sure others can comment more specifically, but I clearly saw the lack of a open SPIN compiler, and macro-assembler as barriers to this kind of development. Frankly, I'm most excited about seeing a full assembler that operates stand alone, and that is memory model aware as "the tool" needed, more than I am C, but that's just me, and my preference for SPIN + PASM, and no need to do C, though I do have interest.
Finally, there is the very real unresolvable conflict in play here between things being open and flexible enough to allow software people to "just do it", if they need to, and standard tools that constrain things, simplify and streamline. These goals are mutually exclusive, though it is very clearly possible to split the middle and give people some of both worlds, should they need it. IMHO, that is as good as it ever gets, if the technology is to see broad acceptance, outside the community of people who are alpha, early adopter types, who will invest far more than the average user would.
So let the games begin! It is just not a bad thing. In the end, as Ross points out, the community of Propeller users only stand to benefit longer term. There is very little loss, other than some unavoidable duplication of effort in the shorter term.
The real lesson here is open vs closed development. Imagecraft was closed, and really couldn't contribute to the ecosystem needed to build the better tools. As we got basic blocks out in the open, things took off. Remember the SPIN discussion way back when? Closed was good, but... when Hippy started to crack the SPIN nut, with Chip seeing what was going to happen, showing us Pnut, that kicked off a ton of things.
Finally, IMHO, the only real potential tragedy would be either, some closed development endorsed as standard, or a turf war, which ends up being the same constraint. If that is avoided, the product of the work to come will benefit everybody in the end.
Er.. not really. When we talk about "cogjects" or "firmware" we are talking about the binary code that gets loaded into a COG when the COG is started. As it stands now most of those COG binaries are written in PASM but potentially they could be written in any language. I believe we already have a version of BASIC that generates COG code.
The "cogject" or "firmware" idea has a number of facets:
1) That those COG binaries can be fetched from anywhere. Maybe built into your program as Spin does it now. Maybe read from EEPROM, or FLASH or SD card etc. Where ever it comes from it is used to start a COG. Hopefully the buffer space used to do this can be reused later, saving precious HUB memory.
2) Those COG binaries can be used from any language, Spin, C, Forth etc etc without having to make special versions for each language.
Now 2) imposes some requirements on the COG code:
3) There should be a clearly defined and well documented interface for the COG code. This at least includes a) What parameters it expects to get via PAR on start up. b) What the interface between it and the user program is through HUB memory. Typically there are commands, status and data to be exchanged when running. So a "mailbox" or some such must be clearly spelled out for those who want to drive the thing from different languages.
4) There should be no tweaking of values within the DAT section prior to using it to start a COG. Currently it is often the case that Spin code sets up some values into the DAT section that is loaded to COG by way of configuration prior to starting the COG. That's OK from Spin at the moment as Spin and PASM are "linked" at compile time in the prop Tool or BST or whatever. However when working from C, for example, there is no "linkage" between the code and vars in the COG binary blob and setting such configuration items is not possible. Well you can do it if you know the offsets into the binary but then if a new version comes that moves things around it breaks your code.
As it stands many objects fall down on requirements 2) 3) and 4). For example FullDuplexSerial has an interface through HUB memory between the public Spin methods and the running COG. That interface is not documented. In addition it has at least one DAT item that must be set prior to launching. Obviously my C code knows nothing about that items location.
Currently before you can use an exiting object you need to stdy it very carefully, figure out how params get into it via PAR, figure out how the Spin/PASM interface works when running, and look for any values POKED into it prior to launching. Often changes to the PASM have to be made.
So, here we have the criteria I am looking for in "Gold Standard" objects that can support arbitrary languages. Perhaps there are some others I have not thought of yet.
I over simplified, really focusing only on the fact that "the driver" needs to run without higher level language dependencies. That's primary in my mind.
getdat reads the PBASE and PCURR values from the 16-byte header to determine the starting address of the object and the first PUB. PBASE is always $10, but I allow for it to be something else. It then extracts the number of methods and referenced objects from the method table to determine the start of the DAT section. The source file is attached below.
Which means there is a rule five for language neutral COG firmware.
5) The entry point of the COG firmware must be at offset zero into the DAT section.
It's much easier to write with those rules in mind, knowing the PASM must run on it's own, than it is to parse through something, hoping to find and correct dependencies.
I'm kind of there on the use of "firmware" for such a construct. Interesting how "micro-code" makes great sense for LMM / XMM style work. "firmware" is a excellent parallel. This is such a interesting chip!
I find, limiting "variables" in the DAT for COG code to either:
constants - where a value is needed for runtime
, or
reserved working or uninitalized longs, where space is needed at run-time helps to make the firmware stand alone. I now try to use res as much as possible, thinking hard about whether or not anything else is really just a constant, or a potential dependency.
On that note, I still struggle with the lexicon. At times, I'll refer to a working long as a "register", because it's easy to think of it as such. Other times, like for a constant, I will say "constant", or more simply "long", or "cog-long".
With a instruction, I most often say "address" too. Would be nice to have one word that works in more contexts, simply because then new users could simply adopt one definition, and be understanding documentation better. Maybe there is one, and I've just not grokked it yet.
I was able to find an old copy of spinc.cpp using google "site:forums.parallax.com spinc"
BSTC -c is a nice tool for extracting PASM also.
BTW, this idea of PASM blob loading is as old as the hills ... kind of like overlays
In any event, having a header file that describes the SPIN Binary structure has value and I've used spinc.h several times for that. Maybe a more formal header with data structures should be made.
A PASM driver mailbox needs a lock pointer parameter. Some drivers may want to share pins with hardware. I have run into this by trying to squeeze every ounce out of a Propeller's hardware. Most of the time like in the case of I2C all drivers can be put into the cog (EEPROM, RTC, Accelerometer, others where SCL is clock), but there are other times when devices may all want to use P0..7 as data for example and COG will not have enough memory.
Posting private email is seriously not cool. I think you owe Ross an apology for this.
Sorry about that.
Most of the ideas of loading PASM blobs and starting up Spin cogs from a DAT area or from an SD file seem to have been developed during the first couple of years of the Prop. However, it's nice to see new applications of these ideas such as cogjects and starting up Spin cogs from Catalina.
Nasty habit i picked up from linux device drivers that forces one exit point so i didn't have to add multiple fclose calls. There are nicer C-ish ways to do it, and reviewers don't twitch.
When I get home tonight I'll post the updated source for spinc, and also the spin_utlities (which is really just a wrapper around a simple call to _coginit(). Given that every C compiler on the Prop must have an equivalent to _coginit() (which is itself just a simple wrapper function around a COGINIT instruction) the code generated by spinc will be portable to all C compilers.
Ross.
No worries.
Potatohead is right. It is a shame we didn't have an open sourced compiler. Rather than Michael and Brad wasting their time redeveloping the compiler, their efforts (and others help) could have been put to much better use in adding conditional compliation (which both their versions now have) and macros (which we still don't have). Parallax is very open with many things, but this was/is a huge mistake, no matter how bad the code was. But, that is past history, although we still do not have an open compiler yet.
Parallax, why not release the code to Propellant (now) ??? It would still be of benefit now, even with the new compiler going to be available soon.
As for standards, there are some advantages and some disadvantages. IBM's PC standard was a disadvantage because they chose the 8088/8086 platform causing all sorts of problems in address space. The 68000 was a much better solution. We have suffered from processor bloat and software bloat ever since because of that basic incorrect choice. I point this out because it was the most basic of all problems. The other classic surely must be the bus. IBM chose to make the successor to the ISA a closed bus (can't even remember its name). Fortunately the like of Compaq etc realised this and made their own open bus and that took off. I do realise here we are talking about software. We will see different methods in the Prop II.
I do find it a shame that Catalina and bst were not welcomed, for whatever reason, into the frey of the new push by Parallax.
We are however, on the cusp of real progress in the software evolution of the Prop 1. Much progress has been made mainly by a few really dedicated fans off the prop. It is the tying together of these pieces that seem to me to be the most benefit, instead of racing off towards another parallel development of openness. Just IMHO.
Please read.
Parallax want's a GCC compiler tool chain for Propeller. Catalina has a different role. Ross' contribution to stressing the importance of C for Propeller MCUs will be celebrated. Catalina will still be relevant for customers that don't care for Eclipse, etc... and Makefiles.
I can agree with this - Catalina will be used by C programmers who want to write embedded software for the Propeller. GCC will be used by everybody else.
Ross.
Hmmm. I just noticed this bit. Seems to be some serious confusion about Catalina here. Catalina can be used with Eclipse, or with any other configurable IDE - all that is needed is a suitable plugin file. I do not provide an Eclipse plugin since I do not use Eclipse - but I do provide one for Code::Blocks, which is an IDE preferred by many C/C++ programmers.
As for using Makefiles, I can't understand this comment at all. Catalina uses makefiles to build many of the catalyst demo programs. For example, the Lua scripting language, the vi editor and the Infocom game interpeter are all built using makefiles. Typically, you simply need to modify a couple of lines in the makefile - exactly as you would have to do for any new platform or compiler.
Ross.