From: Henk P. <HPoley@DDS.nl> - 2001-10-17 10:30:53
|
Would it be possible to add 'inline' to SDCC? See the following code: ------- inline int min(a,b) { return (a<b)?a:b; } a = min(i++, j); ------- Would then become (off coarse the optimizer will do it's work): ------- inl_0 = i; inl_1 = j; inl_ret_0 = (inl_0++ < inl_1) ? inl_0 : inl_1); a = inl_ret_0; ------- Or do I oversee things? Henk Poley <>< |
From: Bernhard H. <ber...@be...> - 2001-10-17 12:20:16
|
> Would it be possible to add 'inline' to SDCC? See the following code: > > ------- > inline int min(a,b) { return (a<b)?a:b; } > > a = min(i++, j); > ------- > > Would then become (off coarse the optimizer will do it's work): > > ------- > inl_0 = i; > inl_1 = j; > inl_ret_0 = (inl_0++ < inl_1) ? inl_0 : inl_1); > a = inl_ret_0; > ------- > > Or do I oversee things? You don't do this with an "inline" but with a macro: #define min(a,b) ((a) < (b) ? (a) : (b)) Beware of the side-effects, because the smaller parameter is evaluated twice: minimum = min (left [x++], right [y++]); This line won't do what you expect. Bernhard |
From: Eric N. <eri...@us...> - 2001-10-17 14:21:05
|
An improvement I'd like to see is an assembler which could properly handle span-dependent instructions. i.e. The compiler could could just put out: jmp foo or jc foo or cjmpne a,#5,bar or djmpnz r5,bletch The assembler would then properly convert these to sjmp foo or ljmp foo jc foo or jnc lxxx; ljmp foo; lxxx: cjne a,#5,bar or cjne a,#5,lxxxx; sjmp lyyyy; lxxx: ljmp bar; lyyyy: djnz r5, bletch or djnz r5,lxxxx; sjmp lyyyy; lxxxx: ljmp bletch; lyyyy: The effort to do this is not trivial (it turns out to be an NP complete problem), but is well documented (the classic paper on the subject is, ``Assembling Code for Machines with Span-Dependent Instructions'', T. G. Syzmanski, Communications of the ACM, April, 1978). From the date on this papter you can see that the problem has been solved for a long time! There are different ways this could be approached. 1) Start from scratch to write an assembler based on the above reference. 2) Add an 8051 target to gas, and then use gld as a linker. Comments, suggestions??? Is anyone else out there looking in to this? -- Eric Norum eri...@us... Department of Electrical Engineering Phone: (306) 966-5394 University of Saskatchewan FAX: (306) 966-5407 Saskatoon, Canada. |
From: Sandeep D. <sa...@wi...> - 2001-10-20 19:05:16
|
Indeed the assembler and the linker has much room for improvement. With the current situation though, as much as I would like to make these changes I just don't have the time.... To this wishlist I would add , linker with overlaying capability assemler & linker suport for more portable object file formats (e.g. OMF51 .. or ELF)..... The GNU linker is not very capable of handling the multiple address spaces it will have problems when multiple sections start @ the same address for example, a large amount of hackery would be required to handle this....(I think) A nice retargettable assembler written from scratch would be perfect :) Sandeep > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Eric Norum > Sent: Wednesday, October 17, 2001 7:21 AM > Cc: sdc...@li... > Subject: [Sdcc-user] Better assembler? > > > An improvement I'd like to see is an assembler which could properly > handle span-dependent instructions. > > i.e. The compiler could could just put out: > jmp foo > or > jc foo > or > cjmpne a,#5,bar > or > djmpnz r5,bletch > > The assembler would then properly convert these to > sjmp foo or ljmp foo > jc foo or jnc lxxx; ljmp foo; lxxx: > cjne a,#5,bar or cjne a,#5,lxxxx; sjmp lyyyy; > lxxx: ljmp bar; > lyyyy: > djnz r5, bletch or djnz r5,lxxxx; sjmp lyyyy; lxxxx: ljmp bletch; > lyyyy: > > The effort to do this is not trivial (it turns out to be an > NP complete > problem), but is well documented (the classic paper on the subject is, > ``Assembling Code for Machines with Span-Dependent > Instructions'', T. G. > Syzmanski, Communications of the ACM, April, 1978). From the date on > this papter you can see that the problem has been solved for a long > time! > > There are different ways this could be approached. > 1) Start from scratch to write an assembler based on the above > reference. > 2) Add an 8051 target to gas, and then use gld as a linker. > > Comments, suggestions??? > Is anyone else out there looking in to this? > -- > Eric Norum eri...@us... > Department of Electrical Engineering Phone: (306) 966-5394 > University of Saskatchewan FAX: (306) 966-5407 > Saskatoon, Canada. > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Scott D. <sc...@da...> - 2001-10-20 22:50:44
|
On Sat, 20 Oct 2001, Sandeep Dutta wrote: > Indeed the assembler and the linker has much room for improvement. > With the current situation though, as much as I would like to > make these changes I just don't have the time.... > > To this wishlist I would add , linker with overlaying capability > assemler & linker suport for more portable object file formats (e.g. > OMF51 .. or ELF)..... > > The GNU linker is not very capable of handling the multiple address > spaces it will have problems when multiple sections start @ the same > address for example, a large amount of hackery would be required to > handle this....(I think) > > A nice retargettable assembler written from scratch would be perfect :) Actually we're writing a linker for the GNUPIC project right now. Craig Franklin, the most active gpasm (gnupic assembler) maintainer is in the early design stages of the linker. He's heavily leaning on COFF since that's currently the format Microchip has chosen for their linker. Scott |
From: Michael S. <rin...@a-...> - 2001-10-21 08:13:20
|
On Sat, Oct 20, 2001 at 12:04:20PM -0700, Sandeep Dutta wrote: > > The GNU linker is not very capable of handling the multiple address > spaces it will have problems when multiple sections start @ the same > address for example, a large amount of hackery would be required to > handle this....(I think) > > A nice retargettable assembler written from scratch would be perfect :) Alfred Arnold's AS might be worth looking at: the assembler should have everything we need (and supports a really impressive list of targets), but the linker support is still work in progress. It is available from http://www.alfsembler.de/ and the current versions have moved to GPL as license. cu Michael |
From: <MSoegtrop@Michael-Soegtrop.de> - 2001-10-22 15:42:25
|
The GNU assembler and linker work actually very well for small platforms. The problem of multiple overlapping address spaces can be solved by distinguishing the address spaces in some upper bits of the address space AND by section. This works almost always, because only systems with addresses less than 32 bit tend to have overlapping address spaces. The development system for the Ubicom IP2022, which relies on GCC and produces ELF format output, is a good example on how to do this. As far as i can see, all of the overlapping address space business is solved with linker scripts (.x files) and not by hacking the compiler, linker or assembler. This is possible, because gcc distinguishes between several sections (.data, .bss and .text) anyway. A further advantage of using the GNU tools at the back end, is that you can use the GNU binutils, which would solve quite a few of the problems discusses in this news group. Best regards, Michael -----Ursprungliche Nachricht----- Von: sdc...@li... [mailto:sdc...@li...]Im Auftrag von Sandeep Dutta Gesendet: Samstag, 20. Oktober 2001 21:04 An: 'Eric Norum' Cc: sdc...@li... Betreff: RE: [Sdcc-user] Better assembler? Indeed the assembler and the linker has much room for improvement. With the current situation though, as much as I would like to make these changes I just don't have the time.... To this wishlist I would add , linker with overlaying capability assemler & linker suport for more portable object file formats (e.g. OMF51 .. or ELF)..... The GNU linker is not very capable of handling the multiple address spaces it will have problems when multiple sections start @ the same address for example, a large amount of hackery would be required to handle this....(I think) A nice retargettable assembler written from scratch would be perfect :) Sandeep |
From: Eric N. <eri...@us...> - 2001-12-07 14:38:39
|
After making the following two changes I was able to build sdcc on MacOS X.1.1. The ucsim code won't build because it needs a different version of curses/ncurses, but at least I can compile/assemble/link 8051 programs on my Mac. 1) It seems that the sed supplied with MacOS 10.1.1 is not capable of performing the tasks required by the sdcc configure scripts. I downloaded and built GNU sed 3.02 and now the sdcc configure scripts work fine. Perhaps this should be mentioned in the installation notes or a README somewhere. 2) The conditional compiles for APPLE/MACH (i.e. MacOS X) in debugger/msc51/cmd.c leave the `warranty' string undefined. Here's a quick patch. A better solution would be to make the code true ANSI C by adding a \n and placing quotes around each line of the copying/warranty string initializers. For example: "something like this\n" "using the fact that ANSI C concatentates\n" "these individual components\n" Anyhow, here's the quick patch: cvs server: Diffing debugger/mcs51 Index: debugger/mcs51/cmd.c =================================================================== RCS file: /cvsroot/sdcc/sdcc/debugger/mcs51/cmd.c,v retrieving revision 1.4 diff -u -r1.4 cmd.c --- debugger/mcs51/cmd.c 2001/09/14 03:46:43 1.4 +++ debugger/mcs51/cmd.c 2001/12/07 02:39:54 @@ -293,6 +293,11 @@ of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. "; +#endif +#if defined(__APPLE__) && defined(__MACH__) +static char *warranty= +{" NO WARRANTY"}; +#else static char *warranty= " NO WARRANTY -- Eric Norum eri...@us... Department of Electrical Engineering Phone: (306) 966-5394 University of Saskatchewan FAX: (306) 966-5407 Saskatoon, Canada. |
From: Alex K. <Alex@Karahalios.org> - 2001-12-07 16:51:17
|
Hi Eric, If you feel brave, I have some scripts and templates so that you can develop SDCC code under Mac OS X Project Builder. The latest version in CVS does include come changes to the error output of SDCC to make it more compatible with GNU style compilers. There are a few more changes I need to check in for ASLINK and ASX8051. Alex Karahalios On Friday, December 7, 2001, at 07:37 AM, Eric Norum wrote: > After making the following two changes I was able to build sdcc on MacOS > X.1.1. The ucsim code won't build because it needs a different version > of curses/ncurses, but at least I can compile/assemble/link 8051 > programs on my Mac. |
From: Martijn v. B. <pi...@do...> - 2001-12-09 20:58:53
|
Alex Karahalios wrote: > Hi Eric, > > If you feel brave, I have some scripts and templates so that you can > develop SDCC code under Mac OS X Project Builder. Hmm. I was *just* about to ask for help with compiling sdcc under MacOS X 10.0 (still need to upgrade one day) - I seem to be missing sdcc/support/cpp2/Makefile.am.. (this is with Automake 1.5). Any hints? -- Martijn van Buul - Pi...@do... - http://www.stack.nl/~martijnb/ Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333 Kees J. Bot: The sum of CPU power and user brain power is a constant. |
From: Alex K. <Alex@Karahalios.org> - 2001-12-09 22:24:38
|
On Sunday, December 9, 2001, at 01:56 PM, Martijn van Buul wrote: > (this is with Automake 1.5). Any hints? > Try the SDCC patch area at http://sourceforge.net/tracker/index.php?func=detail&aid=454312&group_id=599& atid=300599 There are patches there for Mac OS X. I have not tried these patches, but they appear to cover the areas which cause problems on Mac OS X. I remember compiling SDCC under Mac OS X 10.0 with no problems once I applied similar patches. Alex Karahalios |
From: Karl B. <ka...@tu...> - 2001-12-10 03:21:56
|
Hi, I added in this patch from Rob McKeever to the source base around Sept 18. He had posted to the list around Sept 5th, and I offered to help make the changes in CVS. There was one small piece that I did not add: diff -Naur sdcc-orig/support/cpp2/configure sdcc/support/cpp2/configure --- sdcc-orig/support/cpp2/configure Wed Jul 11 20:21:31 2001 +++ sdcc/support/cpp2/configure Tue Aug 28 10:52:34 2001 @@ -3397,14 +3397,10 @@ s%@symbolic_link@%$symbolic_link%g s%@thread_file@%$thread_file%g s%@c_target_objs@%$c_target_objs%g -/@target_overrides@/r $target_overrides s%@target_overrides@%%g -/@host_overrides@/r $host_overrides s%@host_overrides@%%g s%@cross_defines@%$cross_defines%g -/@cross_overrides@/r $cross_overrides s%@cross_overrides@%%g -/@build_overrides@/r $build_overrides s%@build_overrides@%%g The lines with "/r" were causing him grief. Rob thought we could just get rid of these lines, I didn't change it because I didn't understand what the /r's were supposed to do in the first place. Other than the simulator, I think Rob had SDCC compiling under MacOS X. He also mentioned that Sourceforge had a MacOS X beast in the compiler farm. Karl. Alex Karahalios wrote: > On Sunday, December 9, 2001, at 01:56 PM, Martijn van Buul wrote: > >> (this is with Automake 1.5). Any hints? >> > Try the SDCC patch area at > > http://sourceforge.net/tracker/index.php?func=detail&aid=454312&group_id=599& > > atid=300599 > > There are patches there for Mac OS X. I have not tried these patches, > but they appear to cover the areas which cause problems on Mac OS X. > > I remember compiling SDCC under Mac OS X 10.0 with no problems once I > applied similar patches. > > Alex Karahalios > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Scott D. <sc...@da...> - 2001-10-17 14:54:06
|
On Wed, 17 Oct 2001, Henk Poley wrote: > Would it be possible to add 'inline' to SDCC? See the following code: > > ------- > inline int min(a,b) { return (a<b)?a:b; } > > a = min(i++, j); > ------- > > Would then become (off coarse the optimizer will do it's work): > > ------- > inl_0 = i; > inl_1 = j; > inl_ret_0 = (inl_0++ < inl_1) ? inl_0 : inl_1); > a = inl_ret_0; > ------- > > Or do I oversee things? Henk, One of things I REALLY would like is an inlining linker with automatic register optimization. When I look at the code generated by SDCC or any other compiler for that matter, I think to myself, "you know, if this function was inlined instead of called, I'd save N instructions and remove X temporary registers." It's not hard for the linker to perform a call analysis and decide which functions can be inlined. But it needs to be performed by the linker instead of compiler. The reason is that you don't know apriori where a (non-static) function will be used. Once a function is inlined, it becomes fairly straight forward to coalesce registers too. I already do this to a certain degree in the PIC port (coalescing, not inlining). I know I didn't answer your question, but I've been thinking about this for a while. Wait 'til the PIC port linker is written :). Scott |