ImageCraft C that generates bytecode
ImageCraft
Posts: 348
Way back when, I gave a rough estimate that ImageCraft C being ~5-10x faster but ~4x larger than Spin. I believe the data from users confirm that. Currently, very few people are actually code space limited, but that day will come. XMM C using external SRAM is a possible solution but at ~1 MIPS at best, it might remain as an item of interest only.
As I said elsewhere, it is possible to rev' ImageCraft C to produce bytecode, may be even a mix of LMM, bytecode and native FCACHE code. There is still no guarantee that Spin objects can be used - that opens up a whole other can of worms that I don't want to deal with right now, but we can solve the (perceived) code size issue.
The real problem, as Mike Green pegged it, is how to pay for the development. Ideally, if more of you purchase Propeller C, that'd increase the likelihood of ImageCraft investing in another major development work. The other possibility is to ask for free help. Lets be honest, ImageCraft isn't a huge company, and with the Financial Meltdown, free help is always welcome. In exchange, perhaps we can set it up so that the contributions shall become public domain or Open Source, as the contributors desire, i.e. ImageCraft will make no claim on them except that we will have a right to use them, plus of course a complementary license (or two, or three...) to the compiler. I don't know whether this is enticing enough for you hackers out there, but it's worth a shot.
The most important thing that comes to mind is a good VM bytecode design and the kernel interpreter. We will want it to be compatible with LMM C if possible.
Anyone interested? You can also PM or send me email directly richard @imagecraft.com
// richard
As I said elsewhere, it is possible to rev' ImageCraft C to produce bytecode, may be even a mix of LMM, bytecode and native FCACHE code. There is still no guarantee that Spin objects can be used - that opens up a whole other can of worms that I don't want to deal with right now, but we can solve the (perceived) code size issue.
The real problem, as Mike Green pegged it, is how to pay for the development. Ideally, if more of you purchase Propeller C, that'd increase the likelihood of ImageCraft investing in another major development work. The other possibility is to ask for free help. Lets be honest, ImageCraft isn't a huge company, and with the Financial Meltdown, free help is always welcome. In exchange, perhaps we can set it up so that the contributions shall become public domain or Open Source, as the contributors desire, i.e. ImageCraft will make no claim on them except that we will have a right to use them, plus of course a complementary license (or two, or three...) to the compiler. I don't know whether this is enticing enough for you hackers out there, but it's worth a shot.
The most important thing that comes to mind is a good VM bytecode design and the kernel interpreter. We will want it to be compatible with LMM C if possible.
Anyone interested? You can also PM or send me email directly richard @imagecraft.com
// richard
Comments
Reading the 'other thread' a lot of people view C as useful to utilize existing code but consider spin and pasm to be the 'natural' choice for the prop.
A code generator which essentially translated to spin but could (optionally) drop into bits of pasm might be useful. In fact if you can make the spin/pasm switching clean and easily optional the C could easily become compelling even for people that believe in one of the 'other' memory models.
The other advantage for you in generating spin rather than bytecode is that you have a better documented, easier to debug and more portable target (unless parallax has guaranteed that propII will use an identical bytecode sequence)
David
Is this compiling a C program to run using the ROM SPIN interpreter?· (I guess so)
What would the advantage be?· Would the code be smaller?·
It would be much slower then, right?
I'm one who does run out of code space often, so I could be one who would benefit from this...
@David if you want to generate spin source from c source, you could very easily write an interpeter using PERL. It's just a matter of translating the syntax from the keywords and operators. A full blown compiler is not necessary.
@Richard I would contribute, but compilers are not my competency or interest.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I don't have any particular desire to do that myself. I was simply suggesting Richard may wish to consider spin as a useful intermediate to get him to bytecode rather than reverse engineering the logic himself.
Also I think you will find that generating high quality spin (or anything else) from C is not an entirely trivial task; this is especially true if the two langauges being translated have significant differences.
David
Your initial idea has merit especially if it could be packaged in a good way. It is not necessary to write a compiler, just a translator. If I have some time I might look into making an ANSI C89 features variant ... dynamically sized arrays from C99 will not be possible without a lot of overhead. I have an example translator written in perl from someone on the forum ... it is "limited", but it works for the design goal. PASM would have to be handled a separately and without direct in-line ability, but other than that there is little difference between C and Spin. I still believe that generating byte code is a better approach in the end even though an intermediate set of spin files would make easier debug. If nothing else, it would make it easier for C programmers to understand Spin and get a smaller image faster. XMM would not be supported ... oh well.
A C translator should generate comparable quality spin. If you write garbage C, you will get garbage Spin ... vis-a-vis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I'm almost sure I've seen one somewhere.....
Coley
<EDIT> Found it.... www.mikekohn.net/micro/propeller_atari_emulator.php
Although I must admit the app doesn't seem to be available, might be worth dropping him an email
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
Post Edited (Coley) : 4/4/2009 10:06:48 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
The biggest advantage of having a C to Spin converter or Spin bytecode C compiler for me is image binary size; the disadvantage is slower performance. If Richard goes down the path of compiling C to Spin bytecode, he could also easily provide for #pragma LMM sections for speed. Kye is right of course about reusing current libraries for those who would choose that path.
If I write a full function C to Spin converter, it would have to be feature limited (cripple-ware) free. Free features TBD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Just a thought... how tough would it be to have in-line compilation of Spin objects using something like the <#include> directive?
I obviously need to do more research before I can converse on this topic intelligently because, for example, I don't understand why Spin is not compiled down into the same machine code PASM is. Does it just need another pass to boil bytecode down into a binary. It would seem to me that a Spin to C converter coupled with existing PASM in-line capability would be better (is that what Richard is talking about?). Pardon my childish questions, but I'm seriously interested in this, and I otherwise tend to be a "Jack of all trades, master of none". A hazard of being a consultant... you usually learn just enough to get the job done.
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
You need to understand the hardware first. A cog has only 512 32-bit words of memory of which 16 are used for specialized functions. You cannot directly execute code from the shared 32K bytes of memory. That's not much to hold a compiled program along with data. The Spin interpreter fills essentially all of a cog's memory if it's used, so there are no provisions for copying in little fragments of native code. The amount of time necessary to copy in a whole 512 word load is prohibitive for executing parts of a program. The LMM (Large Memory Model) interpreter scheme is a nice intermediate model that allows for partially interpreted native code and small blocks of native code, but the native instruction set is not very dense and 32K bytes (8K words/instructions) is quickly used up.
I started on that, got proof of concept working, but then it fell apart due to external personal circumstances while turning that into something better ...
http://forums.parallax.com/showthread.php?p=745374
Despite my lack of later progress, I would still argue it's a quite straightforward process, two man-weeks or so to get something basic working.
I'm not convinced that generating Spin bytecode is the way to go ( or that it is what Richard was suggesting ), it's just as easy to create a kernel / interpreter which fits what needs to be done to match the bytecode. However, I can see the benefit in generating Spin bytecode; an executing C program would effectively be a compiled Spin program so access to objects should be quite easy though a practical means to do it would need to be found.
The downside is that all the effort for that is really in the compiler at the code generation level, so I'm not sure how ImageCraft would open that for community development. I guess it's contact Richard at the email address given if interested in that side of things.
One thing which has intrigued me, given it is so easy to get something basic up and running, is why no one else seems to have pursued this further ? Lots of people seem interested, enthusiastic and encouraging but no one ( Catalina excepted ) seems to be doing much beyond that. Is this just a general problem, it's a small community, little spare time, most are interested but hoping someone else delivers it on a plate ?
Is it the case that the 'altruistic model' doesn't suit Propeller development at this present time beyond people's personal projects; would some sort of sponsorship or reward scheme encourage more activity ?
Perhaps you mistook my intent.
First, I understand the concepts, if not the details, of the two memory models, and in fact not having to load the Spin interpreter into each cog would be a point in favor of what I'm thinking of, which is basically to include a "Spin compiler" in the C compiler that would do what compilers do with source files: Open them, interpret them, and spit out either an object file (module), or an executable file. In this case, for use in LMM. By #including a Spin file, you would make it part of the final output, not a separate little chunk of code requiring an interpreter in each cog.
Again, because I'm new to this level of the discussion, I'm at a loss as to why, if you have PASM available, you would eat up cog memory with interpreters instead of compiling Spin down to a binary executable or a PASM object module that could be used by any compiler.
To Steve's point about size... "Who do you think you're going to please with that little thing?" "Heh, Me." - But that's another story... Are you saying that even with the ability to eliminate the Spin interpreter(s) from the scenario, a compiled C program is too big? This is from the ICC online manual:"Since the instructions are native Propeller instructions, the overhead of using the virtual machine is small compared to a byte code interpreter (such as Spin) from Parallax." I'm guessing they are talking about speed overhead only...
OK. Fire away!
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
RISC instructions are not very dense. LMM's use of "native" instructions may be speed efficient, but it's a hog in terms of memory usage and, at least in the Prop I, there's not a huge amount of memory available.
Yes, the ICC online manual statement you quoted is talking about speed performance overhead.
All LMM instructions are PASM except for LMM primitives like @FLOAD and take 4 bytes. Only some Spin bytecode instructions take 4 or more bytes. If you want to see this, use Hippy's Spin disassembler ... find it here: http://forums.parallax.com/forums/default.aspx?f=25&m=296149 . Many Spin statements and bytecodes invoke multiple pasm instructions ... see this here: http://forums.parallax.com/forums/default.aspx?f=25&m=252691
The Spin interpreter lives in mask rom on the propeller chip and not in your program; this frees about 2KB for you to use. At boot time it is copied to only one cog (unless you have a reason to load another one) where it runs bytecode. Adding another interpreter to replace the one in mask rom would just eat that 2KB memory that you could be using for an application unless someone like Hippy is clever enough to make that memory impact a wash by improving some other factor. BTW I'm firmly convinced that Hippy can do ANYTHING with two man weeks.
As usual Mike's comment is full of useful information based on the part of your question that he appears to think is important to answer. This is NOT a criticism. Many people here find out that is the answer they really need eventually.
Using #include to import Spin code would be an interesting addition for a C to Spin translator of converter. That would be one of many features that C language conventions would define. For example one might use struct definitions to create obj.function syntax in a very similar way that spin does today with the OBJ section.
Added: BTW, I speculate about how things can be implemented sometimes without following through on them because I don't have enough time to do it all. If something comes up that offers overwhelming benefit or absolutely must be done in a short time-frame, I will address it and be done with it. I'm multitasking 4 projects right now. Doing exactly one thing at a time may be less stressful and required in some cases, but is ultimately less rewarding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 4/4/2009 11:24:57 PM GMT
@Mike:
My understanding of what WNed says is: If you include a spin file, the compiler should compile this to PASM in LMM. So, the output is the same as for C code. I guess that would work, but I'm not sure how many SPIN objects would bust the available memory.
@WNed:
The problem is really a speed AND code size problem. In PASM each single command has a size of 32bits. The bytecode, as the name already says, has a size of one byte. SPIN-bytecode is 'interpreted' during runtime. Commands tend to be more complex than PASM commands. So one bytecode command can be seen as a call to a subroutine which performs a number of PASM commands.
Operator handling is different. Each PASM command has a destination and a source encoded whereas SPIN can work with operators on the stack with no need to encode these in the command itself. So, in general bytecode is more compact than PASM-code.
What about a C to Spin compiler? ;o)
1. In the end, it seems as usual that the tool you select depends upon the task at hand. One tool, Spin bytecode, will shove 10 lbs. of program in a 5 lb. sack, while PASM/C, will fill the sack with just 5 lbs., but it'll be a damned fast sack!
2. As someone trying to take in large gulps of learning Propeller and ICC simultaneously, I had thought it might be a good (if masochistic) exercise to try and take some of the simplest objects available and rewrite them as C objects, but MagIO2's comment, "I'm not sure how many SPIN objects would bust the available memory." raises an interesting point? Am I to believe that Image Craft put all that work into a compiler that can only be used to produce trivially small programs? Of course the people at Image Craft seem to think that programs of a scale to be used in industrial applications can be developed using their product, but comments here would indicate a serious limitation... Is that the reason for XMM? ...Or a push for a bytecode compiler?
By the way - the critical piece I was missing at the start was the huge disparity between the size of instructions for each language. I understood that bytecode meant, duh, byte-code, I had just somehow done a disconnect between the use of bytecode and the inevitable size of instructions for a 32 bit machine... might they each occupy, say, 32 bits? I made the connect while doing my internal rant about, "OK Mike, I know the damn hardware... hardware... 32 bit hardware... Sorry Mike." (hanging my head in shame). As Steve sort of said, the answer I needed, not the answer I was looking for. The trade off between speed and size was the one I was looking for.
@Steve - Thanks for the links.
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Post Edited (WNed) : 4/5/2009 12:30:29 AM GMT
From my recollections of 6 months ago...
The spin interpreter seems takes an average of 50 pasm instructions per bytecode. But I had no live data to test with, so this could be skewed. It takes about 25+ pasm instructions to fetch and decode. The arithmetic ones are the quickest. My version was giving about 20+% improvement - only a little faster (10-15%??) in fetching and decoding but saved quite a bit space in the cog (but then used 2K to hold the interpreter and another 1K to hold the vector table, all in hub - so 3K down in hub - the 2K could be recovered by loading from upper 32K eeproms with a tiny stub). This space was used to refine and speedup the remainder of the code. The arithmetic bytecodes were sped up enormously. Others which I thought were used a lot (stack ops) were also targetted with good improvements.
So now you see why spin is fairly slow. I have some space left and I also have a fast sweet spot overlay loader, so overlays could be done for extra commands, such as floating point, etc. This is faster than LMM if any loops are involved, and probably faster mostly/always.
LMM takes 4 instructions to execute which means 2 hub cycles = 32 clocks (so equivalent to 8 instructions per LMM instruction), plus any overhead if inline code modification is allowed. (load, increment, execute loop)
So, in summary... LMM is at least 8 times slower than pasm and uses more memory for large programs as 1:1 with instructions. Spin is about 50++ times slower than pasm but produces much smaller code. I cannot comment on either C version. This should give you some basics to work with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
A four-way unrolled LMM is at most 4.25x slower than PASM, and with optimal use of FCACHE can approach pure pasm speed (the more the FCACHED'd code loops, the closer it gets)
If I was not so busy playing with SPI Flash, and working on LMM, I'd jump into the TriBlade and ZiCog... I used to program quite a bit under CP/M - anyone remember TurboPascal, then Mix C?
Here are a few links for ZiCog:
http://www.cpm8680.com/mix/mix-c21-max.zip
http://primepuzzle.com/mouse/maxz80.zip
http://www.cpm8680.com/mix/mix-c21-cpm-tools.pdf
http://www.mathematik.uni-ulm.de/users/ag/yaze-ag/yaze-ag_doc.html
some instructions at http://groups.google.com/group/comp.os.cpm/browse_thread/thread/b0a445ae9b21cca8/bf6d002954c083ce?lnk=raot&pli=1
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
I don't mean to sound inscrutable. I do remember my compiler-writing classes many years ago and the observation that programs tend to spend about 90% of their time in 10% of their code and that's the code you want to optimize for speed while the rest needs to be optimized for space. Unfortunately, the 10% that's crucial for speed is not known until the program is finished and instrumented to measure where it spends its time. Often it's not where you think it is.
Ned, this may sound blunt, but I have seen this type of quote, you know, just once too often. You are not the first person to say something like this, and as I have said elsewhere, there is no one, except Steve, that has pushed the limit of LMM C. A 32K Propeller is equivalent to an 8K AVR, more or less. there are lots of people using 8K AVR with our compilers writing commercial products that you may even use, right now. So "only for trivial programs?" I don't think so.
So yes, if people said, oooo 32 bits CPU with 8 engines, I will write Linux to run of it!... well may be not. But if someone were to say, hmm... what kind of useful things I can do with 32K of LMM space? It gets much more interesting.
One of my little projects is building a small tracked rover (named RatBot) that I am going to try programming entirely in ICC and PASM. In the process I will be learning a great deal, developing C objects to add to the library, and taking my first step toward world domination. If RatBot runs out of memory along the way, I'll be sure to let you know, but only after I hit up the forum denizens for some optimization tricks.
Here's a photo of RatBot back when it had a skimpy little BS2 brain. This way you have the opportunity to call my baby ugly if it will make you feel better.
@Mike, isn't the purpose of version zero to run and find bottlenecks, etc. for rewriting and optimization? Also, thanks a lot for the books under the pillow tip... didn't get any sleep with those corners digging into my head.
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Post Edited (WNed) : 4/5/2009 8:51:35 AM GMT
I think it's more true to say that observations reveal a "potential limitation" in terms of how large or complicated a C program can get before the Hub memory size limitation becomes a problem. Propeller II, XMM and bytecode all reduce or remove the potential limitation by providing considerably more memory to use than the current 32KB Propeller.
There's probably little contention in saying that the more memory you have the larger your programs can be but it's harder to say how a particular memory size limits what programs can be written. The same can be said of Spin even though it has better code density; there are already some who complain the 32KB Propeller doesn't have enough memory, though that perhaps most frequently comes down to data storage rather than code, particularly in terms of video buffer.
C programs will run on the Propeller, larger C programs will run by generating bytecode, by adding XMM or by using the Propeller II. The pertinent question at present for the current C-LMM compiler is IMO; what can be done with an 8K instruction Propeller, at what point does it require XMM ?
While I know buying a single seat car has potential problems which a two-seater would reduce, and a four-seater more so, that doesn't tell me how much of a problem there will be in practice. Will it more often than not be suitable or will I frequently run into problems ?
What we don't have at the moment are, "this is a credible C application which I'd expect to run on a Proeplller; it doesn't, or it does and required X% of available memory", feedbacks which would allow on-paper observations to be set against practical experience.
We're stuck with wondering if the house we are about to buy is going to big enough having no idea what we can actually fit inside it, all we have is the floor area known and knowing less big boxes will fit than smaller boxes.
It's not so much about being negative as it is about being cautious, wanting to make an informed decision when making a commitment.
Bill: I guess since you have a whole cog to play with you can unravel the fetch mechanism for LMM to get some improvement. However, you either have to implement a stack mechanism or else a method for self-modifying code, and both of these will add extra instructions to be executed.
I·still think overlays would be quicker and certainly no slower as I can hit the sweet spot in loading, and no problems with instruction modification (within the overlay or resident code). However, I cannot comment on its' impact·on the·compiler, so this may not be a practical solution. Richard?
Anyway, for the most part, tight PASM code is only needed for specialised tasks. The code which is likely to be large can probably afford to run at 4x-8x slower anyway. It is the 50x slower with spin that is likely to be a problem for some professionals. Somewhere, I am sure Richard commented about ICC's relative speed and I thought it was somewhere in the middle of these extremes (is this right Richard?)
Richard, everytime someone mentions another chip has this or that, I usually look to find it doesn't have the memory that the Prop has, so your point makes·even more sense. I know some of the latest chips have more memory, but often it is EPROM and little RAM space. This may be good and maybe bad, depending on the application. There are hundreds of various PICs available, but you often need a different one for different designs. Code may be similar, but not the hardware.
It's true, a lot of memory is used up for the video, which by the way is external on other chips, so just use another prop for this if you need the extra memory.
So I guess my question has to be... Why are professionals not using C for·Propeller projects? Is it because they are using PASM or is it because they do not take the Propeller seriously or know about it? From my observations, most are probably not on this forum. Personally, I think the answer is in this order... Don't know about it, not taken seriously, and lastly,·using PASM. Someone needs to make that killer application (hardware & software) to get the exposure.
And finally, Hippy hit the nail on the head - we are all guessing but· noone knows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'm a fan of Propeller though restrained compared to the cheerleaders. I'm a fan of C and its derivatives because that's where I've made my living most of the last 20 years. I've been a Parallax customer about half that time. I'm amazed at what some people can do with little micros.
My applications are like a size 12 shoe, Propeller comes in a size 9. Guess my feet are just too big. Either I cut off my toes, or get sandals [noparse]:)[/noparse]
P.S. Unix CC worked great. Turbo C sucked. Turbo Pascal was better than Turbo C only because it worked. GNU is like manna from heaven.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
On my list of things to do, when I have infinite time, is to create a new language that is much closer to C, but that converts directly to SPIN so that Propellent can compile it.
I think Parallax would have done us all a favor if they would have made SPIN closer to C to begin with... I think maybe that they are Pascal/Delphi people so made it that way instead...
I currently program in both C++ and SPIN... I find the differences in syntax very annoying. Especially, when creating a Windows App to interface with the Propeller, so that I have both editors open.... Can't help but make mistakes...
What I originally meant with my comment is: If you have this #include command, which is able to compile SPIN-code into LMM-PASM, then I'd wonder how much SPIN objects would be needed to bust the HUB-RAM. As already explained SPIN-code is very compact. So, making PASM code out of it will increase size. Usually in a real project you don't use only one object of the ObjectExchange. Of course this very much depends on the ratio of SPIN/PASM in the *.spin-file. Some objects have only short SPIN wrappers and the main part is a driver which is written in PASM and continuously runs in a COG.
@all:
I once asked in a microcontroller forum why the propeller is not used more often in their projects. Answer: The'd loose their C libraries that they build up in years.
I am looking for the answer: Is is code density or speed thats needed with ICC (or Spin for that matter)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
These days I work in a fairly niche market; volumes are low and prices are higher than mass market products. I've been aware of the Prop since it was first introduced but had filed it under 'interesting but can't see a need for it (in what I do)'. Things changed at the end of last year when I had a very niche product to develop which needed a VGA output. All of my work is 'OS-free embedded' so any standard components were out of the question. I guess I could have goes FPGA or one of several chips with inbuilt VGA but, as a small company, the cost to move into those areas was too high. Then I remembered the Prop and bought a Proto board and demo board from Mouser. I was very impressed how easy it was to get something running.
So, I added a prop to the CPU card to sit alongside the other MPU with the prop looking after the VGA, keyboard and SD card ( I posted photos somewhere on the forum if you want to look).
Now I have another project on the table. It's for a slightly broader market although volumes will still be low and prices high, about 1,000USD. I have been thinking 'Can I do it all with a Prop?"
For some of the code, the user interface, speed doesn't matter. Spin is plenty fast enough, C is faster. People can only push buttons so fast. For the rest of the code speed is very important. I need to take data from externals sources, buffer it into arrays, performs maths on it and then send it to other external devices. The maths operations change depending on user input. I need to do this every 10us, every second of every hour of the day. I also need to handle an SD card, a PS2 keyboard, a VGA display and 2 full-duplex serial ports delivering and taking the data. SPIN isn't fast enough for maths or peripherals. LMM C is unlikely to be fast enough. So, my COG allocation goes...
0 - Runs Spin Interpreter or LMM C
1 - Runs Maths functions in PASM
2 - Keyboard in PASM
3 - SPI code for SD card in PASM
4 - VGA in PASM
5 - VGA in PASM (running 80x40 so 2 COGs)
6 - Full Duplex serial in PASM
7 - Full Duplex serial in PASM
I'm fairly certain that I now have enough processing power!
Now my memory requirements. I have 7 COGs to load; 7 x 512 longs = 3584 Longs leaving me 4608 Longs. I then need 800 longs for VGA buffers and 1536 longs for data arrays. So, I now have 2272 longs free for all my high-level code. Which is about 1,000 lines of SPIN or about 400 lines of C without allowing for other variables and the stack. So, without doing something 'clever' I'm not sure I can do it all in a Prop, certainly not in LMM C.
But, with the fantastic resource which is this forum, I can see a way to do it. My PASM code, which is about 45% of my memory footprint, can be loaded from the upper 32k of EEPROM at boot time. I have the VGA buffer which can be used to load from EEPROM, or even SD card and then to load the code in the COG with the buffer being reused. Suddenly I double my code space for no money and I can probably do what I want.
A larger commercial developer though would simply look at the Prop, see too many obstacles and go for an ARM7 instead.
Today I have been taking various objects and hacking them together in SPIN to prove the concept of the project. Once I know it will work I will rewrite in C. Spin just has too many missing bits for my liking.
I think one of the Props problems, and therefore the tools for the Prop, are that until you've played with it, it all looks a bit quirky and 'hobbyist'. It is however a very interesting chip for some applications. It is a perfect fit where you can mentally divide your project up as I have done above. But, had I not wanted VGA, I very much doubt if I would have considered it.
The C library argument is an interesting one but I don't think, in reality, it affects Prop uptake. It's true many developers have a large library of C functions or purchase third party libraries. but these lumps of code are generally for larger systems, things like mobile phones, which aren't a target application for the Prop anyway. For the sort of applications the prop is good at, most code will be written from the ground up. Yes, I have a library of useful functions but these are mostly a few dozen lines long, things like button debouncers, and porting then into any language is trivial. The key part to them is the algorithm not the source code.
So, speed or code size?
I guess the answer is both but in preference code size. My reasoning is that the philosophy of the prop is 'soft peripherals' which will, to be useful, be written in PASM. Once you have a soft peripheral you can give it more intelligence to offload processing from your main code. My main code will not touch any of my data. It'll all be done in PASM. So my main will be looking after user IO where I have a more relaxed throughput. And I think this is the correct approach for the Prop. Using just one COG running a single threaded piece of code means you are using the wrong chip for the job.
Hmmm? A library of soft peripherals with a unified interface. Kind of like a traditional USART on a mainstream micro, controlled by 'registers' but with a bit more intelligence to take the load of the main processor. Things like the peripheral handling XON/XOFF with user-defined trigger levels. Intended to be used by most people at the binary level and built with overlay loading in mind. With built in compiler support for pulling them in from extended memory.
C to SPIN translation? No, it'll be horrible. You'll be trying to map things SPIN doesn't support onto code not designed to run it.