-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.12.2013 18:49, schrieb Masur Jonathan: > 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.
Asking on sdcc-devel about specifics should help. There's the code, the manual, and three published articles: Sandeep Dutta, "Anatomy of a Compiler". Read this one for an introduction Philipp Klaus Krause, "Optimal Register Allocation in Polynomial Time". REad this one if yu want to know the details of the register allocator. Philipp Klaus Krause "Optimal placement of bank selection instructions in polynomial time". REad this one if you want to know the details of how user-configurable named address spaces are implemented. > > Where can I look at the feature requests and bugs list Philip > mentioned ? They're at sourceforge (under "tickets"): http://sourceforge.net/projects/sdcc/ You might also want to subscribe to the sdcc-devel list in addition to sdcc-user. > > 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. While this probably is not an item for a beginner, most sdcc targets have 16-bit stack pointers, which would make variable lengths arrays on the stack feasible (and desirable, especially for embedded systems, since it can save the overhead of having to link malloc / free libries). > > 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. The back-end part is easy: We would himplement it the same as returning long long: The caller passes a pointer, and the callee writes the return value there. > > 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. I strongly disagree. sdcc should IMO always be as standard-compliant (not just the 1998 ANSI standard, but the 1990, 1995, 1999, 2011 ISO standards) as possible. I see no need to deviate from the standard. A 24-bit data type is clearly a good thing to have, and there is an open feature request. The standard-compliant way to implement it is to give it a reserved name (e.g. __sdcc_int24), and add typedefs to stdint.h to have it available under the standard names int24_t (for the signed one) and uint24_t (for the unsigned one). Also the 24 bit signed type would give us an efficient standard-compliant ptrdiff_t. > > 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. Yes. How about that stm8 assembler subw bug I mentioned? Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlK0iwMACgkQbtUV+xsoLpphDQCg6tzf/ST5PPT+5SBO01Go0B8K G0gAoN18J74LWYYzCL5B50+OwM7l9I1i =jZb+ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
