Phil,
this is a fascinating topic: The "Perfect Beginner's Programming Language" .....Memories from 1968: Nikolaus Wirth leaves the IFIP WG 2.1 as he thinks they are totally wrong with Algol68, and invents something similar for his students The "Beginner's Language" was BASIC at that time, "B" as "Beginner"...
I generally agree with your ratings above, "dynamic" things need not be so expensive as to leave them out, although safety critical applications frown upon them.... Indeed there are many not so widely known implementations of such functions in SPIN (string handling, heap managament,...), but as they are not part of the language they are easily put aside...
My two other concerns are: data structures and functional constructs. I am totally unhappy with the non-existence of any data structure in SPIN and the impossibility to use these so-called "objects" efficiently as a substitution for it. As we both know Perl well, we might center a little bit around the "hash", this being the most useful and practical "datastructure" ever, dynamic, and flexible enough to even emulate objects! Many other languages have adapted that feature for its merrits (e.g. Python, JavaScript). But any static recursive datastructure ala Pascal would have sufficed.
A beginner's language must have a datastructure concept - either the static "classical", or a dynamic "hash" based!
Functional constructs (e.g. grep, map, ...) are a matter of an advanced compiler. The code needed is always serialized, and maybe the simple minded user looses the relation to it's amount and the run time needed. Some tests I did woth Python many years ago showed that it was in fact faster to avoid those constructs...
However they are important building blocks to write more understandable prgrams...
My point however was NOT the Beginner's Language. My point was: Given the constraints I have it is NOT possible to teach a (new or old) language at the same time as teaching (micro) electronics. It is possible to write books that pretend they do this, but this does not work in a scheduled class!
First a little bit of the language, then a little bit of electronics, then apply this to the microcontroller.
Then a little bit more of the language, then a little bit more of electronics, then apply this to the microcontroller.
Then the rest of the language and all its idiosyncrasies.
Then the Assemply language on top.
This will take YEARS.
I need the students to have a "working" knowledge of a language I can utilize immediately. Or if not I have to give them a pointer how to accomplish that (and it's not "Read Chapter 3 of the Manual!" This had not worked, alas) and come back later. C is perfect for this.
Although it might be a bad language, well it most like is a bad language....
I just wanted to offer encouragement to Richard and Imagecraft.
I am not an " educator", just an old guy who develops real embedded products which sell in their thousands.
I spent 5 years writing PIC assembler for a company over a decade ago, and when C compilers finally arrived for the PIC, I breathed a big sigh of relief.
I had to learn C, but it is a "standard" language, and thus has the momentum and volume of programmers and sample functions etc..
I have the imagecraft C compiler for the ARM.
I am excited by Imagecraft's work on propeller, and it will finally make me buy and check out the propeller after just keeping a watching brief for 9 months or so.
question, is it possible to make object modules of C, SPIN, and assembly, and them link them to form the runtime?
deSilva said...
@Beanie
Your concept of "delay" is most inappropriate for this kind of usage. That is why WAITCNT had been invented...
However there are situations where you have to couple events of different "kind", i.e. setting a line a specific time after reading another line:
WAITPEQ()
time := CNT
WAITCNT(time+delay-calib)
OUTA |= XXX
This has to be calibrated by around 600 ticks. This is best determined by using a 'scope
Well the C compilers I have used usually have a delay() function in their library (although with some cheap compilers I have had to create my own). I have not seen any compiler with a waitcnt() function. (I think that is a Spin function?) In any case the code was just a quick and dirty to illustrate my concern about deterministic timing.
@Beanie: When it comes to EXACT timing be it in C or whatever language, there is ALWAYS either interrupts or specific hardware actions. But in heavily loaded systems also interrupt driven activities can show a "jitter". This is the beauty of the Propeller that you have no such effect, when you have a COG to spare and doing it in PASM. As far as I can remember one of Chip's arguments against optimzing SPIN code was that the reliability of hand-tuned loops in SPIN would go lost; one example of that being your delay-example.
One thing I wonder about is some details about how the concurrency of the prop will be handled. What operations will be guaranteed to be atomic? The same ones that Spin does?
<I>I'm sure there are others, but these are the first that come to mind. I've yet to see an "ideal" beginner's language.</I>
Let me score Python.
1) ++Python. No prior declarations required. Garbage collected.
2) ++Python. Variables are not typed, other than by implication of what you assign to them.
3) ++Python. If X is a sequence (an arbitrary sized array or a string), then "for y in x" will loop once for each item in x, and you don't bneed to dereference it with a loop index.
4) ++Python. There is no goto statement. Structured and/or OOP can be used interchangably.
5) ++Python. There are only functions. When they appear as part of a class people call them methods, but the language syntax is the same either way.
6) ++python. You always use "print". Does fancy formatting or not depending on the parameters.
It's always hard to think of anything as "ideal", but if I was teaching programming, I'd use python. But it's not the thing for embedded programming.
If people want to continue to discuss what type of language would be suited for the Propeller, please start a new thread. Let's leave this one for ImageCraft and any questions people may have about the compiler.
acantostega said...
One thing I wonder about is some details about how the concurrency of the prop will be handled. What operations will be guaranteed to be atomic? The same ones that Spin does?
There doesn't seem to be that much to me which is guaranteed to be 'atomic' in Spin. Just the CogInit, CogNew and the Lock commands. As it is the ultimate execution of a PASM instruction within the Spin Interpreter which makes those atomic I would expect the C compiler to be exactly the same. There may be some operations within C which use Lock or software semaphores to make them atomic.
deSilva said...
@Beanie: When it comes to EXACT timing be it in C or whatever language, there is ALWAYS either interrupts or specific hardware actions. But in heavily loaded systems also interrupt driven activities can show a "jitter". This is the beauty of the Propeller that you have no such effect, when you have a COG to spare and doing it in PASM. As far as I can remember one of Chip's arguments against optimzing SPIN code was that the reliability of hand-tuned loops in SPIN would go lost; one example of that being your delay-example.
Yup. Which is why I chose the Propeller for this project instead of a more familiar (to me) 8051 variant. The Prop reminds me of an FPGA in that several concurrent processes can be run independent of each other. However unlike an FPGA the Prop does not require a second mortgage on the house to buy the software development tools.
And we all have (still unanswered) questions of just that kind (and many more):
said...
... is it possible to make object modules of C, SPIN, and assembly, and them link them to form the runtime?
Thanks.
re: linking: you can definitely link asm modules, although currently our asm's syntax is slightly different from Parallax's. If nothing else, there's relocation to think about. We will not be able to take in Parallax generated object files from their assembler (do they even generate object files?). So you will have to do some (minor) conversion of the PASM source code.
SPIN is going to be difficult. We will have to somehow interface to the SPIN interpreter and make sure they don't trash our LMM kernel. At best, I can see running SPIN objects in another COG eventually but it definitely will not make in any release One. Of course, if the C compiler is as popular as I hope it will be, the hope is that we will get support from the community (and of course we will support the community as much as possible) such that most SPIN usable objects will also be available in C linkable form.
and I would imagine that existing C library code will be ported to Propeller C, e.g. TCP/IP stack etc.
There is "only one pasm" for the propeller. Please do not change it any way or I will have to maintain two files for every pasm routine I write so that I can operate in the Parallax world and also in the ImageCraft world. In the end the bookkepping will be two much and I will scrap ImageCraft C.
ImageCraft and Parallax appear to have a good relationship so if the PASM syntax needs to change in some small way to work with C it is possible that those changes could be incorporated in the Propeller Tool. That should solve most problems; existing PASM works, C-PASM works as well.
Or perhaps a simple tool to convert between the two would suffice.
deSilva said...
@Beanie: When it comes to EXACT timing be it in C or whatever language, there is ALWAYS either interrupts or specific hardware actions. But in heavily loaded systems also interrupt driven activities can show a "jitter". This is the beauty of the Propeller that you have no such effect, when you have a COG to spare and doing it in PASM. As far as I can remember one of Chip's arguments against optimzing SPIN code was that the reliability of hand-tuned loops in SPIN would go lost; one example of that being your delay-example.
Yup. Which is why I chose the Propeller for this project instead of a more familiar (to me) 8051 variant. The Prop reminds me of an FPGA in that several concurrent processes can be run independent of each other. However unlike an FPGA the Prop does not require a second mortgage on the house to buy the software development tools.
Xilinx WebPack and Altera Quartus Web Edition tools are free! Excellent evaluation kits are available very cheaply, like the Xilinx/Digilent Spartan 3 Starter Kit at $99.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Here are some info re: assembler from the dev team:
1. Assembler reads the assembly file(.s) and generates the ELF object file(.o).
2. Complete Instruction set as per propellar manual except ORG and FIT.
3. ICC Directives - .area, .byte, .word, .long, .align, .blkb, .blkw
4. Sections:
.area text - text section where the code resides
.area data - data section
.area lit - literal tables
.area bss - uninitialized data section
5. Relocatable sections
user defined areas
****
The ELF object file contains debug information, to be used later by a debugger. As you can see, the directives and sections are needed by the C compiler to ... support C. I hope this addresses the question why we can't just use PASM syntax 100%
// richard
Post Edited (ImageCraft) : 3/4/2008 12:53:30 PM GMT
> So Nick is already out; and it's really close between Beanie and deSilva
Pffff! I was talking about the beta.
Anyhow, I can well live with a different syntax for ASM. Preferably if the ImageCraft assembler fails with Parallax-syntax (and doesn't generate unwanted code).
Happyly awaiting #define etc.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
you originally said " I think this was more of a notification to everyone that pcc (are we allowed to call it that?) is coming soon, not a call for testers..."
my point of
"what made you assume I thought it was a call for testers ?"
is that I didnt think for one moment it was a call for beta testers.
just because i ask to be one, doesnt mean I thought that imagecraft's post WAS a call for testers.
I was slightly annoyed that you even posted your "objection" to me politely asking the question to Imagecraft.
I'm fascinated by the amount and content of chatter your postings create [noparse]:)[/noparse]
I eagerly await some Propeller C tools release; hope yours goes smoothly.
Your other tool sets appear to have shell executable compiler, assembler, and linker.
Will this also be the case for Propeller? Are there linux distribution variants of the tools?
What about your debugger ? Is it IDE only or can it be driven via gdb ?
Would u/COS-II or Salvo RTOS be supported from beginning ?
Comments
this is a fascinating topic: The "Perfect Beginner's Programming Language" .....Memories from 1968: Nikolaus Wirth leaves the IFIP WG 2.1 as he thinks they are totally wrong with Algol68, and invents something similar for his students
I generally agree with your ratings above, "dynamic" things need not be so expensive as to leave them out, although safety critical applications frown upon them.... Indeed there are many not so widely known implementations of such functions in SPIN (string handling, heap managament,...), but as they are not part of the language they are easily put aside...
My two other concerns are: data structures and functional constructs. I am totally unhappy with the non-existence of any data structure in SPIN and the impossibility to use these so-called "objects" efficiently as a substitution for it. As we both know Perl well, we might center a little bit around the "hash", this being the most useful and practical "datastructure" ever, dynamic, and flexible enough to even emulate objects! Many other languages have adapted that feature for its merrits (e.g. Python, JavaScript). But any static recursive datastructure ala Pascal would have sufficed.
A beginner's language must have a datastructure concept - either the static "classical", or a dynamic "hash" based!
Functional constructs (e.g. grep, map, ...) are a matter of an advanced compiler. The code needed is always serialized, and maybe the simple minded user looses the relation to it's amount and the run time needed. Some tests I did woth Python many years ago showed that it was in fact faster to avoid those constructs...
However they are important building blocks to write more understandable prgrams...
My point however was NOT the Beginner's Language. My point was: Given the constraints I have it is NOT possible to teach a (new or old) language at the same time as teaching (micro) electronics. It is possible to write books that pretend they do this, but this does not work in a scheduled class!
First a little bit of the language, then a little bit of electronics, then apply this to the microcontroller.
Then a little bit more of the language, then a little bit more of electronics, then apply this to the microcontroller.
Then the rest of the language and all its idiosyncrasies.
Then the Assemply language on top.
This will take YEARS.
I need the students to have a "working" knowledge of a language I can utilize immediately. Or if not I have to give them a pointer how to accomplish that (and it's not "Read Chapter 3 of the Manual!" This had not worked, alas) and come back later. C is perfect for this.
Although it might be a bad language, well it most like is a bad language....
Post Edited (deSilva) : 3/3/2008 7:42:46 AM GMT
Your concept of "delay" is most inappropriate for this kind of usage. That is why WAITCNT had been invented...
However there are situations where you have to couple events of different "kind", i.e. setting a line a specific time after reading another line:
This has to be calibrated by around 600 ticks. This is best determined by using a 'scope
I am not an " educator", just an old guy who develops real embedded products which sell in their thousands.
I spent 5 years writing PIC assembler for a company over a decade ago, and when C compilers finally arrived for the PIC, I breathed a big sigh of relief.
I had to learn C, but it is a "standard" language, and thus has the momentum and volume of programmers and sample functions etc..
I have the imagecraft C compiler for the ARM.
I am excited by Imagecraft's work on propeller, and it will finally make me buy and check out the propeller after just keeping a watching brief for 9 months or so.
question, is it possible to make object modules of C, SPIN, and assembly, and them link them to form the runtime?
Mike
Well the C compilers I have used usually have a delay() function in their library (although with some cheap compilers I have had to create my own). I have not seen any compiler with a waitcnt() function. (I think that is a Spin function?) In any case the code was just a quick and dirty to illustrate my concern about deterministic timing.
The system counter in the Propeller ticks once every cycle. That instruction pauses COG program execution until a specified value is matched.
That counter is global to all COGS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
And we all have (still unanswered) questions of just that kind (and many more):
Let me score Python.
1) ++Python. No prior declarations required. Garbage collected.
2) ++Python. Variables are not typed, other than by implication of what you assign to them.
3) ++Python. If X is a sequence (an arbitrary sized array or a string), then "for y in x" will loop once for each item in x, and you don't bneed to dereference it with a loop index.
4) ++Python. There is no goto statement. Structured and/or OOP can be used interchangably.
5) ++Python. There are only functions. When they appear as part of a class people call them methods, but the language syntax is the same either way.
6) ++python. You always use "print". Does fancy formatting or not depending on the parameters.
It's always hard to think of anything as "ideal", but if I was teaching programming, I'd use python. But it's not the thing for embedded programming.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
There doesn't seem to be that much to me which is guaranteed to be 'atomic' in Spin. Just the CogInit, CogNew and the Lock commands. As it is the ultimate execution of a PASM instruction within the Spin Interpreter which makes those atomic I would expect the C compiler to be exactly the same. There may be some operations within C which use Lock or software semaphores to make them atomic.
Yup. Which is why I chose the Propeller for this project instead of a more familiar (to me) 8051 variant. The Prop reminds me of an FPGA in that several concurrent processes can be run independent of each other. However unlike an FPGA the Prop does not require a second mortgage on the house to buy the software development tools.
Thanks.
re: linking: you can definitely link asm modules, although currently our asm's syntax is slightly different from Parallax's. If nothing else, there's relocation to think about. We will not be able to take in Parallax generated object files from their assembler (do they even generate object files?). So you will have to do some (minor) conversion of the PASM source code.
SPIN is going to be difficult. We will have to somehow interface to the SPIN interpreter and make sure they don't trash our LMM kernel. At best, I can see running SPIN objects in another COG eventually but it definitely will not make in any release One. Of course, if the C compiler is as popular as I hope it will be, the hope is that we will get support from the community (and of course we will support the community as much as possible) such that most SPIN usable objects will also be available in C linkable form.
and I would imagine that existing C library code will be ported to Propeller C, e.g. TCP/IP stack etc.
There is "only one pasm" for the propeller. Please do not change it any way or I will have to maintain two files for every pasm routine I write so that I can operate in the Parallax world and also in the ImageCraft world. In the end the bookkepping will be two much and I will scrap ImageCraft C.
Jim
Or perhaps a simple tool to convert between the two would suffice.
please can I be a beta tester.
Mike
i think this was more of a notification to everyone that pcc (are we allowed to call it that?) is coming soon, not a call for testers...
am I not allowed express my strong interest ?
I take exception to your post
Xilinx WebPack and Altera Quartus Web Edition tools are free! Excellent evaluation kits are available very cheaply, like the Xilinx/Digilent Spartan 3 Starter Kit at $99.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Here are some info re: assembler from the dev team:
1. Assembler reads the assembly file(.s) and generates the ELF object file(.o).
2. Complete Instruction set as per propellar manual except ORG and FIT.
3. ICC Directives - .area, .byte, .word, .long, .align, .blkb, .blkw
4. Sections:
.area text - text section where the code resides
.area data - data section
.area lit - literal tables
.area bss - uninitialized data section
5. Relocatable sections
user defined areas
****
The ELF object file contains debug information, to be used later by a debugger. As you can see, the directives and sections are needed by the C compiler to ... support C. I hope this addresses the question why we can't just use PASM syntax 100%
// richard
Post Edited (ImageCraft) : 3/4/2008 12:53:30 PM GMT
Ok, you win. I will still contribute to your trip to Tahiti. Good luck with the completion of your development.
Jim
Stay tuned.
deSilva: Easter = March 23rd; fibo(29) = 10 sec
Beanie2K: April 1st; fibo(29) = 15 sec
NickMueller: Feb 27th; fibo(29) = 13 sec
So Nick is already out; and it's really close between Beanie and deSilva
After re-reading your post I have found this evidence:
Theres a thumbs down button next to my posts, press it to concede defeat.
Pffff! I was talking about the beta.
Anyhow, I can well live with a different syntax for ASM. Preferably if the ImageCraft assembler fails with Parallax-syntax (and doesn't generate unwanted code).
Happyly awaiting #define etc.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
you originally said " I think this was more of a notification to everyone that pcc (are we allowed to call it that?) is coming soon, not a call for testers..."
my point of
"what made you assume I thought it was a call for testers ?"
is that I didnt think for one moment it was a call for beta testers.
just because i ask to be one, doesnt mean I thought that imagecraft's post WAS a call for testers.
I was slightly annoyed that you even posted your "objection" to me politely asking the question to Imagecraft.
Mike
And just for the record, neither deSilva nor Beanie2K pay me to make Nick lose
March has 31 day right? What if I release it right in the middle?
BTW, I am 100% sure that we can do much better than 10 secs for the required function. You just have to write it in optimized C:
main()
{
int i = fibo_29();
}
int fibo_29()
{
return 514229;
}
But now we have a first upper bound estimation: THAT piece of C will at least run < 10 s....
I eagerly await some Propeller C tools release; hope yours goes smoothly.
Your other tool sets appear to have shell executable compiler, assembler, and linker.
Will this also be the case for Propeller? Are there linux distribution variants of the tools?
What about your debugger ? Is it IDE only or can it be driven via gdb ?
Would u/COS-II or Salvo RTOS be supported from beginning ?
TIA ... in your backyard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)