PICROSS (Formerly STUPICC) PIC Compiler Project
Welcome to the PICROSS PIC compiler project.
(I hope to have news before January 2007...)
|
Well, this project is my humble attempt on writing a C compiler for
Microchip PIC micro processors.
I plan to update this page frequently with any step forward (or backward) of the project development.
The general idea and purpose of this site is to gather people interested on this project.
Why? Good question, some reasons are:
- Since school I'm used to one-man teamwork. Is not school's fault anyway, my teammates
were usually too lazy to work, or too irresponsibles to carry away their part of the job.
I always work alone, but pityfully this is not the way great achievements work and I'm aware
of it. I hope to work side by side with other programmers and interested people in this project.
- I want this compiler to become REALLY useful and a good alternative for PIC programmers
all around the world.
- I also would like to provide a fully documented with tons of sample code and useful libraries
compiler for free.
Well, that's a brief overview of the project roots.
And the name is ...
After some time thinking I came up with STUPICC (STUPICC, The Ultimate PIC Compiler)
Is a funny and recursive acronym. I still need your feedback, what do you think about the name?
suggestions are still welcomed ;)
What about the current state?
'Standard' C features currently implemented:
- fuctions and procedures.
- One-dimensional arrays (with optional string initializer)
- if, else, for, while, break, return statements.
- ==, !=, >, <, >=, <= relational operators.
- +, -, *, /, % Math operators.
- |, & ^, ˜ bit-wise/boolean operators.
- ++, --, +=, -= increment operators.
- >> and << shift operators.
o #include, #define, #pragma preprocessor directives.
Limitations:
- Only one data type: char
- Only numeric constants can be #defined
- No macros.
- No recursion support (Used to have :(. Removed for code's robustness and simplicity sake.)
- Assignments CAN'T be placed as math factors. (i.e: a = b++; is an invalid expression)
PIC-specific and "custom" features:
- #asm preprocessor directive. Used like:
- #asm
bsf STATUS, RP0
clrf PORTB
#endasm
- Nested comments :P
- static variables (i.e: char PORTA @ 0x05 /* forces PORTA to be declared at 0x05 */)
works for arrays too: char array @ 0x0c[10]
- clear_bit(REGISTER, BIT)
- set_bit(REGISTER, BIT)
- get_bit(REGISTER, BIT) function
- loop { ... } Infinite loop.
- asm() In-line asm. Two forms:
- asm {
bsf STATUS, RP0
clrf PORTB
}
- More targets can be defined by using #pragma maxram and #pragma rambase along with
the static (@) variable allocation mentioned above. Currently I've defined headers for 16c84, 16f84
16f83, 16f62x, 16f648a, 12c508, 12c509, 16f873, 16f874,16f876,
16f877.
- sleep() (Posted on 06/27/2004)
Libraries:
10/11/2004
I've been working (in fact, its core is almost finished) on a sort of linker, I don't know if I should call it
a linker, an optimizer or just assembler. Maybe all of them? :P What it does is to read the asm output file,
'assembles' the code in memory, and traces the execution searching for unreachable code, or fragments of code
never called. Once localized, it tries to optimize the code in memory, eliminating unreachable instructions thus
improving the code size. After reorganized the code, will generate the code needed for program-memory pages flipping
before every call or goto (Yes, the code for (program memory) bank switching will be generated at this level, since
after reducing the code, one or more instructions located on a given page will end up 1 or more pages before). Once
done this, it'll probably output the HEX file (current version of the compiler only produces the assembler code.
I use mpasm to produce the hex) thus making a really standalone development system.
I've though on some sort of IDE too. What do you think about it? Will obviously be for DOS, and maybe with a
Windows version (maybe? Is a FACT that if there's no windows-friendly version, half the world wouldn't use it).
So if the IDE does exist, will be for DOS AND Windows. I'll try to port it to linux too (believe me I would really
like to make it ONLY for DOS and linux, but a win-version is almost a modern requirement and porting to three platforms
isn't really an easy task. This is your opportunity to participate, if you REALLY would like to see a linux version (if
the IDE is done of course) send me an email saying so!
10/08/2004
Sorry about the delay, I guess I forgot to update the page. However, I've not passed this time IDLE.
Actually, I've done headers for 12c508, 12c509, 16f873, 16f874, 16f876,
16f877 uPICs and finally wrote
the code needed to handle multiplication and division (8 bit math only). I've added the % (Modulo) operator
too. Since the list of 'theoretically' supported devices is getting large I'm starting to get myself in troubles.
I've NO programming hardware for some devices nor a single way to test the code on such PICs. I really need
some help here, so if you are interested on this project and have the chance to work with any of these devices
and would like to help me, please send me an email.
Ah, I've also done code for automatic bank selection(ABS), so you won't need to worry about setting the memory page
before handling a variable/file. It tries to be smart enough to just change the bit that needs to be changed
It's not as efficient as handwritten, since I would need to trace the code to figure out the current page after a
CALL, branch and such, so I'll probably will include a way to disable the ABS. I've also defined some pragmas to
specify the register and bits that must be set in order to select a bank.
09/27/2004
Header for the 16f83 target added.
7-segment display library.
get_bit() function added.
Configuration Bits support trough #pragma config.
Constant Expression evaluator for #defines and #pragmas. i.e: #define LED_BIT (3+2)*5-20
defines LED_BIT as 5. This way #pragma config can accept things like
#pragma config XT_OSC | CP_OFF.
09/13/2004
Yeah, I'm still alive. I've been working on other projects, thinking about this one too.
Good news? Ints are almost fully implemented (declaration, assignments, parameters passing,
functions, etc).
Bad News? I'll remove them anyway because the implementation left much to be desired, It have
made the code a mess (maze?) and the clarity and simplicity of the compiler has been lost.
Wouter van Ooijen have made it so far with his JAL compiler without adding INT support.
Why should then I add it? experienced programmers can write their own procedures and functions
for dealing with ints, since Integer math must be emulated on 8 bit processors.
I'm waiting for requests, comments, suggestions, ideas, support, or any form of feedback.
I Really NEED your feedback. I don't know what the world expects on a compiler, nor
facilities, features and tools you would like to see with it. I don't even know if this is
a good idea after all....
Anyway, I'll keep building the compiler, trying to add features, optimize, add more targets, etc
BUT without ints.
PS: Now PICNIC turn out to be a good name. PIC No-Integers Compiler hehehehehe.
Just kidding ;)
06/24/2004
Header for 16f648a done.
I just came up with a idea, what about NO-integers and NO other type rather than 'char' BUT with
struct and custom data types support? so I can provide an "intlib" with integer functions
and with a:
typedef struct{
char HI;
char LO;
}INT;
I NEED your opinion about it, probably will be wise (in the meantime) to implement structs first.
06/27/2004
No feedback. I've fixed some things and improved some others a bit. I've also tested code on a real PIC and it
does work properly. Still taking some decisions.
What about code size/quality?
As a quick comparison I've compiled the following example with my compiler, C2C and CC5X:
My Compiler:
#include "16f62x.h"
main(){
char counter;
set_bit(STATUS, RP0);
TRISB = 0;
clear_bit(STATUS, RP0);
loop{
PORTB = 1;
for (counter=0;counter<7;counter++) PORTB<<1;
}
}
|
:1000000001288316003086008312013086000030FC
:10001000A2002208A40007302402FF3003180301C5
:0E002000003803191628A20A860D09280528A3
:02400E00F13F80
:00000001FF
|
The equivalent code in C2C:
main(){
char counter;
set_bit(STATUS, RP0);
TRISB = 0;
clear_bit(STATUS, RP0);
while(1){
PORTB = 1;
for (counter=0;counter<7;counter++) PORTB<<1;
}
}
|
:020000000628D0
:080008000B1109008316831699
:1000100086018312013083128600F10107307102DC
:10002000013003180301003C03190A288312060853
:0C003000F000700DFE39F10A0E280A28BD
:00000001FF
** AND DOESN'T WORK (In jalss simulator at least.) **
|
The same code for cc5x:
#include "16f628.h"
void main(){
char counter;
TRISB = 0;
while (1){
PORTB = 1;
for (counter=0;counter<7;counter++) PORTB = PORTB<<1;
}
}
|
:10000000012883160313860101308312031386002F
:10001000A0010730831203132002031804280310E1
:06002000860DA00A09286C
:00000001FF
|
As you can see, I'm not match for CC5X :P hehehe, but the code is not _THAT_ inefficient,
it compiles without errors and runs according what the program is expected to do.
Ok, so how can I contact you?
All my contact info is in www.damnsoft.org in the "About" section.
I will not reproduce it here since "spambots" uses to scan pages looking for email
addresses to send spam to.