C Compiler available shortly
scotta
Posts: 168
How many of you would be interested in purchasing a C compiler/interpretor for the propeller ?
The package consists of a true Recursive Descent Compiler for the C language,
available for Windows, Linux, and, shortly, the Mac. The interpretor is written
in assembler, specifically for the Parallax Propeller. The programs are compact,
and execute immediately after the processor is powered up.
The combination is fantastic:
The current chip executes 120,000 C language expressions per second, PER COG .
The next chip (some months away...) should do 1 million/COG.
Supported commands: for,while,repeat,do,until,if,else if,else, goto, function calls
Parameters supported: multi-level function calls with multiple parameters and return value.
Preprocessor-directives: Simple commands like #DEFINE are supported, recursive parsing of defines' in the works
Currently supported operators (in order of precedence):
Postfix Add/Sub a++
Function
Prefix Add/Sub ++a
Logical Not !
Binary Not ~
Multiply *
Divide /
Modulus %
Add +
Subtract -
Shl <<
Shr >>
<
>
<=
>=
!=
==
Bitwise And &
Bitwise XOR ^
Bitwise OR |
Logical AND &&
Logical OR ||
Assignment y=((m*x)+b) * c /5
Sincerely,
Scott Alcock
Essay Software, LLC
EssaySoftware@gmail.com
The package consists of a true Recursive Descent Compiler for the C language,
available for Windows, Linux, and, shortly, the Mac. The interpretor is written
in assembler, specifically for the Parallax Propeller. The programs are compact,
and execute immediately after the processor is powered up.
The combination is fantastic:
The current chip executes 120,000 C language expressions per second, PER COG .
The next chip (some months away...) should do 1 million/COG.
Supported commands: for,while,repeat,do,until,if,else if,else, goto, function calls
Parameters supported: multi-level function calls with multiple parameters and return value.
Preprocessor-directives: Simple commands like #DEFINE are supported, recursive parsing of defines' in the works
Currently supported operators (in order of precedence):
Postfix Add/Sub a++
Function
Prefix Add/Sub ++a
Logical Not !
Binary Not ~
Multiply *
Divide /
Modulus %
Add +
Subtract -
Shl <<
Shr >>
<
>
<=
>=
!=
==
Bitwise And &
Bitwise XOR ^
Bitwise OR |
Logical AND &&
Logical OR ||
Assignment y=((m*x)+b) * c /5
Sincerely,
Scott Alcock
Essay Software, LLC
EssaySoftware@gmail.com
Comments
Its ready for beta testers.
Sincerely,
Scott Alcock
Essay Software, LLC
EssaySoftware@gmail.com
If I were a 'C' person, I'd join in!
Sounds very interesting.
I'm also glad to see linux support! [noparse]:)[/noparse]
Thanks Scott.
C was something I always wished for on the Prop.
--Andrew Arsenault.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
But if it is in the right range. YES
<www.essay-software.com>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
will be posted on Essay-Software.com after the
beta.
Send an email if you wish to be on the beta.
Sincerely,
Scott Alcock
Essay Software, LLC
EssaySoftware@gmail.com
Does it generate normal (small model) cog assembly?
Does does it generate Bill Henning's large model code or some kind of P-code?
----
The Code Cowboy
How much we talking here?
Is there a beta discount?
A C-based "Cog New" is in the prototype area. If we add one level of
precedence to the compiler, we end up at the 'object-thread' level. This
level contains the code-space, and the execution space (I.E. C-code
running on a cog). The object-thread level is where we intend on injecting
assembler source/object code.
cowboy3398,
It, right now, is somewhere between the "Large Memory Model" and Pseudo-Code. The
stack itself can reside in either local (cog based) or global (32K) memory. It seems there
is nothing to be had at compiling to the cog level, not until the cog memory space
exceeds a few Kb.
Rayman,
The existing video drivers are completely portable (minor wrapper changes), when
we release the object-thread precedence. See the "Nick Mueller" section of this post.
Sincerely,
Scott Alcock
Essay Software, LLC
EssaySoftware@gmail.com
JT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
It depends on price of course and also how much of a memory footprint the p-code interpreter has.
I have been hesitant to post to this thread, as your initial advertisement lacked any indication of professionality...
Phrases like "120,000 C language expressions per second", or lists of supported operators are - lets say - particular.
I should expect performance statements wrt acknowledged benchmarks and compliance statement wrt C-standard, subsets or waivers if applicable.... Compile time for larger programs (e.g. 30kb code generated) is interesting to know as well...
It it not so tricky to develop a "recursive descent compiler" for a C-subset using the appropriate tools or languages. This is a standard homework for computer science graduates...
A "C -instruction" per 8 µs is quite close to SPIN performance...
Don't be too hard on the guy. It sounds like we will have an abundance of C compilers this season, one for the Large Memory Model and one for another virtual machine more comparable to Spin's. I'm sure ImageCraft's will be done up in a very professional manner. This one may or may not be as professional and probably will have a less professional cost. It's expensive to do the benchmark and compliance testing properly and, if included, should add significantly to the cost. It's not so tricky to do a recursive descent compiler for C, but it's still a huge amount of work, not something for a holiday project and it would still be a significant effort for a term project.
It is mainly that I do not have a good feeling with it from the start...
The more compilers/support we have, the better, even at professional prices. As a hobbyst, I'd prefer lower ones
Is anyone likely to port this though?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
avr.c 140 kbytes
avr.h
avr.md 80 kbytes
libgcc.S
those are basically, and some others for inclusion in the gcc itself.
But, we have to have a working LMM and asm compiler. (i'm working on that).
No, not me. I've sent him an eMail that I'd like to test the compiler, but didn't get any answer.
Imagecraft's C shouldn't be that far away ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
There are two absolutely unknows parameters to bet on:
* First download of First Beta (for free, I hope )
-> deSilva's guess: around Easter (which is early this year)
* The run time performance. We can choose one of the proposed Benchmarks in the other thread (i.e. computung fibo(29) recursively) Measurements by deSilva were
- 26 sec with SPIN
- 800 ms handcoded PASM
http://forums.parallax.com/showthread.php?p=601870 - near the end
This is a very PASM unfriendly benchmark!
-> deSilva's hope: Imagecraft C will do it in 10 seconds!
Post Edited (deSilva) : 1/6/2008 1:29:21 PM GMT
OK, my guess is:
1st Beta - April 1, 2008
fibo(29) benchmark: 15 seconds
@deSilva : Yes, recursive fibo(29) is PASM unfriendly; my own PASM attempt took 1.8 seconds, over twice as long as yours. Well done with your coding there.
Speed is 2.1 times faster than Spin.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Nick
"Real Soon Now"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO