User's suggestions TODO list - roybaer/sdcc-wiki GitHub Wiki

  • support to pic 16F631
  • Make FULL use of R0~R7 when pass parameters on MCS51
  • sdcc being able to or being base to compile: ansi-basic (very needed, due the lack of good z80 ansi-basic compilers), python, perl, pascal, etc.
  • support to pic12f683
  • support pic18f8772
  • support PIC18F6390
  • support PIC18F4550 - very common and versatile PIC for boards with USB [DONE]
  • Fix the code-generation bugs: The bugs where sdcc generates wrong code for correct C programs.
  • for the 8051 family, it should be nice to know the address of a declared bit ( &bit )
  • Make sdcc an ANSI C compiler. (comment - I wonder whether this is such a good idea. Many components of the ANSI standard are just plain bad ideas for embedded systems. Mostly these are implementation constraints rather than language features. I assume ISO has the same issues, but I haven't studied that extensively)
  • Make sdcc an ISO C99 compiler.
  • Support more recent 18F's. The 18F libraries are compiled for a part that no longer is available. stack.S presumes memory where not all 18F's have memory. I/O presumes MSSP which isn't available on all parts. As a minimum, at least document the workarounds.
  • PIC16 port - compiler should be willing to use access RAM for udata when available and other RAM exhausted.
  • PIC16 port - even with --obanksel=2 the compiler still emits a large number of unnecessary banksels
  • PIC16 port - RAM buffers larger than 256 ( char buf[512] )
  • documentation with example code/tutorial for beginners (I'm interested in pic and atmel processor)
  • port SDCC to the Parallax Propeller (See http://propeller.wikispaces.com/Programming+in+C ). (I'm not sure this makes sense. SDCC seems to be aimed at 8-bit CPUs; perhaps some other retargetable compiler would be more appropriate for the 32-bit Propeller).
  • Cypress PSoC M8C port - is CY8C29466 a good first target? A little discussion at http://www.psocdeveloper.com/forums/viewtopic.php?f=3&t=5417 . Can we use the simulator at http://m8cutils.sourceforge.net/ for testing this port?
  • Are there any good ideas in RCSC that can make SDCC even better? Andy Yuen ported RCSC to the 8051 in 1997(!). See "Retargetable Concurrent Small C" by Andy Yuen 1997 and "Concurrent Small C" by Andy Yuen 1996 http://www.ddj.com/184410255 http://www.ddj.com/architect/184409938
  • "CPIK (the C compiler for PIC18 devices) is now released under GPL licence." by Alain Gibaud. Are there any good ideas in CPIK that can make SDCC even better? Is there anything the SDCC project can do to make CPIK even better? Would it save effort to write a single device-specific library that works with both CPIK and SDCC -- for example, a library for sending and receiving RS485 on a PIC18F2553 -- rather than maintaining two slightly-different libraries in parallel?

Table of Contents

integrated development environment

Currently http://en.wikipedia.org/wiki/8051_compiler claims that "SDCC ... lacks integrated development environment".

However, I've heard rumors that several integrated development environments (IDEs) work fine with sdcc.

Dear reader, would you mind picking any one of the following IDEs marked "untested", testing to see if it really does work with SDCC, and change it to "works" or "doesn't work" ?

External memory

External RAM

When my compiler complains that it has run out of RAM, I fantasize about an option something like this: 

  "--use-slow-external-serial-RAM"::
  Use slow, external, serial RAM for variables, rather than internal RAM.

External constants

When my compiler complains that it has run out of program memory, I fantasize about an option something like this: 

 "--use-slow-external-serial-flash-for-constants"::
 Use slow, external, serial Flash (or other EEPROM) for constants, rather than internal program memory.

I would be happy if such an option used used the simplest implementation: program memory reserved for things that absolutely must be in program memory: executable code. Everything else goes into external memory: variable initialization constants, font tables, detailed error-description "debug" strings, etc.

(That's much simpler than trying to decide:

  • which constants are kept in internal program memory,
  • which are pushed out to external memory, and
  • (yet another potential source of obscure bugs) which constants are stored in external memory, but are temporarily cached in internal RAM during one function, and later that same location in RAM is re-used to cache a completely different constant during some other function.
)

Is there a better place for complex suggestions like this?

⚠️ **GitHub.com Fallback** ⚠️