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 feasible. 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 etc... - 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. 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, Jonathan ------------------------------------------------------------------------------ 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! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
