On Fri, Dec 20, 2013 at 6:49 PM, Masur Jonathan <jmasur@bluewin.ch> wrote:
Sorry if what I'm asking is dumb.

I'd like to get started helping to develop SDCC. However the first thing
is that I should understand as well as possible how its internal works.
I downloaded the sources and managed to compile them just fine, however
I'd like to know how I can find documentation about the internal
workings of the compiler at a high level but still detailed enough
(thigns like there's a front end, an ICode representation and a Back end
is not detailed enough). The code itself isn't quite self-explanatory
when it comes for the high level thing.

Where can I look at the feature requests and bugs list Philip mentioned ?

As for the features Philip mentioned, many are platform specific to
platforms I'm not familiar with so I can't take these. I'd be willing to
add/improve/fix anything that is not platform specific though.

As for Phillip's suggestions :

Variables length arrays are nice, but clearly made for systems which
creates arrays on their execution stacks. I believe that this is not the
case of the majority of SDCC targets, so it'll simply not be technically

Functions that takes structs and unions and return structs and unions
could be nice, HOWEVER returning a struct/union will be dangerous as the
# of bytes returned by a function is not bounded anymore. This will
complicate the calling convention significantly, especially for return
values. In the case of returning base types only, the # of bytes
returned is limited to something like sizeof(long) or sizeof(long long)
depending on whether long long is implemented.

Speaking of types, I will probably be hated for stating the following,
especially as a "newcommer"; however I still want to say that. I think
it's crazy to support 64-bit basic types, but not supporting 24-bit.
Unlike the majority of C compilers, SDCC targets 8-bit systems. We can
assume distributions of variables range is somewhat exponential.
This means that the user is :
- Very likely to want to use 8-bit data types
- Likely to use 16-bit data types
- Somewhat likely  to use 24-bit data types
- Unlikely to use 32-bit data types
- Much unlikely to use 40-bit data types
- Extremely unlikely to use 64-bit data types

So in my opinion, "long" should be 24-bit, and "long long" 32-bit. Yes,
I know the ANSI standard states that "long should be at least 32-bit"
BUT we have to keep in mind that SDCC's goal is to make efficient code
for 8-bit targets and that ANSI was NOT made with this goal. So by
departing from ANSI when required we can make a better compiler overall.

So that should be the end of the part I'll be hated for.
I agree with you... in the hate thing, hehe!

I think ANSI compliance is really usuful for portability and I would try as hard as possible to be close to ANSI. My 2 cents.


Now I think I'd like to contribute in the machine independent
optimisation part, and I'd be interested in doing range analysis. In
fact I'll have to do this at a school project, so if I success I could
attempt to implement this into SDCC.

However, in the meantime I should probably start by doing something mcuh
simpler/shorter/easier in order to get started, right ? If I can get any
pointers, that'd be great.

Sorry for the very long post and best regards,


Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
Sdcc-user mailing list