@RossH: OT - It was already diverted, so what the heck
@heater: I totally agree except that Basic and Pascal are easier than C and Spin. I say that because of the operators <|, ~~label, etc, which makes reading them a nightmare unless you are totally fluent in these obscure operators. I <emphasis> HATE </emphasis> their use. It is just not readable, but I live with it - and I have an engineering background although I have done both hardware and software from almost the beginning. I choose to avoid them wherever possible. IMHO Spin is much much easier than C.
Now, having said all that, the Prop MUST have C, period !!! It is required to get the chip into mainstream where it will be noticed. As time goes by, I see there will be a migration to a mix of C and Spin (yes, I believe they will co-exist, if they cannot already).
There is also a valid point in longevity. We know this, but professionals do not. So this is another reason for C.
Now, once exposed to the prop, it is easy to see how it can be used in all sorts of ways. And, the one chip does it all. No need for lots of inventory with different flavours of PICs, etc.
The Prop II will have an even bigger requirement for C. And, the Prop I & II will co-exist, as, in many respects, they are really different beasts for different jobs. Something akin to 8086 and 80486 or 6800 to 68000 although the instruction set was completely different in the latter case.
FWIW: I have designed many professional circuits in my time, and I am very much aware of single sourcing and reliability of supply. These things still burn you - I have not found that magical crystal ball yet. But, I have no problems with using a prop in a professional design of mine (not able to be released here). I only have to ensure I have one chip in stock and a few other bits which can be substituted. I am more concerned with the world-wide chip and component shortage looming on the horizon. It will probably be easier to get prop chips because we probably won't get the bandits buying up this stock and holding them to ransom.
Someone mentioned security and potting. That's what I will be doing. I am actually more concerned with knock-offs coming from the manufacturing sources. You only have to look at the proliferation of knock-offs coming from China. I have a few ideas, but once they become mainstream, they become ineffective.
Again, just my 2 cents
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I only not agre with word "profesionals". Good Profesionals not looks on what programing language are used but how good hardware functions with software available to it.
heater.
I agre with You on that Parallax is very stable company.
RossH.
Thanks for nice work on Yours "C" for Propeller that is free for us.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha: Respectfuly, I disagree. Professionals should (but some don't) look at all aspects including language, software, hardware, cost, availability. The language comes into play because a company (as has been said above) may have a lot of code done and they do not want to waste that investment. Sometimes it is cost effective to change processors and other times it is not.
However, often people do not want to move from their comfort zone. I believe that is an issue here with the C requirement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
There is a simple and cheap way to achieve practical code security on the current Propeller:
Get an ultra-cheap 8-pin PIC (which DOES have code protect) and code up some cypher algorithm which receives·a byte stream from the Propeller (made from RealRandom.spin), translates it using·an algorithm matched in the Propeller, and then sends it back to the Propeller for verification. If the Propeller doesn't get back the right translation, then it doesn't execute its program, or maybe screws up just enough to render the copy unreliable, or maybe even erases its entire EEPROM.
For this protection to be overcome, one would have to reverse-engineer the contents of the EEPROM into executable behavior - Spin AND self-modifying PASM. What a pain! You could obfuscate·things quite badly, if you bothered to.
This method would take 1 pin of a Propeller, an 8-pin (or 6-pin) chip,·and cost under 50 cents to implement. It's not all automatic like selecting a code-protect fuse, but it would be pretty effective. And you could change up each different end-product's implementation a little, so that each product would have to be cracked anew.
heater said...
Jazzed "and Spin is a very close relative of Pascal if you haven't noticed"
...
Spin may look a bit like PASCAL, it for sure does not have the semantics of Pascal.
Your right. Having some syntactic similarity does not make it a close relative.
There are abundant differences of course, but here some comparisons for those who don't know (SPIN first then PASCAL):
Both have a CON like statement
CON
BITS = 9
CONST
BITS = 9;
Both have a VAR statement
VAR
long value
VAR
value : integer;
Both use := for assignment
val := 4
val := 4;
Both have repeat until. These are identical because of Pascal's curious end of body ";" rule.
repeat
x := x + 1
until x > 4
repeat
x := x + 1
until x > 4
A Spin programmer might learn C faster than Pascal, but I suppose we would never know.
The propeller HAS C support from ImageCraft and Catalina. Is the problem that they don't come directly from Parallax? Does anybody use a ARM compiler supplied by ARM? I thought most developers use Keil or some other third party compiler? What is the problem?
I haven't used it, but I thought that ImageCraft C would generate cog code also, not just LMM code..
Someone want to explain the problem to me?
I am guessing that when the TurboProp comes out ImageCraft and others will have compliers for it also.
Chip: Yes, I agree, there are many cheapish ways to hide the code, particularly in self-modifying code.
The PIC10F2xx series is a great candidate. PIC10F200 is 34c in qties 100 (DigiKey), SOT-23-6 6pin package, 0.95mm pin spacing. See photos of the RamBlade U3. It has been designed to take a PIC10F2xx in the future. This would not even require a pin as it can co-exist with the Eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Leon said...
The Propeller architecture simply isn't suitable for C, and the compilers aren't efficient enough to make them a viable alternative to PASM.
Leon,
I don't understand your comment.· Spin is basically a subset of C with a different syntax.· The Spin intrinsic functions can be provided in a C library, or they can be implemented as macros.· Compiled C is probably a good alternative to PASM in a lot of cases.· Of course, there will always be time-critical functions that need to be implemented in hand-written assembly.
The main issue with selecting a language is which one is best for a particular application.· If I need to do something that requires a full 20 MIPS or more of compute power I would use assembly in one or more cogs.· If I need to do something that uses objects that exist in the object exchange library, I would probably use Spin.· If I'm porting a large piece of code that is already written in C I would definately use C.
Fundamentaly, there is no reason that a particular application couldn't use all three languages running in different cogs.
Dave
hinv said...
I really don't understand this argument.
... Someone want to explain the problem to me?
Efficient compilers or not, the Propeller has to "interpret" any program > 496 instructions. Other microcontrollers run C output (machine/assembly code) directly without interpretation limited only by their stated code size (up to 512KB in some cases). While one <unnamed uc> for example runs C compiled instructions at 20MHz, the Propeller would run similar instructions at 5MHz (assuming 80MHz operation). Of course, Propeller has advantages, but for reasonable/larger size C programs, the advantages are less clear.
Maybe not the explanation you're looking for since the answer does not address the compiler producer. However, if the device were designed to run C, it would make sense for the device have a tool-chain from the beginning. But that was not important to Parallax since their focus is what Chip wants to produce rather than what a large set of customers may prefer initially to use. What most customers want over time may change, but educating everyone to take that direction is costly. Meanwhile the technology adapters and curious onlookers get to have fun ....
@Leon - The fact that Spin is compiled into interpretive code has nothing to do with it. There are a number of C compilers that produce interpretive code. There are a number of C compilers that produce mostly sequences of subroutine calls so that they can call themselves native instruction compilers, yet in terms of code density and execution efficiency are worse than good interpretive implementations.
Spin is functionally a subset of C in that it uses most of the same control structures (with different syntax), has most of the data structures of early (pre-ANSI) C and most of the operators. It has the same loose typing as was in early C.
Leon said...
The Propeller architecture simply isn't suitable for C, and the compilers aren't efficient enough to make them a viable alternative to PASM.
That is simply not true Leon! As you well know, it totally depends on what the user requires.
...taking a deep breath...
jazzed said...
Efficient compilers or not, the Propeller has to "interpret" any program > 496 instructions. Other microcontrollers run C output (machine/assembly code) directly without interpretation limited only by their stated code size (up to 512KB in some cases). While one <unnamed uc> for example runs C compiled instructions at 20MHz, the Propeller would run similar instructions at 5MHz (assuming 80MHz operation). Of course, Propeller has advantages, but for reasonable/larger size C programs, the advantages are less clear.
The prop does not have to "interpret" programs > 496 instructions. Overlays can load at 1/4 overhead. LMM can run with 1/4 overhead as an approximate worst case. This translates to approx 1/5 so 20%. Thus an 80MHz prop is now running at 16MHz but we do have 8 cores to share the load. So, 8 * 16MHz = 128MHz. Do not forget the efficiencies of the prop pasm code which would then boost this up again.
I am not saying that C is the best thing for the prop, but I am saying it can run C quite satisfactorily. It totally depends on what the end use is to be. The prop has a lot of unique features that are not possible on other architectures.
BTW: This thread is way off topic and seems to have developed into criticism of the prop. For those that do not like the prop, go back to your other forums and leave us alone to enjoy what we have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
1) In general it is expected that a C compiler compiles down to the native instruction set of the target architecture. There are exceptions of course but that is basically what C is for.
2) It is generally expected that a modern compiler can produce assembly code that is approaching the efficiency of hand coded assembler.
3) On the Propeller architecture that does not make any sense. You would end up with all the power of C crammed into those 496 native instructions that fit in a COG. It's a huge lot of work to create such a compiler for such a small job.
3) Such a C compiler having to implement a stack in code as there isn't one in PASM. Having to implement indexed addressing in code as there is non in PASM etc etc would probably generate code that is no where near as efficient as expected.
Hence Leon's stance that C is not a viable alternative to PASM.
Leon: Be careful. Spin is basically a sub set of C. The fact that it is interpreted or not is neither here nor there. That is an implementation issue. There are interpreters for C, there could conceivably be a compiler for Spin. There could conceivably be a hardware processor built that executes Spin bytecodes directly. Which makes the Spin Tool a real down to the metal compiler.
Hmm...thinks...Interesting project idea there, create a soft core CPU for an FPGA that executes Spin bytecodes directly.
Hmm...thinks more... If you could squeeze 8 of those Spin cores on an FPGA with HUB RAM you would have a fast running Propeller. Except that it can't do PASM. If it was fast enough it would not have to !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think I should emphasise that the statement "C is not a viable alternative to PASM" is in the context of writing PASM for the COG. Which I believe is the context Leon meant it in. For sure I do.
Once you move away from actual PASM in a COG we are in the world of LMM or byte codes so choose you poison, Spin or C or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A good example of "pick the tool to fit the task" is PropBasic and its older sibling SX/Basic. As compilers go, these are pretty primitive with very limited expression handling. It does generate PASM code directly and provides a very useful framework for multi-cog programs coupled with a lot of built-in statements for common microcontroller tasks like serial I/O and other I/O pin manipulation and timing. It's a good match for tasks that might have been done with a Stamp and Stamp Basic.
heater said...
I think I should emphasise that the statement "C is not a viable alternative to PASM" is in the context of writing PASM for the COG. Which I believe is the context Leon meant it in. For sure I do.
Once you move away from actual PASM in a COG we are in the world of LMM or byte codes so choose you poison, Spin or C or whatever.
Yes, that is how I meant it. Implementations of C for other MCUs are usually very efficient, nearly as good as assembly language in some cases.
Very few, if any, mainstream C compilers for embedded systems compile to interpreted code. Spin is different from C in many other ways. For instance, the syntax is quite different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Well OK, apart from the syntax and the semantics and the target (raw asm or bytecodes) and the "objects" you must admit that conceptually Spin is a subset of C [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Perhaps spin could be redone to have lots of curly braces, would that help? C-SPIN, basically spin but looks like C [noparse]:D[/noparse]
More seriously given that to make the most of the propeller you need to code taking into account the hardware is there going to be a massive difference between porting to Spin and changing the C code to match the propeller if native C was supported? Micros applications are never so massive that I would worry about direct code re-usage other than having code that shows me the algorithm I want to code, that is the real work of programming for me anyway.
Graham Stabler said...
Perhaps spin could be redone to have lots of curly braces, would that help? C-SPIN, basically spin but looks like C [noparse]:D[/noparse]
More seriously given that to make the most of the propeller you need to code taking into account the hardware is there going to be a massive difference between porting to Spin and changing the C code to match the propeller if native C was supported? Micros applications are never so massive that I would worry about direct code re-usage other than having code that shows me the algorithm I want to code, that is the real work of programming for me anyway.
I think it depends on the application whether it is better to convert C code to Spin or port the C code directly to the Propeller using a C compiler.· I started working on a C-to-Spin converter a few months ago, and I'm about half-way done with it.· There didn't seem to be much interest in it, so I put it on the back-burner for now.· I did test it out on a 2,500 line C program that is used to load Xilinx chips throught he JTAG interface.· This program was too large to fit in hub memory using a C compiler.· However, I was able to convert it to Spin using the·cspin utility, and I was able to fit it in hub memory.· I would never have attempted to convert this program to Spin by hand.· It contained a few structs that would have been difficult to map by hand
There are other cases where it would be better to keep the code in C.· There may be an application that is designed to run on many platforms and processors.· In this case it is better to maintain one set of source code instead of having multiples copies in different languages.
Dave
Very funny curly brace observation Graham [noparse]:)[/noparse] Except for having to remember the difference between <= and =< and some syntax stuff, SPIN is C like, Pascal like, and Java like, etc.... Once you know a few languages, Spin is cake.
Dave's translator is doing something good as expected: C in Spin-sized bytes. Of course the source and performance is still Spin. Why no one ever chose Spin byte codes as the output considering Propeller's memory size is beyond me (even reading the excuses provided by the decision makers).
... on to other things ....
If the original topic was just troll-bait, that's too bad. In a free world, everyone has the right to get and filter information as well as ask questions. The original poster led it this way, so it's on topic whether someone likes it or not. Maybe the internet is not such a great idea after all [noparse]:)[/noparse]
My opinions based on participation here over the last two years and enjoying the Propeller since it's introduction are honest and informed. Hopefully the next guy who gets over-excited will have at least some warning against getting too attached to over-extended expectations.
Sharing any ideas here is obviously not useful unless they agree with someone who agrees with almost everyone else [noparse]:)[/noparse] Forums, it seems are not worth the trouble for businesses. At least people here are mostly civil.
If Propeller can not sustain a little criticism, then it's probably less valuable than you think, you are in denial, or you are being dishonest.
Cluso99 said...
...taking a deep breath...
The prop does not have to "interpret" programs > 496 instructions. Overlays can load at 1/4 overhead. LMM can run with 1/4 overhead as an approximate worst case. This translates to approx 1/5 so 20%. Thus an 80MHz prop is now running at 16MHz but we do have 8 cores to share the load. So, 8 * 16MHz = 128MHz. Do not forget the efficiencies of the prop pasm code which would then boost this up again.
There is little difference interpreting LMM PASM/macro instructions and constantly overlay loading PASM to achieve greater than 496 instructions per COG and you know it. It's just something that has to be done to make it more useful than the original design. ... at least it's a possibility and whether it's a good idea or not is up to the end user who may have a lot at stake or not.
Right now, I look at all of this evolving kind of like the punch card business. Punch cards were not very practical after 60 years or so from the 1920's (but that's all we had thanks to the Card Tabulating Machine Company ... IBM), so people came up with good solutions over time and profited from it one way or another (financially, creatively, or otherwise). What you and many of us have done is try to come up with better solutions than punch cards (analogy) for the Propeller to extend its possibilities. Doing interesting things is satisfying.
In retro-spect, I consider much of the enhancements a huge mistake as people reading in due-diligence here now would think that propeller is not attractive for anything other than the constantly promoted other-fitting solutions. People who yearn for Z80 for example may find happiness here, since that is apparently a reasonable solution with Propeller and probably fits with some visions of what embedded or otherwise computing should be. In the meantime the concept of the Propeller architecture is shown to be great ... for a limited set of things.
I hope your entries to the Propeller Popularity Contest do well this year so that all new comers expectations can be properly aligned by the contest announcements and the history of winners. There are some good projects that have come to Propeller, hopefully there will be more.
I have some small projects to complete for the current Propeller and I will do that or maybe use a better fitting micro in the case where there is not enough resources. If Propeller II ever comes, I'll use it because it is an attractive idea. Still I won't hold my breath for Propeller II.
Dave's translator is doing something good as expected: C in Spin-sized bytes. Of course the source and performance is still Spin. Why no one ever chose Spin byte codes as the output considering Propeller's memory size is beyond me (even reading the excuses provided by the decision makers).
....
If I can find someone who will write spin bytecode assembler, this should be a fairly easy job. Heck, a real documented on Spin bytecode instruction set, similar to even Parallax assembler code reference, would be sufficient. I can't afford to spend time to turn the disassembled code etc. into a document that I can use.
For now, I am waiting for V2, then make tons of money with ICC for Prop V2, then I can afford to redo ICC for Prop V1 with Spin bytecode.
But food needs to be put on table.
It's good that hobbyists have dayjobs, but this is my dayjob.
If you want C with byte codes use GCC and the Zog VM [noparse]:)[/noparse]
Dave Hein: Is that 2500 lines of C code for JTAG open for inspection? I'd love to compile it for Zog byte codes and see how it compares in size to your C to Spin translated version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jazzed said...
Dave's translator is doing something good as expected: C in Spin-sized bytes. Of course the source and performance is still Spin. Why no one ever chose Spin byte codes as the output considering Propeller's memory size is beyond me (even reading the excuses provided by the decision makers).
You said it yourself - the performance would be SPIN performance. The current C compilers are already between 4 and 8 times faster than SPIN, and many people complain that even this is too slow (which is a complaint I don't really understand - slow compared to what? It's faster than SPIN, and you can't compare it to PASM since you can't even write PASM programs larger than 496 longs without using some kind of LMM - in which case your PASM program would execute at about the same speed as C).
As heater says - if you are satisfied with SPIN speeds, then ZOG may be the right answer.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Anyway a little comment on the following statement is in order:
"People who yearn for Z80 for example may find happiness here, since that is apparently a reasonable solution with Propeller and probably fits with some visions of what embedded or otherwise computing should be"
I'd just like to point out that the Z80 emulator and it's predecessor PropAltair are just hobby projects, just for fun.
It all started with PropAltair which was never supposed to be a "serious" project. It was just my first ever attempt at PASM programming for this new fangled chip I had discovered. A learning exercise.
I am surprised and glad that some here have had some fun with them. The whole project has taken on a it's of it's own.
It in no way fits my vision of what embedded or other computing should be. For any serious work I would never start with or recommend ZiCog (or a Z80) (Unless you really do have to run some old Z80 binary blobs for some obscure reason).
It should be clear to everyone, this is just for fun.
Despite my obsession, the Propeller world is much bigger than ZiCog. This forum brings up new and fascinating ideas tackling a huge variety of tasks and applications on an almost daily basis.
Prop II is going to make that world even bigger in ways we probably can't imagine yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I hope not also. But you're right - his post could be read that way. Jazzed? Are you still with us?
@heater,
I did preface my remark with "if you are satisfied with SPIN speeds" ... on that basis I think ZOG still fits in the "totally crazy" category [noparse]:)[/noparse]
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
What octal really wants is to make it easy to hide the fact he's stolen someone else's code. That's the most common reason someone gets nervous about spies.
I've tried to shake this addiction a few times. No Luck! It's harder than quitting smoking (done) or coffee (pending) ... being absolutely convinced it's the right thing to do is key. Not convinced yet[noparse]:)[/noparse] Seeing things like the AM and FM transmitter thread is just too priceless to miss.
The Propeller II is a great carrot considering how we've all come to enjoy the first Propeller. I just have some projects that need more resources *now* and can't wait an eternity for an open ended promise. This is what I mean by "I won't hold my breath ...."
C compiled to Spin byte code is memory efficient. You know the old saw about performance and memory size being a trade-off in many cases at least. You don't need to add 2K bytes to your program to use it because it is built into prop's ROM just like the character set and the transcendental math tables. When faced with 4 times as fast and won't fit -vs- works great but slow there is little choice.
I really do want to see GNU tools available for Propeller one way or another. If it has to be emulated, I'll just put a bag over it's head and ignore the side effects [noparse];)[/noparse]. Native PASM/LMM would be better for Propeller II of course ... until download times make excuses to take an early lunch [noparse]:)[/noparse].
Now to assemble my newly arrived Xtune PropPad Mini and port 65K color GUI code for it and Rayman's PSM ....
Comments
@heater: I totally agree except that Basic and Pascal are easier than C and Spin. I say that because of the operators <|, ~~label, etc, which makes reading them a nightmare unless you are totally fluent in these obscure operators. I <emphasis> HATE </emphasis> their use. It is just not readable, but I live with it - and I have an engineering background although I have done both hardware and software from almost the beginning. I choose to avoid them wherever possible. IMHO Spin is much much easier than C.
Now, having said all that, the Prop MUST have C, period !!! It is required to get the chip into mainstream where it will be noticed. As time goes by, I see there will be a migration to a mix of C and Spin (yes, I believe they will co-exist, if they cannot already).
There is also a valid point in longevity. We know this, but professionals do not. So this is another reason for C.
Now, once exposed to the prop, it is easy to see how it can be used in all sorts of ways. And, the one chip does it all. No need for lots of inventory with different flavours of PICs, etc.
The Prop II will have an even bigger requirement for C. And, the Prop I & II will co-exist, as, in many respects, they are really different beasts for different jobs. Something akin to 8086 and 80486 or 6800 to 68000 although the instruction set was completely different in the latter case.
FWIW: I have designed many professional circuits in my time, and I am very much aware of single sourcing and reliability of supply. These things still burn you - I have not found that magical crystal ball yet. But, I have no problems with using a prop in a professional design of mine (not able to be released here). I only have to ensure I have one chip in stock and a few other bits which can be substituted. I am more concerned with the world-wide chip and component shortage looming on the horizon. It will probably be easier to get prop chips because we probably won't get the bandits buying up this stock and holding them to ransom.
Someone mentioned security and potting. That's what I will be doing. I am actually more concerned with knock-offs coming from the manufacturing sources. You only have to look at the proliferation of knock-offs coming from China. I have a few ideas, but once they become mainstream, they become ineffective.
Again, just my 2 cents
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Nice summarise.
I only not agre with word "profesionals". Good Profesionals not looks on what programing language are used but how good hardware functions with software available to it.
heater.
I agre with You on that Parallax is very stable company.
RossH.
Thanks for nice work on Yours "C" for Propeller that is free for us.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
However, often people do not want to move from their comfort zone. I believe that is an issue here with the C requirement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Get an ultra-cheap 8-pin PIC (which DOES have code protect) and code up some cypher algorithm which receives·a byte stream from the Propeller (made from RealRandom.spin), translates it using·an algorithm matched in the Propeller, and then sends it back to the Propeller for verification. If the Propeller doesn't get back the right translation, then it doesn't execute its program, or maybe screws up just enough to render the copy unreliable, or maybe even erases its entire EEPROM.
For this protection to be overcome, one would have to reverse-engineer the contents of the EEPROM into executable behavior - Spin AND self-modifying PASM. What a pain! You could obfuscate·things quite badly, if you bothered to.
This method would take 1 pin of a Propeller, an 8-pin (or 6-pin) chip,·and cost under 50 cents to implement. It's not all automatic like selecting a code-protect fuse, but it would be pretty effective. And you could change up each different end-product's implementation a little, so that each product would have to be cracked anew.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Your right. Having some syntactic similarity does not make it a close relative.
There are abundant differences of course, but here some comparisons for those who don't know (SPIN first then PASCAL):
Both have a CON like statement
Both have a VAR statement
Both use := for assignment
Both have repeat until. These are identical because of Pascal's curious end of body ";" rule.
repeat x := x + 1 until x > 4 repeat x := x + 1 until x > 4A Spin programmer might learn C faster than Pascal, but I suppose we would never know.
The propeller HAS C support from ImageCraft and Catalina. Is the problem that they don't come directly from Parallax? Does anybody use a ARM compiler supplied by ARM? I thought most developers use Keil or some other third party compiler? What is the problem?
I haven't used it, but I thought that ImageCraft C would generate cog code also, not just LMM code..
Someone want to explain the problem to me?
I am guessing that when the TurboProp comes out ImageCraft and others will have compliers for it also.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
The PIC10F2xx series is a great candidate. PIC10F200 is 34c in qties 100 (DigiKey), SOT-23-6 6pin package, 0.95mm pin spacing. See photos of the RamBlade U3. It has been designed to take a PIC10F2xx in the future. This would not even require a pin as it can co-exist with the Eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I don't understand your comment.· Spin is basically a subset of C with a different syntax.· The Spin intrinsic functions can be provided in a C library, or they can be implemented as macros.· Compiled C is probably a good alternative to PASM in a lot of cases.· Of course, there will always be time-critical functions that need to be implemented in hand-written assembly.
The main issue with selecting a language is which one is best for a particular application.· If I need to do something that requires a full 20 MIPS or more of compute power I would use assembly in one or more cogs.· If I need to do something that uses objects that exist in the object exchange library, I would probably use Spin.· If I'm porting a large piece of code that is already written in C I would definately use C.
Fundamentaly, there is no reason that a particular application couldn't use all three languages running in different cogs.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/22/2010 5:14:36 PM GMT
Maybe not the explanation you're looking for since the answer does not address the compiler producer. However, if the device were designed to run C, it would make sense for the device have a tool-chain from the beginning. But that was not important to Parallax since their focus is what Chip wants to produce rather than what a large set of customers may prefer initially to use. What most customers want over time may change, but educating everyone to take that direction is costly. Meanwhile the technology adapters and curious onlookers get to have fun ....
Spin is functionally a subset of C in that it uses most of the same control structures (with different syntax), has most of the data structures of early (pre-ANSI) C and most of the operators. It has the same loose typing as was in early C.
...taking a deep breath...
The prop does not have to "interpret" programs > 496 instructions. Overlays can load at 1/4 overhead. LMM can run with 1/4 overhead as an approximate worst case. This translates to approx 1/5 so 20%. Thus an 80MHz prop is now running at 16MHz but we do have 8 cores to share the load. So, 8 * 16MHz = 128MHz. Do not forget the efficiencies of the prop pasm code which would then boost this up again.
I am not saying that C is the best thing for the prop, but I am saying it can run C quite satisfactorily. It totally depends on what the end use is to be. The prop has a lot of unique features that are not possible on other architectures.
BTW: This thread is way off topic and seems to have developed into criticism of the prop. For those that do not like the prop, go back to your other forums and leave us alone to enjoy what we have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
1) In general it is expected that a C compiler compiles down to the native instruction set of the target architecture. There are exceptions of course but that is basically what C is for.
2) It is generally expected that a modern compiler can produce assembly code that is approaching the efficiency of hand coded assembler.
3) On the Propeller architecture that does not make any sense. You would end up with all the power of C crammed into those 496 native instructions that fit in a COG. It's a huge lot of work to create such a compiler for such a small job.
3) Such a C compiler having to implement a stack in code as there isn't one in PASM. Having to implement indexed addressing in code as there is non in PASM etc etc would probably generate code that is no where near as efficient as expected.
Hence Leon's stance that C is not a viable alternative to PASM.
Leon: Be careful. Spin is basically a sub set of C. The fact that it is interpreted or not is neither here nor there. That is an implementation issue. There are interpreters for C, there could conceivably be a compiler for Spin. There could conceivably be a hardware processor built that executes Spin bytecodes directly. Which makes the Spin Tool a real down to the metal compiler.
Hmm...thinks...Interesting project idea there, create a soft core CPU for an FPGA that executes Spin bytecodes directly.
Hmm...thinks more... If you could squeeze 8 of those Spin cores on an FPGA with HUB RAM you would have a fast running Propeller. Except that it can't do PASM. If it was fast enough it would not have to !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Once you move away from actual PASM in a COG we are in the world of LMM or byte codes so choose you poison, Spin or C or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, that is how I meant it. Implementations of C for other MCUs are usually very efficient, nearly as good as assembly language in some cases.
Very few, if any, mainstream C compilers for embedded systems compile to interpreted code. Spin is different from C in many other ways. For instance, the syntax is quite different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/22/2010 6:35:58 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
More seriously given that to make the most of the propeller you need to code taking into account the hardware is there going to be a massive difference between porting to Spin and changing the C code to match the propeller if native C was supported? Micros applications are never so massive that I would worry about direct code re-usage other than having code that shows me the algorithm I want to code, that is the real work of programming for me anyway.
Graham
There are other cases where it would be better to keep the code in C.· There may be an application that is designed to run on many platforms and processors.· In this case it is better to maintain one set of source code instead of having multiples copies in different languages.
Dave
Dave's translator is doing something good as expected: C in Spin-sized bytes. Of course the source and performance is still Spin. Why no one ever chose Spin byte codes as the output considering Propeller's memory size is beyond me (even reading the excuses provided by the decision makers).
... on to other things ....
If the original topic was just troll-bait, that's too bad. In a free world, everyone has the right to get and filter information as well as ask questions. The original poster led it this way, so it's on topic whether someone likes it or not. Maybe the internet is not such a great idea after all [noparse]:)[/noparse]
My opinions based on participation here over the last two years and enjoying the Propeller since it's introduction are honest and informed. Hopefully the next guy who gets over-excited will have at least some warning against getting too attached to over-extended expectations.
Sharing any ideas here is obviously not useful unless they agree with someone who agrees with almost everyone else [noparse]:)[/noparse] Forums, it seems are not worth the trouble for businesses. At least people here are mostly civil.
If Propeller can not sustain a little criticism, then it's probably less valuable than you think, you are in denial, or you are being dishonest.
There is little difference interpreting LMM PASM/macro instructions and constantly overlay loading PASM to achieve greater than 496 instructions per COG and you know it. It's just something that has to be done to make it more useful than the original design. ... at least it's a possibility and whether it's a good idea or not is up to the end user who may have a lot at stake or not.
Right now, I look at all of this evolving kind of like the punch card business. Punch cards were not very practical after 60 years or so from the 1920's (but that's all we had thanks to the Card Tabulating Machine Company ... IBM), so people came up with good solutions over time and profited from it one way or another (financially, creatively, or otherwise). What you and many of us have done is try to come up with better solutions than punch cards (analogy) for the Propeller to extend its possibilities. Doing interesting things is satisfying.
In retro-spect, I consider much of the enhancements a huge mistake as people reading in due-diligence here now would think that propeller is not attractive for anything other than the constantly promoted other-fitting solutions. People who yearn for Z80 for example may find happiness here, since that is apparently a reasonable solution with Propeller and probably fits with some visions of what embedded or otherwise computing should be. In the meantime the concept of the Propeller architecture is shown to be great ... for a limited set of things.
I hope your entries to the Propeller Popularity Contest do well this year so that all new comers expectations can be properly aligned by the contest announcements and the history of winners. There are some good projects that have come to Propeller, hopefully there will be more.
I have some small projects to complete for the current Propeller and I will do that or maybe use a better fitting micro in the case where there is not enough resources. If Propeller II ever comes, I'll use it because it is an attractive idea. Still I won't hold my breath for Propeller II.
Best of luck to all.
If I can find someone who will write spin bytecode assembler, this should be a fairly easy job. Heck, a real documented on Spin bytecode instruction set, similar to even Parallax assembler code reference, would be sufficient. I can't afford to spend time to turn the disassembled code etc. into a document that I can use.
For now, I am waiting for V2, then make tons of money with ICC for Prop V2, then I can afford to redo ICC for Prop V1 with Spin bytecode.
But food needs to be put on table.
It's good that hobbyists have dayjobs, but this is my dayjob.
// richard
Dave Hein: Is that 2500 lines of C code for JTAG open for inspection? I'd love to compile it for Zog byte codes and see how it compares in size to your C to Spin translated version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You said it yourself - the performance would be SPIN performance. The current C compilers are already between 4 and 8 times faster than SPIN, and many people complain that even this is too slow (which is a complaint I don't really understand - slow compared to what? It's faster than SPIN, and you can't compare it to PASM since you can't even write PASM programs larger than 496 longs without using some kind of LMM - in which case your PASM program would execute at about the same speed as C).
As heater says - if you are satisfied with SPIN speeds, then ZOG may be the right answer.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Just now I'm sure that zog will be slower than Spin byte codes. Until you move to external memory that is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ray
Jazzed: What's up ?
Anyway a little comment on the following statement is in order:
"People who yearn for Z80 for example may find happiness here, since that is apparently a reasonable solution with Propeller and probably fits with some visions of what embedded or otherwise computing should be"
I'd just like to point out that the Z80 emulator and it's predecessor PropAltair are just hobby projects, just for fun.
It all started with PropAltair which was never supposed to be a "serious" project. It was just my first ever attempt at PASM programming for this new fangled chip I had discovered. A learning exercise.
I am surprised and glad that some here have had some fun with them. The whole project has taken on a it's of it's own.
It in no way fits my vision of what embedded or other computing should be. For any serious work I would never start with or recommend ZiCog (or a Z80) (Unless you really do have to run some old Z80 binary blobs for some obscure reason).
It should be clear to everyone, this is just for fun.
Despite my obsession, the Propeller world is much bigger than ZiCog. This forum brings up new and fascinating ideas tackling a huge variety of tasks and applications on an almost daily basis.
Prop II is going to make that world even bigger in ways we probably can't imagine yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I hope not also. But you're right - his post could be read that way. Jazzed? Are you still with us?
@heater,
I did preface my remark with "if you are satisfied with SPIN speeds" ... on that basis I think ZOG still fits in the "totally crazy" category [noparse]:)[/noparse]
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The Propeller II is a great carrot considering how we've all come to enjoy the first Propeller. I just have some projects that need more resources *now* and can't wait an eternity for an open ended promise. This is what I mean by "I won't hold my breath ...."
C compiled to Spin byte code is memory efficient. You know the old saw about performance and memory size being a trade-off in many cases at least. You don't need to add 2K bytes to your program to use it because it is built into prop's ROM just like the character set and the transcendental math tables. When faced with 4 times as fast and won't fit -vs- works great but slow there is little choice.
I really do want to see GNU tools available for Propeller one way or another. If it has to be emulated, I'll just put a bag over it's head and ignore the side effects [noparse];)[/noparse]. Native PASM/LMM would be better for Propeller II of course ... until download times make excuses to take an early lunch [noparse]:)[/noparse].
Now to assemble my newly arrived Xtune PropPad Mini and port 65K color GUI code for it and Rayman's PSM ....
Later.