Continuing the effort to replicate Spin objects in C++ attached is an experimental Zog V 0.21
that include C++ versions of FullDuplexSerial and VMCog.
When run on TriBlade it runs a simple test that gets chars from the terminal with the C++ FDS, writes them out to external memory and reads them back via the C++ VMCog and displays the result. Like so:
ZOG v0.21 (HUB)
zpu memory at 00000748
PASM Firmware in C++ test.
Starting VMCog...
OK
Press any key to continue
k
Writing to VMCog...
OK
Reading from VMCog...
Got k
OK
Press any key to continue
z
Writing to VMCog...
OK
Reading from VMCog...
Got z
OK
For other external memory boards supported by VMCog just edit the #defines in test/vmcog.spin and rebuild with "make". The Makefile will recompile that VMCog.spin with bstc and suck the PASM binary blob for the COG out of it.
That's assuming you have a ZPU GCC tool chain set up, don't forget to edit the paths in the Makefile.
Just for Jazzed this has the FullDuplexSerial object instantiated on the heap. For the record this makes the binary about 3K bigger than having it statically declared. Probably because it links in malloc.
I also tried to make a plain C version of VMCog. Even with out any object oriented techniques in C, i.e. only possible to have one VMCog "object", it came out slightly bigger than the C++ class !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
3K is a pretty small price to pay for GNU's industrial strength and optimized malloc [noparse]:)[/noparse]
Do you suppose you would ever make new/delete work with malloc transparently?
BTW: I'm happy to notice that my C FullDuplexSerial code for ICC made object of the week and thank Parallax for that. While it's useful for ICC and is an early demonstration of the "run a blob of PASM" ability, it seems less important with recent ZOG and Catalina progress [noparse]:)[/noparse] Definitely a good thing for the community.
heater said...
Just for Jazzed this has the FullDuplexSerial object instantiated on the heap. For the record this makes the binary about 3K bigger than having it statically declared. Probably because it links in malloc.
I also tried to make a plain C version of VMCog. Even with out any object oriented techniques in C, i.e. only possible to have one VMCog "object", it came out slightly bigger than the C++ class !!!
There was a time in the dim and distant past when I found out how to replace the implementation of new and delete for an entire C++ program. Even used it to catch memory leaks in one embedded project. Can't for the life of me remember how now and a quick google around is not helping. I'm sure it can be done but is low on my TODO list just now. Unless someone comes up with some good pointers that is.
Well done on the object of the week. I'm surprised though that ICC did not have this a long time ago.
I don't think Zog lessens the importance of your FDS object. Zog will never have the speed of ICC or Catalina. Not sure he even has a space saving advantage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A native LMM PASM GCC target would be amazing. Fore sure it's beyond my ken.
Anyway with Catalina and ICC is there any need for anyone to take on such a mammoth task?
Actually it did occur to me when Parallax announced their "not C" C like language for the Prop that perhaps it would be resources better used to get some consultants, ZyLin for example, to create a Propeller GCC target and matching LMM kernel. Not for Prop I but to put in ROM for Prop II.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Family has been keeping me busy for a few days, so I've not posted much... I'll be back starting on Monday [noparse]:)[/noparse] ... seems family missed me!
Re/ GCC target - it will be *MUCH* easier on P2, due to new indexed/autoincrement hub addressing modes, and doing a stack (and associated stack frame) will be a piece of cake compared to p1.
It could be done for P1, but it would run slowly - LMM ops for stack, stack frame, and indexed instructions. It would NOT be fast.
I have no problem with GCC - I use it all the time. Catalina is compiled with it. These days, its my second favorite compiler
Even though I'm not as fanatical about GCC as you are, I have to acknowledge that it would be very useful in a marketing sense for Parallax to be able to claim that it supports the Propeller - it would be another a small step along the path to mainstream acceptance of this quirky little microcontroller we all love so much.
I've said before - and I continue to believe - that someone, somewhere is working in a port of GCC for the Propeller. No doubt it will emerge in due course. Fortunately, in the meantime there is Catalina
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1) What's the smallest neatest low level SD card driver for the Prop?
2) Does anyone have recommendations for a small FAT file system code in C.
Q1 arises because, having never really looked at it before, I find that the spiFemto.spin driver that I am using with fsrwFemto_rr001 for Zog has a huge PASM section of almost 2K bytes. It includes a lot of code for I2C as well as SPI. Actually its very confusing as it has a bucket load of I2C PASM code to handle read/write commands etc but no Spin interface functions to do so. All the header text talks about I2C. What that about?
Anyway I'm looking for a SD driver I can convert to C for Zog that has a small PASM "firmware" blob that can be used. One difficulty is that I use this spiFemto because Cluso has modified it for use with shared pins on the TriBlade.
P.S. RossH: "...someone, somewhere is working in a port of GCC for the Propeller. No doubt it will emerge in due course. Fortunately, in the meantime there is Catalina"
For once Catalina cannot compete here, this is a C++ thread [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) What's the smallest neatest low level SD card driver for the Prop?
2) Does anyone have recommendations for a small FAT file system code in C.
There is a C version of FSRW that I was able to compile with ICC long ago [noparse]:)[/noparse]
If I could only find that .... grumble. I put it in the obex but removed it for some reason.
The original FSRW has a small PASM driver and an even smaller SPIN only driver.
I recently uploaded a sdcard config/boot loader to Bill's VMCOG thread ... it has FSRW stuff.
Look here: http://forums.parallax.com/attachment.php?attachmentid=71105
Yes, Catalina uses DOSFS - it seems to work very well. But you may want to use the version included with Catalina, as I have incorporated several fixes found in the newsgroups that never seem to have made it back into the "official" release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
heater said...
P.S. RossH: "...someone, somewhere is working in a port of GCC for the Propeller. No doubt it will emerge in due course. Fortunately, in the meantime there is Catalina"
For once Catalina cannot compete here, this is a C++ thread [noparse]:)[/noparse]
Very much not so! All the original C++ compilers were written in plain old C. There are several still available, and I looked at porting one to the Propeller, but I didn't want to encourage the use of such a demented language
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ross : I was just on a fishing expedition in the Catalina package [noparse]:)[/noparse]
I found the DOSFS and noticed you have Version 1.02 the one I downloaded yesterday from www.larwe.comis V 1.03 from 2006. What do you think?
I also found your catalina_sdspiqasm.spin modified to work with TriBlade.
What I don't see is any mention of getting the SD card to tristate it's D0 pin so that it does not fight with the shared bus pins on TriBlade. The sdspiFemto.spin that is used by Zog and ZiCog on TriBlade has a modification by Cluso to do that.
So how does catalina_sdspiqasm.spin manage to work on TriBlade and use external RAM without that?
I must say, looking around there I see that Catalina is a tremendous piece of work, what with all the infrastructure and target support never mind the compiler itself. Brilliant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's been a while, but I believe the version of DOSFS I have in Catalina has all the latest patches I could find - there are some discrepencies in the labelling of various versions of DOSFS available on the net. There is supposed to be a version 1.04 available, but I could never find a copy and I never got a response from the author to any of my queries. But it's easy enough to do a file comparison and check - I put #defines around all the changes I made in case I wanted to back them out later.
The file "catalina_sdspiqasm.spin" is only used in FSRW - but there is equivalent special code to manage the TriBladeProp in "Catalina_SD_Plugin.spin" which is the SD card manager used by DOSFS.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Oops, I think I added that one! There may be a few other odds and sods I added as well.
I appreciate the kind words about Catalina. Most people don't realize that the porting of LCC itself to a new platform is almost completely trivial, and takes only a matter of weeks even for a rank beginner like me. And most of this time is spent just climbing the necessarily steep learning curve. After that I thought I was nearly done - then I spent the next year on the various libraries, targets, drivers and support tools.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've had a chance to look at the XMOS extensions to C that you recommended (at least those which deal with concurrency). They are a good attempt at bolting CSP semantics onto C - but as well as making the resulting combined language non-standard, the result is not particularly elegant (at least not in my view!). This is not the fault of XMOS - I've never found CSP to be particularly elegant in any form. CSP is quite a low level approach to concurrency, and CSP programs tend to get very complex once you get beyond textbook examples.
Ada is based on some of the same ideas as CSP, but Ada rejected the concept of requiring a separately defined communication channel as being both complex and unnecessary. Instead, Ada only has the rendezvous - but it has more complex rendezvous semantics than CSP. The rationale for the Ada design is given in archive.adaic.com/standards/83rat/html/ratl-13-03.html - it's quite interesting reading.
Ada is more "powerful" than CSP, in that it is easy to emulate CSP semantics in Ada, but impossible to emulate Ada semantics in CSP (at least using Hoare's original CSP - but I believe there are extensions to CSP in which it is possible). The result is that Ada programs tend to be simpler and easier to understand than the equivalent CSP programs.
But in the end, what I really like about Ada is that a rendezvous is no more difficult to either write or understand than a procedure call is in most other languages - and this is the feature I'd like to have in Catalina. Also, I'd like to do it without changing any C syntax - I'm not sure this is possible, but it would be great if a concurrent program could be run on the Propeller and use true concurrency (by being executed in multiple cogs) while exactly the same program could be executed on another platform and use simulated concurrency (e.g. by using a thread library).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
We should be careful of mentioning XMOS too much. There is a lynching going on over on another thread of a poor chap who did that[noparse]:)[/noparse]
Still this is about languages for parallel programming.
That's an interesting take on XC vs ADA.
Here is my take on XC:
The C language is about the lowest level "high level" portable language you can have. It abstracts all the common and most basic features of computers as they have been know for many decades and gets you away from assembly language. Those features are basically:
a) A processor, of course, running the code.
b) Memory, of course, where your code and data live.
c) The basic sizes of data the machines can handle usually 8 bit char, 16 bit short int, 32 bit int etc both signed and unsigned.
d) Basic control flow if/while/for reflecting what you can do in assembler.
e) Functions, abstracting the call stacks available in nearly all machines.
f) Pointers abstracting indirect addressing.
Then there are a few high level features usually not actually existing in the hardware like struct, typedef etc. But basically it's down to the metal.
Now we come to the situation of having many processors (Not just 2 or 4 or 8 sharing memory like an Intel or even a Prop. Let's think in terms of 100s, or millions of CPUs. With NO shared memory. The new hardware feature here is :
a) Generally it is not possible to share memory among all these processors.
b) The will necessarily be some means of communication between them.
So enter XC as the minimal extension to C to support this new "metal".
1) It introduces the fact of multiple processors with PAR. Parallel threads of code on different cores or different chips.
2) It introduces the fact of interprocessor communication with channels.
3) By virtue of the fact that different threads in PAR may well be on different chips and cannot share memory it deems all threads to be equal, different chip or not, and will not let data be shared through memory.
So we see that XC is again about the minimal "high level" language you can have to work on such multi-processor architectures, as C was for mono-processors. How well it works at this task I have yet to see.
Now David May of XMOS did all this decades ago with the OCCAM language on the Inmos Transputer chip which was similar in its multi-cpu/channel hardware. Occam was not a big hit for the usual reason, it's not C [noparse]:)[/noparse] So when David started XMOS he had learned that lesson and made a new "minimal parallel" language that is very much like C and will easily link and interoperate with C and C++.
All in all I think it's quite brilliant.
As for handling this kind of parallelism in ADA I have limited experience. ADA lives in a much higher plane of abstraction than C. If the independent CPUs linked with channels architecture can be worked with easily using rendezvous as you say then all is well and good.
Whatever you may come up with for handling concurrency among Cogs in a Prop chip should also work for distributing the threads of that same program among multiple Props with some communication media. That is what XC and Occam are all about.
I'll have to take time out to read the paper you linked to.
Mean while, on the topic of this thread, I just managed to rewrite the "syscall" ZPU instruction that Zog uses to start PASM blobs in other Cogs in PASM, i.e. it happens directly in the emulator rather than farming it out to the Spin support code. (Zog goes parallel[noparse]:)[/noparse]) This means I can now get rid of all Spin code in a Zog system [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I saw the boys with their hoods and ropes heading over to that other thread - I'm staying well away from it! From now on I will refer to the offending company/chip only as XXXX!
I knew that the XXXX came from the same roots as Occam, so I wasn't surprised to see CSP feature prominently in XC. Unfortunately, in my view CSP falls into the same category as Lisp - a good idea that is mostly unusable by mere mortals. These things lives on in some places (notably academia) because they are so clever that people assume they must also be useful.
XC (like Occam) is probably a good choice for environments where you may indeed have 100's of interconnected parallel processors available - but if you have a hardware budget that size then you probably don't mind also having to program in a non-standard language. But back in the real world this is not generally the case, and XC doesn't seem to me to be a good choice where you have a fixed (and typically very small) number of processors (like we have in the Prop).
A much more minimalist extensions to C to add concurrency is described here - supertech.csail.mit.edu/cilk/. The addition of a couple of simple #defines makes every cilk program a valid ANSI C program guaranteed to produce the same result when executed in a non-parallel environment. It's very clever! Unfortunately, I don't like this one either - it's based on the old fork/join concurrency model.
Good work on Parallel Zog, by the way. In hindsight, I think it was a mistake leaving this out of Catalina until the last release. It's really what the Prop is all about, after all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH : "...CSP....good idea that is mostly unusable by mere mortals. These things lives on in some places .... because they are so clever that people assume they must also be useful."
I have the opposite take on that. CSP is a damn good idea that is ignored as people think it's too theoretical and academic. Then they go ahead and use it anyway, without knowing it, to solve their problems. Of course looking at Tony Hoare's book "Communicating Sequential Processes" I can see why people run away. Life is too short for that.
Concrete examples:
1) My first ever professional work was on a process control system that was built out of 8085's. Yes that long ago. There was a whole rack of CPU cards, one for the user interface, one for data logging/fault monitoring, one for the actual process control. That last one had to be split into two when it was discovered there was not enough performance in one CPU. A couple more for other odd tasks.
These all communicated. The process control CPU's shared some RAM so they could work fast together. Others talked over a parallel communication bus. Still others were hanging off of serial lines.
2) Next up I worked on a Radar system. Again a rack full of processors, this time much faster in house design 16 bit beats. But the pattern is the same: one drives the display, one or more do the signal processing, another manages the whole show etc. This time all sharing an address space and communicating over a nice back plane.
3) I could go on but the world is full of such examples. They use VME buses or whatever it takes to get CSP.
So when the Transputer and Occam arrived my first reaction was, "Bloody hell why have I been struggling with all this multi-processor Smile for so long. This simple, fast, tightly coupled to the CPU coms channel idea is all we ever needed. And Occam as a way to write the whole application across many processors, brilliant.
P.S. The Propeller chip architecture looks very much like the block diagram of that radar processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I remember the Transputer. It was big news when I was at Uni. I even considered buying one - but I gave up on the idea when I discovered they wanted some ridiculous (at the time) amount of money for a development board with ONE transputer chip on it. I never could figure out what they expected anyone to be able to do with a single transputer chip. Of course the University itself ended up with a couple - but I suspect they got them as freebies. This also encouraged a brief flurry of interest in Occam - but building a system with more than a few transputer chips was never really cost effective outside supercomputer applications (with supercomputer budgets!). Of course Occam survived because it was also applicable to much cheaper chips.
Time will tell whether XXXX and XC suffer the same fate - i.e. being fondly remembered as technologically innovative but with a price/performance ratio that limited their general applicability.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
It was sad, eventually there were full pages adds in the EE Times for $20 or so Transputer chips after SGS-Thomson bought INMOS. But it was too late. The T9000 successor with 100Mbiit/sec links never made it out of the gate. I tried to get the T800 into one project where multiple processors were an ideal solution to the requirements but the power consumption was to great.
Comments
that include C++ versions of FullDuplexSerial and VMCog.
When run on TriBlade it runs a simple test that gets chars from the terminal with the C++ FDS, writes them out to external memory and reads them back via the C++ VMCog and displays the result. Like so:
For other external memory boards supported by VMCog just edit the #defines in test/vmcog.spin and rebuild with "make". The Makefile will recompile that VMCog.spin with bstc and suck the PASM binary blob for the COG out of it.
That's assuming you have a ZPU GCC tool chain set up, don't forget to edit the paths in the Makefile.
Just for Jazzed this has the FullDuplexSerial object instantiated on the heap. For the record this makes the binary about 3K bigger than having it statically declared. Probably because it links in malloc.
I also tried to make a plain C version of VMCog. Even with out any object oriented techniques in C, i.e. only possible to have one VMCog "object", it came out slightly bigger than the C++ class !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
3K is a pretty small price to pay for GNU's industrial strength and optimized malloc [noparse]:)[/noparse]
Do you suppose you would ever make new/delete work with malloc transparently?
BTW: I'm happy to notice that my C FullDuplexSerial code for ICC made object of the week and thank Parallax for that. While it's useful for ICC and is an early demonstration of the "run a blob of PASM" ability, it seems less important with recent ZOG and Catalina progress [noparse]:)[/noparse] Definitely a good thing for the community.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Well done on the object of the week. I'm surprised though that ICC did not have this a long time ago.
I don't think Zog lessens the importance of your FDS object. Zog will never have the speed of ICC or Catalina. Not sure he even has a space saving advantage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, new and delete integration can wait. Excellent progress so far.
Now, if we could only get a native LMM PASM GNU working [noparse]:)[/noparse] But that's a real PITA.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
A native LMM PASM GCC target would be amazing. Fore sure it's beyond my ken.
Anyway with Catalina and ICC is there any need for anyone to take on such a mammoth task?
Actually it did occur to me when Parallax announced their "not C" C like language for the Prop that perhaps it would be resources better used to get some consultants, ZyLin for example, to create a Propeller GCC target and matching LMM kernel. Not for Prop I but to put in ROM for Prop II.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Family has been keeping me busy for a few days, so I've not posted much... I'll be back starting on Monday [noparse]:)[/noparse] ... seems family missed me!
Re/ GCC target - it will be *MUCH* easier on P2, due to new indexed/autoincrement hub addressing modes, and doing a stack (and associated stack frame) will be a piece of cake compared to p1.
It could be done for P1, but it would run slowly - LMM ops for stack, stack frame, and indexed instructions. It would NOT be fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I use GNU because it builds almost anything out there without massive rewrites.
@Bill, everything runs faster on PropII ... someday. Enjoy your family time.
Having/starting a native GNU port now would make a PropII port easier.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I have no problem with GCC - I use it all the time. Catalina is compiled with it. These days, its my second favorite compiler
Even though I'm not as fanatical about GCC as you are, I have to acknowledge that it would be very useful in a marketing sense for Parallax to be able to claim that it supports the Propeller - it would be another a small step along the path to mainstream acceptance of this quirky little microcontroller we all love so much.
I've said before - and I continue to believe - that someone, somewhere is working in a port of GCC for the Propeller. No doubt it will emerge in due course. Fortunately, in the meantime there is Catalina
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 7/4/2010 2:43:52 AM GMT
1) What's the smallest neatest low level SD card driver for the Prop?
2) Does anyone have recommendations for a small FAT file system code in C.
Q1 arises because, having never really looked at it before, I find that the spiFemto.spin driver that I am using with fsrwFemto_rr001 for Zog has a huge PASM section of almost 2K bytes. It includes a lot of code for I2C as well as SPI. Actually its very confusing as it has a bucket load of I2C PASM code to handle read/write commands etc but no Spin interface functions to do so. All the header text talks about I2C. What that about?
Anyway I'm looking for a SD driver I can convert to C for Zog that has a small PASM "firmware" blob that can be used. One difficulty is that I use this spiFemto because Cluso has modified it for use with shared pins on the TriBlade.
Q2 arises because Zog needs a FAT file system in C. So far I have discovered DOSFS here www.larwe.com/zws/products/dosfs/index.html and FatFs Generic File System Module here elm-chan.org/fsw/ff/00index_e.html A while back I spotted some others but don't seem to be able to find them again.
P.S. RossH: "...someone, somewhere is working in a port of GCC for the Propeller. No doubt it will emerge in due course. Fortunately, in the meantime there is Catalina"
For once Catalina cannot compete here, this is a C++ thread [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If I could only find that .... grumble. I put it in the obex but removed it for some reason.
The original FSRW has a small PASM driver and an even smaller SPIN only driver.
I recently uploaded a sdcard config/boot loader to Bill's VMCOG thread ... it has FSRW stuff.
Look here: http://forums.parallax.com/attachment.php?attachmentid=71105
Doesn't Catalina have a FAT C source?
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Problem then is to figure out how to get it to play nicely with the shared pins on a TriBlade.
Never thought to poach code from Catalina. Now that I look at it Ross is using the same DOSFS from Lewin A.R.W. Edwards that I have just discovered.
So, cheers, looks like Zog is in business on the FAT front.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, Catalina uses DOSFS - it seems to work very well. But you may want to use the version included with Catalina, as I have incorporated several fixes found in the newsgroups that never seem to have made it back into the "official" release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Very much not so! All the original C++ compilers were written in plain old C. There are several still available, and I looked at porting one to the Propeller, but I didn't want to encourage the use of such a demented language
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I found the DOSFS and noticed you have Version 1.02 the one I downloaded yesterday from www.larwe.comis V 1.03 from 2006. What do you think?
I also found your catalina_sdspiqasm.spin modified to work with TriBlade.
What I don't see is any mention of getting the SD card to tristate it's D0 pin so that it does not fight with the shared bus pins on TriBlade. The sdspiFemto.spin that is used by Zog and ZiCog on TriBlade has a modification by Cluso to do that.
So how does catalina_sdspiqasm.spin manage to work on TriBlade and use external RAM without that?
I must say, looking around there I see that Catalina is a tremendous piece of work, what with all the infrastructure and target support never mind the compiler itself. Brilliant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/4/2010 6:32:52 AM GMT
It's been a while, but I believe the version of DOSFS I have in Catalina has all the latest patches I could find - there are some discrepencies in the labelling of various versions of DOSFS available on the net. There is supposed to be a version 1.04 available, but I could never find a copy and I never got a response from the author to any of my queries. But it's easy enough to do a file comparison and check - I put #defines around all the changes I made in case I wanted to back them out later.
The file "catalina_sdspiqasm.spin" is only used in FSRW - but there is equivalent special code to manage the TriBladeProp in "Catalina_SD_Plugin.spin" which is the SD card manager used by DOSFS.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
OK I found Catalina_SD_Plugin_Input. You really have thought of everything.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oops, I think I added that one! There may be a few other odds and sods I added as well.
I appreciate the kind words about Catalina. Most people don't realize that the porting of LCC itself to a new platform is almost completely trivial, and takes only a matter of weeks even for a rank beginner like me. And most of this time is spent just climbing the necessarily steep learning curve. After that I thought I was nearly done - then I spent the next year on the various libraries, targets, drivers and support tools.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've had a chance to look at the XMOS extensions to C that you recommended (at least those which deal with concurrency). They are a good attempt at bolting CSP semantics onto C - but as well as making the resulting combined language non-standard, the result is not particularly elegant (at least not in my view!). This is not the fault of XMOS - I've never found CSP to be particularly elegant in any form. CSP is quite a low level approach to concurrency, and CSP programs tend to get very complex once you get beyond textbook examples.
Ada is based on some of the same ideas as CSP, but Ada rejected the concept of requiring a separately defined communication channel as being both complex and unnecessary. Instead, Ada only has the rendezvous - but it has more complex rendezvous semantics than CSP. The rationale for the Ada design is given in archive.adaic.com/standards/83rat/html/ratl-13-03.html - it's quite interesting reading.
Ada is more "powerful" than CSP, in that it is easy to emulate CSP semantics in Ada, but impossible to emulate Ada semantics in CSP (at least using Hoare's original CSP - but I believe there are extensions to CSP in which it is possible). The result is that Ada programs tend to be simpler and easier to understand than the equivalent CSP programs.
But in the end, what I really like about Ada is that a rendezvous is no more difficult to either write or understand than a procedure call is in most other languages - and this is the feature I'd like to have in Catalina. Also, I'd like to do it without changing any C syntax - I'm not sure this is possible, but it would be great if a concurrent program could be run on the Propeller and use true concurrency (by being executed in multiple cogs) while exactly the same program could be executed on another platform and use simulated concurrency (e.g. by using a thread library).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
We should be careful of mentioning XMOS too much. There is a lynching going on over on another thread of a poor chap who did that[noparse]:)[/noparse]
Still this is about languages for parallel programming.
That's an interesting take on XC vs ADA.
Here is my take on XC:
The C language is about the lowest level "high level" portable language you can have. It abstracts all the common and most basic features of computers as they have been know for many decades and gets you away from assembly language. Those features are basically:
a) A processor, of course, running the code.
b) Memory, of course, where your code and data live.
c) The basic sizes of data the machines can handle usually 8 bit char, 16 bit short int, 32 bit int etc both signed and unsigned.
d) Basic control flow if/while/for reflecting what you can do in assembler.
e) Functions, abstracting the call stacks available in nearly all machines.
f) Pointers abstracting indirect addressing.
Then there are a few high level features usually not actually existing in the hardware like struct, typedef etc. But basically it's down to the metal.
Now we come to the situation of having many processors (Not just 2 or 4 or 8 sharing memory like an Intel or even a Prop. Let's think in terms of 100s, or millions of CPUs. With NO shared memory. The new hardware feature here is :
a) Generally it is not possible to share memory among all these processors.
b) The will necessarily be some means of communication between them.
So enter XC as the minimal extension to C to support this new "metal".
1) It introduces the fact of multiple processors with PAR. Parallel threads of code on different cores or different chips.
2) It introduces the fact of interprocessor communication with channels.
3) By virtue of the fact that different threads in PAR may well be on different chips and cannot share memory it deems all threads to be equal, different chip or not, and will not let data be shared through memory.
So we see that XC is again about the minimal "high level" language you can have to work on such multi-processor architectures, as C was for mono-processors. How well it works at this task I have yet to see.
Now David May of XMOS did all this decades ago with the OCCAM language on the Inmos Transputer chip which was similar in its multi-cpu/channel hardware. Occam was not a big hit for the usual reason, it's not C [noparse]:)[/noparse] So when David started XMOS he had learned that lesson and made a new "minimal parallel" language that is very much like C and will easily link and interoperate with C and C++.
All in all I think it's quite brilliant.
As for handling this kind of parallelism in ADA I have limited experience. ADA lives in a much higher plane of abstraction than C. If the independent CPUs linked with channels architecture can be worked with easily using rendezvous as you say then all is well and good.
Whatever you may come up with for handling concurrency among Cogs in a Prop chip should also work for distributing the threads of that same program among multiple Props with some communication media. That is what XC and Occam are all about.
I'll have to take time out to read the paper you linked to.
Mean while, on the topic of this thread, I just managed to rewrite the "syscall" ZPU instruction that Zog uses to start PASM blobs in other Cogs in PASM, i.e. it happens directly in the emulator rather than farming it out to the Spin support code. (Zog goes parallel[noparse]:)[/noparse]) This means I can now get rid of all Spin code in a Zog system [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I saw the boys with their hoods and ropes heading over to that other thread - I'm staying well away from it! From now on I will refer to the offending company/chip only as XXXX!
I knew that the XXXX came from the same roots as Occam, so I wasn't surprised to see CSP feature prominently in XC. Unfortunately, in my view CSP falls into the same category as Lisp - a good idea that is mostly unusable by mere mortals. These things lives on in some places (notably academia) because they are so clever that people assume they must also be useful.
XC (like Occam) is probably a good choice for environments where you may indeed have 100's of interconnected parallel processors available - but if you have a hardware budget that size then you probably don't mind also having to program in a non-standard language. But back in the real world this is not generally the case, and XC doesn't seem to me to be a good choice where you have a fixed (and typically very small) number of processors (like we have in the Prop).
A much more minimalist extensions to C to add concurrency is described here - supertech.csail.mit.edu/cilk/. The addition of a couple of simple #defines makes every cilk program a valid ANSI C program guaranteed to produce the same result when executed in a non-parallel environment. It's very clever! Unfortunately, I don't like this one either - it's based on the old fork/join concurrency model.
Good work on Parallel Zog, by the way. In hindsight, I think it was a mistake leaving this out of Catalina until the last release. It's really what the Prop is all about, after all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have the opposite take on that. CSP is a damn good idea that is ignored as people think it's too theoretical and academic. Then they go ahead and use it anyway, without knowing it, to solve their problems. Of course looking at Tony Hoare's book "Communicating Sequential Processes" I can see why people run away. Life is too short for that.
Concrete examples:
1) My first ever professional work was on a process control system that was built out of 8085's. Yes that long ago. There was a whole rack of CPU cards, one for the user interface, one for data logging/fault monitoring, one for the actual process control. That last one had to be split into two when it was discovered there was not enough performance in one CPU. A couple more for other odd tasks.
These all communicated. The process control CPU's shared some RAM so they could work fast together. Others talked over a parallel communication bus. Still others were hanging off of serial lines.
2) Next up I worked on a Radar system. Again a rack full of processors, this time much faster in house design 16 bit beats. But the pattern is the same: one drives the display, one or more do the signal processing, another manages the whole show etc. This time all sharing an address space and communicating over a nice back plane.
3) I could go on but the world is full of such examples. They use VME buses or whatever it takes to get CSP.
So when the Transputer and Occam arrived my first reaction was, "Bloody hell why have I been struggling with all this multi-processor Smile for so long. This simple, fast, tightly coupled to the CPU coms channel idea is all we ever needed. And Occam as a way to write the whole application across many processors, brilliant.
P.S. The Propeller chip architecture looks very much like the block diagram of that radar processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I remember the Transputer. It was big news when I was at Uni. I even considered buying one - but I gave up on the idea when I discovered they wanted some ridiculous (at the time) amount of money for a development board with ONE transputer chip on it. I never could figure out what they expected anyone to be able to do with a single transputer chip. Of course the University itself ended up with a couple - but I suspect they got them as freebies. This also encouraged a brief flurry of interest in Occam - but building a system with more than a few transputer chips was never really cost effective outside supercomputer applications (with supercomputer budgets!). Of course Occam survived because it was also applicable to much cheaper chips.
Time will tell whether XXXX and XC suffer the same fate - i.e. being fondly remembered as technologically innovative but with a price/performance ratio that limited their general applicability.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Interestingly back at my old university they are still hacking on Occam. They have an interpreter for Occam that runs on the Lego Mindstorms would you belive!
transterpreter.org/publications/pdfs/native-transterpreter-lego-mindstorms-rcx.pdf
Hmm.. I wonder if that "Transterpreter" could run in a Cog.....Occam for the Prop anyone?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.