View Full Version : C Compiler Sourceforge project

02-04-2007, 09:57 PM
because of all the requests flying around in a million threads here, I created a project to get this ball rolling:

www.sourceforge.net/projects/propc (http://www.sourceforge.net/projects/propc)

Its awaiting approval from sourceforge staff... should take a few days to a few weeks. then Ill create the CVS repository for it. Meanwhile I'll administer the project and email me (or post here) your snippets, design idea's or anything you want to be made public for this GNU project.


Post Edited (bassmaster) : 2/4/2007 4:03:28 PM GMT

Dennis Ferron
02-05-2007, 12:51 AM
You know I honestly think that C will be around for the next 1000 years. I'm not saying we won't invent better languages in the mean time, in fact I think that interpreted languages are the future of programming, but when you write the core of the interpreter for those languages, guess what? It will be written in C!

It's not that C is as good as it could possibly be, it's just that C does what it does and does it well.

Do you plan to use the large memory model scheme that has been posted in these forums previously, or will each C module have to fit in 512 longs in a cog?

Can you call Spin objects or assembly code inside a Spin object, from a Propeller C program? Can you call C code from inside a Spin program? I think this will be an important point. If I have all these objects already written in Spin, or a combination of Spin and Propeller assembly, I'm only going to use C if I can still use my Spin objects too. When starting a new language, you have a bootstrapping problem - people will only write in it if there are libraries available, but people only make libraries if they write in it. Making the language interoperable with existing software is a great way to get the ball rolling. It's why C++ became popular - you had a lot of people using C, and they found they could use C++ and it worked with all their existing C code too.

I think having a C compiler available will make developers and/or companies that are too "set in their ways" to learn Spin more willing to consider the Propeller. The second question I get asked by people after, "Why does it have a video shift register on every cog?" (Ans: the cogs are all identical) is, "Where's the C compiler?"

02-05-2007, 01:25 AM
Do you plan to use the large memory model scheme that has been posted in these forums previously....
I just am offering to "help" administer/moderate formalize the process as opposed to have a bunch of people trying to do their own version, this will allow us to combine our idea's and features, etc, as well as have a CVS source control repository.

I also will offer some of my time for construction.

Anyone that wants to·post a rought draft proposal together for review and post it that would be great.

Lets also agree on formats:

no word/WP

Keep the UML/sequence diagrams·in·bmp's or pdf for now??


You·have a good question, I think we should start off with a good design discussion before partitioning the project into procedures to be assigned to developers.

If anyone wants to stop this now, or continue to work on our own, its fine, I have found·in my many years in the industry of software development, that combinig resources and having some process will create a much more usefull product, as well as having one that is freely available for all is a plus. If we do not get the ball rolling soon, I suspect someone will write a good one, and charge 200 bucks for a 1 user license, etc, like·a unnamed c compiler for the pic that is for sale at a very high price.


Post Edited (bassmaster) : 2/4/2007 6:38:44 PM GMT

Kevin Wood
02-05-2007, 03:30 AM
I think the best way to do this would be to make the Propeller a target for GCC. It already supports several platforms, so there is a large body of knowledge already out there. It would also allow people to use toolchains already in existence that support GCC, such as Eclipse integration.

I don't know how much I could do with the actual compiler, but if this gets off the ground, I'd be willing to help with the documentation.

One other thing. My suggestion would be to use some form of BSD or similar license. There seems to be a lot of controversy with IP & the GPL, and if there is a compiler available, people will want to use it commercially without open sourcing their code. Just make it easy for them to do so.

However, that would probably rule out GCC.

Post Edited (Kevin Wood) : 2/4/2007 8:39:10 PM GMT

02-05-2007, 04:54 AM
GCC should be ok, that was my plan for the compiler, then windows users could use cygwin.dll etc 1st step would be acompiler command line that ifdef's UNIX etc and outputs .binary, then work on gtk etc for an IDE for X.

Kevin Wood
02-05-2007, 05:37 AM
Do you really want to develop an IDE, instead of using something already available? Either Eclipse or Netbeans should be easier to adapt, rather than build one from scratch.

However, if building one is the goal, and open source is the target, then QT is also a possibility for the GUI. It is available for Windows, Linux, OS-X, and Solaris x86.

02-05-2007, 08:51 AM
The IDE is not really part of this initial endevour. the main goal is the compiler kdeveloper could be used in X or just us wine.

I think you are right, lets focus on the compiler now.

02-05-2007, 01:15 PM
I don't have the technical expertise at all to help (hopefully I will in couple of semesters ;) ) another possible starting point is SDCC, another open source C compiler mainly conceived for embedded devices. Currently it supports Motorola HC something, Intel 8051's and Microchip PIC 16* and 18* devices. Yet another one is SmallC, a subset of C implemented for a lot of MCUs as well.

02-05-2007, 01:32 PM
I'd love to have a C compiler for this... I'm (obviously) going to learn spin, but having a C compiler would definately excite more people that are more stubborn on programming. I don't know nearly enough about this chip or really even porting GCC, but I think GCC would be the best choice since it's very commonly ported and used by so many people. I don't really know all of the limitations of this chip though, so it may not make sense to have a C compiler if the overhead will eat up all of the cog memory. And if the chip interprets spin code efficiently, it may perform better translating the C code to spin code.


Bill Henning
02-05-2007, 02:21 PM
I like Spin, the more I use it, the more I like it as a "quick and dirty" prototyping language


I came up with the large model in order to be able to write large, fast programs - and to make the propeller targetable by C compilers.

Unfortunately I don't have the bandwidth to do porting right now (way too busy until April), however I'd be willing to provide advice (I often take a peek at the forums between builds), some help, and I am going to maintain the "official" large model kernels.

It would be EXTREMELY interesting to do a C compiler that targeted Spin byte codes; frankly thats probably a better first target than large model.

www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

02-05-2007, 07:15 PM
Some way to convert C/Spin into assembly then put them in 512 blocks and use the large memory model to run them?

Learning lots about compilers and parallel cpus, prop is MIMD, and there are C compilers as this is the most common type.
496 long code space is going to be interesting restriction but it could mean small C, which should be easier to port.

Eclipse and GCC port would be multiplatform but that looks at first glance a major job.
I have used Eclipse and it is good when it works, bit of a mess when it does not.
Anyone interested could try the TI MSP430 free 8k compiler to see what it looks and feels like.

The prop is feeling very much like a small DOS box not a single use microcontroller.
More of a general purpose do anything little box that you can run little programs on at the same time.
Mike's OS, Rokicki's SD card, Bill's large memory model and a nice way to drop and drag objects.
This is not a microcontroller this is a single chip computer with Bios in 32k EEPOM.


02-05-2007, 08:34 PM
Bill Henning said...

It would be EXTREMELY interesting to do a C compiler that targeted Spin byte codes; frankly thats probably a better first target than large model.

That is not a bad Idea, c2spin binary, then a "linker" to make the binary all wrapped into propc with command line arguments e.g. -s = output· spin -e ouputs eeprom and -b outputs binary.

It would not be a "real" compiler, but it would allow batch , and allow Kdeveloper scripts to develop in....

Good idea to start....

Post Edited (bassmaster) : 2/5/2007 2:30:47 PM GMT

02-05-2007, 10:28 PM
So to break this down into managable peices, we need to 1st crate the c2spin method, lets start with the basics: breaking it into the managable procedures.

e.g. to convert this simple a blinkoneled.c to blinkoneled.spin·...


#define _clkmode {"xtal1 + pll16x")
#define ·_xinfreq· 500000

#define·High 1
#define·Low 0
#define·Out 1


char Pin;

public void Start(void)· // Do we need a main() ???
··· BlinkingLED();

private void BlinkingLED()
·····int DirA[5];· //typedef in a propc header file??
···· int OutA[5];· //typedef in a propc header file??
···· int i;

···· memset(DirA,0,5);

···· Pin = 7·;

·· {
········ OutA[Pin] = High;··········//LED ON
········ Pause(500);················ //ONE-HALF SECOND WAIT
········ OutA[Pin] = Low;········· //LED OFF
········ Pause(500);
··· }


· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000············

· High = 1························ 'A CONstant used to set an output port to about 3 volts
· Low· = 0························ 'A CONstant used to set an output port to about 0 volts
· Out = %1························ 'A CONstant used to set a port's direction to Out

· Byte Pin························ 'Declares Pin to be a global VARiable of a type Byte

PUB Start
· BlinkingLED
·················································· ·················································· ·······················
PRI BlinkingLED
· Pin := 7
· DirA[Pin] := Out
· Repeat 5
········ OutA[Pin] := High········ 'LED ON·····································
········ WaitCnt(40_000_000 + Cnt) 'ONE-HALF SECOND WAIT
········ OutA[Pin] := Low········· 'LED OFF
········ WaitCnt(40_000_000 + Cnt) 'ONE-HALF SECOND WAIT


1: We need a parseDefs(xxx)·i.e. xxx = VAR·, It will look through the whole C·file for·definitions then convert to·write to the·spin·output·file pointer for later write.

······· These three CON, VAR, DAT, and are easy!

2. We need a parseMethods() and int getnextmethodPtr(filename) parseMethod(routinename);
········ It will look through the whole file for·methods (PUB , PRI) ·then convert to·the spin·output·file pointer for later write. e.g

······· int i;

······· i = getnextmethodPtr(filename);

········do while ( i) != -1 // e.g. here i = ptr to (void Start(void) { blinkingled(); }

PUB Start
· BlinkingLED

········ This one is more complex, but not so bad. It will require it to be broken down into subroutines:
··························· 1. convertFor()·· (makes a repeat) Uses ConvertIf()
····························2. convertWhile() Uses ConvertIf() (Simple)
··························· 3. convertCaseSwitch() Uses ConvertIf() (Simple)
··························· 4. convertIf()·· (Simple)
··························· 5. convertSyntax()·i.e· = to := and 5000000 to 5_000_000 ??? (maybeP)
····························8. convertPause()· ·makes Pause(500); = ·(WaitCnt(40_000_000 + Cnt) (I think waitcnt(clkfreq/500+cnt) is better)
··························· 9. convertCalls() e.g blinkingled(): gets converted to 0x12 "blinkingled" 0x13 and writen to the next line.

·Anyway this is a quick idea, I am sure there are better idea's and a few typo's.·······

Post Edited (bassmaster) : 2/5/2007 4:38:04 PM GMT

02-06-2007, 08:21 PM
From what I have gathered so far even assembly needs a bit of spin to start it.
This little bit of spin would be the "main"
Replacing curly brackets with indenting should not be too hard.
Looks fairly simple but then I know next to nothing about parsing:)

The registers would be macro defines and won't change.
From my limited experience Spin looks better than C anyway, mainly because it is so close to the asembly syntax.

I still don't know enough about this beast, wonder if I could find someone to pay me to learn it:)


02-06-2007, 09:04 PM
the c syntax parser methods already exist in tinyc or GCC etc. , thats the first step of the compiler actually, then error with desciptive text of the problem, I.E unititialized variable on line XXX.

02-07-2007, 03:17 PM
The project on SourceForge is still showing up as an invalid project. Is that just because we don't have anything up there yet?


02-07-2007, 07:59 PM
it is "Queued for Proccessing" status now, should be a few more days...

meanwhile, I need developers to start writing the simple routines listed above (names may be modified) ·that we will add to CVS when the project is approved:

If you want to contribute, assign yourself one and post that you are working on it and your expected due date. so we do not have more than one developer working on the same thing.

I expect a UML use case· / Sequence diagrams for each method. Unit test it also.

And we will need some volenteer Guineu (SP) pigs for QA. and eventually QC.


Post Edited (bassmaster) : 2/7/2007 1:06:37 PM GMT

02-09-2007, 02:51 AM
Its approved and up...


02-10-2007, 04:23 AM
Nice. I really like the energy you have and am eager to see it's fruition. But why C? Why not at least c++ or better yet c# where you can managed code and avoid dll hell?


02-10-2007, 05:07 AM
C#, dll's? This is a microcontroller with a very limited amount of memory... I can't imagine anything like that on here. C is very powerful and definately well suited for a limited architecture like this where everything can be translated into efficient assembly code. C++ may be possible, but from what I've seen, I think the system might even be too limited for classes (at least anything that'd benefit from being a class). Everything C++ does can be done in C with a little effort, and probably more efficiently since it'd probably be written with a special purpose in mind (I can't think of the last time I wrote anything for an embedded system that I really wished I had anything better than C... typically I'm wanting to rewrite a lot of it in ASM). Anyway, C is definately the simplest of those, and IMO where the effort should be put first... extra stuff like C++ features could be added to the standard C compiler later if desired.


02-10-2007, 05:24 AM
I have to admit, I've been using a subset-of-C to Spin convertor to write my fat16 and the initial Basic interpreter.
I do this so I can develop and debug under linux.

On the other hand, the code I have is impossibly ugly and I highly recommend people stay away from it.

If you are curious however, you can look at:

http://tomas.rokicki.com/fat16work/fsrw.c --- the C language version of the FAT16 support

http://tomas.rokicki.com/fat16work/fsrw.spin --- the Spin version, automatically generated from the above

http://tomas.rokicki.com/fat16work/ctospin.pl --- the Perl script that does the translation.

I must emphasize: this code is *specific* to this project, not at all general, and not intended to be.
It's also not intended to be generic, or documented, or anything else. So examine at your own risk.

02-10-2007, 05:38 AM
Wow... that perl script has so much regex in it my head is going to explode. Amazing how you managed to do that conversion in a relatively short (but what seems to be complex) program.

02-10-2007, 08:58 AM
there is no dll hell with ansi c, yea go to c# then you have framework hell

02-10-2007, 08:55 PM
rokicki, nice start!

02-11-2007, 12:43 AM
Actually, I'd recommend people *not* approach it the way I have, with regexp.
It's possible to get it to work, but it would be very unreadable and unwieldy.
Better to do it "right" with a real lexer and parser.

02-12-2007, 02:52 AM