From: Maarten B. <sou...@ds...> - 2005-05-14 12:19:27
|
<?xml version="1.0" ?><html> <head> <title></title> </head> <body> <div align="left"><font face="Arial"><span style="font-size:10pt">Continuing this on the developers list.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">I did not even know aslink was developing on it's own in a totally different place. So, as you may have guessed now, I used the sdcc version. But then again, I hardly changed anything to aslink if anything at all. Let me see...</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">I disabled the check for flat24 mode when processing >> 16 and generating R_HIB in asexpr.c. And I disabled the (!flat24Mode) in outrb() in asout.c. Thereby it is possible to have the linker generate 24-bit alike addresses when the -r option is used: sdcc -Wl-r</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">In main.c I added "banked" to the keywords and in gen.c genCall() has this change:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  /* make the call */</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  if (IFFUNC_ISBANKEDCALL (dtype) && !SPEC_STAT(getSpec(dtype)))</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  {</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    char *l = (OP_SYMBOL (IC_LEFT (ic))->rname[0] ?</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">               OP_SYMBOL (IC_LEFT (ic))->rname :</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">               OP_SYMBOL (IC_LEFT (ic))->name);</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">    emitcode ("mov", "r0,#%s", l);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    emitcode ("mov", "r1,#(%s >> 8)", l);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    emitcode ("mov", "r2,#(%s >> 16)", l);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    emitcode ("lcall", "__sdcc_banked_call");</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  }</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  else</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  {</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    emitcode ("lcall", "%s", (OP_SYMBOL (IC_LEFT (ic))->rname[0] ?</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">                              OP_SYMBOL (IC_LEFT (ic))->rname :</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">                              OP_SYMBOL (IC_LEFT (ic))->name));</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  }</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">This is possible because when using calleR-saves all registers are free when making the call. And genEndFunction has this code:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">      if (IFFUNC_ISBANKEDCALL (sym->type) && !SPEC_STAT(getSpec(sym->type)))</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">        {</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">          emitcode ("ljmp", "__sdcc_banked_ret");</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">        }</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">      else</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">        {</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">          emitcode ("ret", "");</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">        }</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">In SDCC.lex a new pragma was introduced:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    { "codeseg",  P_CODESEG,      0 },</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">and in doPragma():</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  case P_CODESEG:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    {</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">      char *segname = Safe_malloc(9);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">      sscanf(cp, " %8s", segname);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">      segname[8] = '\0';</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">      options.code_seg = segname;</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    }</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    break;</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">And in SDCCglobl.h the new option:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    const char *code_seg;       /* segment name to use instead of CSEG */</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">With default in SDCCmain.c:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  options.code_seg = CODE_NAME; /* default to CSEG for generated code */</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">This enables the user to specify a name to use for the code segment instead of CSEG. For Example #pragma codeseg CSEG1</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Then SDCCglue.c emitMaps() ends in:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  tfprintf (code->oFile, "\t!area\n", xinit->sname);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  if (port->genXINIT) {</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">    emitStaticSeg (xinit, code->oFile);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  }</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  emitStaticSeg (statsg, code->oFile);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  inInitMode--;</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">This has the effect that constants in code now end up in XINIT instead of CSEG, but this probably still needs more work.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">glue() ends with:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  /* copy over code */</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  fprintf (asmFile, "%s", iComments2);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  fprintf (asmFile, "; code\n");</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  fprintf (asmFile, "%s", iComments2);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  tfprintf (asmFile, "\t!areacode\n", options.code_seg);</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">  copyFile (asmFile, code->oFile);</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">thereby putting the generated code in the named code segment.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">And finally I introduced crtbank.asm which contains this for the Silabs C8051F12x uC:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            .globl _PSBANK</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            .area HOME    (CODE)</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">__sdcc_banked_call::</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            push    _PSBANK</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            anl       _PSBANK,#0xF0</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            xch      a,r0                  ;save Acc</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            push    acc                  ;do not assume any register bank</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            mov     a,r1</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            push    acc                  ;may need to reverse R0 and R1</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            mov     a,r2</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            orl        _PSBANK,a</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            xch      a,r0                  ;restore Acc</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            ret                                ;make the call</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">__sdcc_banked_ret::</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            pop      _PSBANK</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">            ret                                ;make the call</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Parameters passed on stack probably still need work, but as I said it's all very basic.</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">How to use it:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">prototype a banked function:</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">void foo(char x) banked;</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">And implement it in a source file with the pragma:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">#pragma codeseg CSEG1</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">void foo(char x) banked</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">{ x; }</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Compile and then link with -Wl-r and-Wl-bCSEG1=0x28000 to place the segment in another bank: 0x028000. The highest byte is the bank, the other 16 bits it's address. There is no checking for overlaps or automatic compacting in banks.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">I hope this is clear enough.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Now what should be possible with this kind of solution:</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">1) Do code banking on different mcs51-like uC's. Handle the specifics in crtbank.asm.</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">2) Put all constants in one or two segments (XINIT and probably another one CONST) which hopefully will fit in one bank each. Code can stay as efficient as it is if the CONST bank can stay selected during normal operation (true for F12x) and might free up the common area from XINIT (and even CONST on F12x !).</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> > But in the meantime I've got some very basic code </span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> > banking running. I'll try to complete it.</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> just curious, could you leak some more details?)</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> In particular I'd be interested whether using</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> an updated "aslink" would be part of the plan.</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> SDCC uses 1.70, whereas version 4.00 supports code banking.</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> http://shop-pdp.kent.edu/ashtml/asxupd.htm</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> Greetings,</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> Frieder</span></font></div> <div align="left"><br/></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Greets,</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">Maarten</span></font></div> </body> </html> |
From: Erik P. <epe...@iv...> - 2005-05-14 14:38:36
|
> > just curious, could you leak some more details?) > > In particular I'd be interested whether using > > an updated "aslink" would be part of the plan. > > > > SDCC uses 1.70, whereas version 4.00 supports code banking. > > http://shop-pdp.kent.edu/ashtml/asxupd.htm > > > > Greetings, > > Frieder I don't think the license agreement for the newer version would work for us: End User License Agreement This software is FREEWARE which means it is NOT public domain but fully copyrighted material that is distributed freely without money. Its electronic distribution through BBSs, the Internet, or other such means is encouraged provided no money is requested in return. It is forbidden to distribute this software should this file, or any of the remaining files, change in any way or be omitted from the archive. If you would like to include this software together with your own work you MUST include it only as the original complete un- modified archive in which I distribute it and not as independent files. If uncertain, simply point others or link to: http://ship-pdp.kent.edu/asxhtm/asxxxx.htm Please note that although I have done my best to ensure there is no potentially dangerous code (or accidental virus infec- tions), the nature of programming is such that it forces me to provide absolutely no warranty, express or implied, with this version of the software, and I bear no responsibility for what- ever damages, direct or consequential, you may suffer from its use. I definately do not warrant this software for suitability for any particular purpose, either. It is also possible that the instructions, the extra utilities, or the examples that come with the software contain errors, none of which were inten- tional. In particular, the second paragraph forbidding the distribution of modified files seems rather anti-open source. Erik |
From: Frieder F. <fri...@we...> - 2005-05-14 15:26:49
|
Erik Petrich wrote: > I don't think the license agreement for the newer version would > work for us: > ... > > In particular, the second paragraph forbidding the distribution of > modified files seems rather anti-open source. > > Erik Ooops. This pretty much explains why SDCCs version is this far behind. To my naive reading the version that comes with SDCC still has a kind of BSD style license. The new license clearly doesn't fit. And you and especially Maarten maybe shouldn't even look into the 4.00 aslink sources:( This is kind of unfortunate because IIRC cc6809 (also on SF) seemingly switched to 4.00. Greetings, Frieder |
From: Martin L. <le...@di...> - 2005-05-25 13:22:59
|
On l=F8r, 2005-05-14 at 09:44 -0500, Erik Petrich wrote: > > > just curious, could you leak some more details?) > > > In particular I'd be interested whether using > > > an updated "aslink" would be part of the plan. > > > > > > SDCC uses 1.70, whereas version 4.00 supports code banking. > > > http://shop-pdp.kent.edu/ashtml/asxupd.htm > > > > > > Greetings, > > > Frieder >=20 > I don't think the license agreement for the newer version would > work for us: I tried to investigate a little bit further. So I got the old 1.70 and a few other versions of the website. On the download site there is the same "Enduser License Agreement" - it's unclear whether it suppose to apply to all or some versions. This license agreemet is included with the 4.0 package, but not with the other versions I tried (3.11 and 1.70). 3.11 has the following notice on distribution, but I can't find anything on modification: ... Distribution: May be freely distributed with author's permission and inclusion of copyright notice ... Did anyone try to contact the author (Alan R. Baldwin) maybee he would be interested in a special deal for sdcc. Or maybee some of the changes for sdcc might be interesting for him as well? --=20 Regards Martin Leopold. Dept. of Computer Science, University of Copenhagen |
From: Frieder F. <fri...@we...> - 2005-05-27 00:08:13
|
Hello Martin, Martin Leopold wrote: > I tried to investigate a little bit further. So I got the old 1.70 and a > few other versions of the website. On the download site there is the > same "Enduser License Agreement" - it's unclear whether it suppose to > apply to all or some versions. > > This license agreemet is included with the 4.0 package, but not with the > other versions I tried (3.11 and 1.70). 3.11 has the following notice on > distribution, but I can't find anything on modification: > > ... > Distribution: May be freely distributed with author's > permission and inclusion of copyright notice > ... > > Did anyone try to contact the author (Alan R. Baldwin) maybee he would > be interested in a special deal for sdcc. Or maybee some of the changes > for sdcc might be interesting for him as well? this might have been done some years ago but I don't think it happened recently. Some days ago I notified Aurelien (the Debian maintainer of SDCC) about the different licensing terms of this package and whether this could mean (part of) SDCC would have to move to Debian non-free. As the licensing don't seem to be very clear (to my naive reading) it would (as you proposed) make sense to contact the author to hear about his intent. This has to the best of my knowlegde not happened recently and as a non-native english speaker I myself didn't feel up to it. Greetings, Frieder |
From: Mark S. <mar...@ma...> - 2005-06-14 19:49:55
|
Has anyone contacted Alan Baldwin regarding the ASXXXX license? If nobody has, I'll be happy to follow up. My understanding is that: 1. SDCC uses a patched version of the 1.70 source and there is=20 interest in using the latest, 4.0 package for further development. 2. However there are concerns about license compatibility. SDCC is=20 distributed under the GPL and ASXXXX 4.0 license does not seem to be=20 compatible. 3. We would like to know if Alan is willing to cut SDCC project some=20 slack on the distribution terms for his software. If this is materially correct, and no one gives me any reason not to=20 contact Mr. Baldwin, I will do so in the next couple of days. If anyone has already contacted Mr. Baldwin, please speak up. I really=20= don't want to hassle and annoy him. Thanks, -Mark Swayne On May 25, 2005, at 6:22 AM, Martin Leopold wrote: > On l=F8r, 2005-05-14 at 09:44 -0500, Erik Petrich wrote: >>>> just curious, could you leak some more details?) >>>> In particular I'd be interested whether using >>>> an updated "aslink" would be part of the plan. >>>> >>>> SDCC uses 1.70, whereas version 4.00 supports code banking. >>>> http://shop-pdp.kent.edu/ashtml/asxupd.htm >>>> >>>> Greetings, >>>> Frieder >> >> I don't think the license agreement for the newer version would >> work for us: > > I tried to investigate a little bit further. So I got the old 1.70 and=20= > a > few other versions of the website. On the download site there is the > same "Enduser License Agreement" - it's unclear whether it suppose to > apply to all or some versions. > > This license agreemet is included with the 4.0 package, but not with=20= > the > other versions I tried (3.11 and 1.70). 3.11 has the following notice=20= > on > distribution, but I can't find anything on modification: > > ... > Distribution: May be freely distributed with author's > permission and inclusion of copyright notice > ... > > Did anyone try to contact the author (Alan R. Baldwin) maybee he would > be interested in a special deal for sdcc. Or maybee some of the = changes > for sdcc might be interesting for him as well? > > --=20 > Regards Martin Leopold. > Dept. of Computer Science, University of Copenhagen > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: GoToMeeting - the easiest way to=20 > collaborate > online with coworkers and clients while avoiding the high cost of=20 > travel and > communications. There is no equipment to buy and you can meet as often=20= > as > you want. Try it=20 > free.http://ads.osdn.com/?ad_idt02&alloc_id=16135&op=3Dclick > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Mark S. <mar...@ch...> - 2005-07-12 22:03:55
|
Update: I sent Alan Baldwin an email on June 24th, and haven't heard anything=20 from him yet. If I haven't heard anything after a full month has passed (ie on or=20 about 7-24), I will contact him again at the address listed on the=20 ASXXXX page. I found another email address for him in Kent State's online faculty=20 directory, but I am hesitant to contact him through that address. What=20 do people think about contacting him at this other email address? I=20 really don't want to be rude or pushy, but total silence is rather=20 frustrating. --Mark Swayne Mark Swayne wrote: > Has anyone contacted Alan Baldwin regarding the ASXXXX license? > > If nobody has, I'll be happy to follow up. > > My understanding is that: > 1. SDCC uses a patched version of the 1.70 source and there is=20 > interest in using the latest, 4.0 package for further development. > 2. However there are concerns about license compatibility. SDCC is=20 > distributed under the GPL and ASXXXX 4.0 license does not seem to be=20 > compatible. > 3. We would like to know if Alan is willing to cut SDCC project some=20 > slack on the distribution terms for his software. > > If this is materially correct, and no one gives me any reason not to=20 > contact Mr. Baldwin, I will do so in the next couple of days. > > If anyone has already contacted Mr. Baldwin, please speak up. I=20 > really don't want to hassle and annoy him. > > Thanks, > > -Mark Swayne > > > On May 25, 2005, at 6:22 AM, Martin Leopold wrote: > >> On l=F8r, 2005-05-14 at 09:44 -0500, Erik Petrich wrote: >> >>>>> just curious, could you leak some more details?) >>>>> In particular I'd be interested whether using >>>>> an updated "aslink" would be part of the plan. >>>>> >>>>> SDCC uses 1.70, whereas version 4.00 supports code banking. >>>>> http://shop-pdp.kent.edu/ashtml/asxupd.htm >>>>> >>>>> Greetings, >>>>> Frieder >>>> >>> >>> I don't think the license agreement for the newer version would >>> work for us: >> >> >> I tried to investigate a little bit further. So I got the old 1.70 and= a >> few other versions of the website. On the download site there is the >> same "Enduser License Agreement" - it's unclear whether it suppose to >> apply to all or some versions. >> >> This license agreemet is included with the 4.0 package, but not with t= he >> other versions I tried (3.11 and 1.70). 3.11 has the following notice = on >> distribution, but I can't find anything on modification: >> >> ... >> Distribution: May be freely distributed with author's >> permission and inclusion of copyright notice >> ... >> >> Did anyone try to contact the author (Alan R. Baldwin) maybee he would >> be interested in a special deal for sdcc. Or maybee some of the change= s >> for sdcc might be interesting for him as well? >> >> --=20 >> Regards Martin Leopold. >> Dept. of Computer Science, University of Copenhagen >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: GoToMeeting - the easiest way to=20 >> collaborate >> online with coworkers and clients while avoiding the high cost of=20 >> travel and >> communications. There is no equipment to buy and you can meet as=20 >> often as >> you want. Try it=20 >> free.http://ads.osdn.com/?ad_idt02&alloc_id=16135&op=3Dclick >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Borut R. <bor...@si...> - 2005-11-26 20:15:22
|
Hi Mark, are there any news from Alan Baldwin? Borut Mark Swayne wrote: > Update: > > I sent Alan Baldwin an email on June 24th, and haven't heard anything > from him yet. > > If I haven't heard anything after a full month has passed (ie on or > about 7-24), I will contact him again at the address listed on the > ASXXXX page. > > I found another email address for him in Kent State's online faculty > directory, but I am hesitant to contact him through that address. > What do people think about contacting him at this other email > address? I really don't want to be rude or pushy, but total silence > is rather frustrating. > > --Mark Swayne |
From: Borut R. <bor...@si...> - 2007-11-17 13:37:36
|
I added the "SDCC AS and LINK history" page to SDCC wiki at http://sdcc.wiki.sourceforge.net/SDCC+AS+and+LINK+history. If you have additional information or comments to add, you are welcome! Borut |
From: Frieder F. <fri...@we...> - 2005-05-14 14:44:26
|
Hello Maarten, cool, that looks good:) May I suggest some variations of the banking switching? a) your approach, which I'd like to name: "R0,R1,R2_indexed_jump_over_1_generic_trampoline" Resources: 6 byte in calling, 2 byte in called routine, + (generic routine in common bank) , 1 byte stack, 3 registers, b) a slight variation over your approach a) "R0,R1,R2_indexed_lcall_over_1_generic_trampoline" Resources: 6 byte in calling, 0 byte in called routine, + (trampoline in common bank), 3 bytes stack, 3 registers, (no overhead when called from same bank) c) another slight variation over your approach: "R0,R1_indexed_lcall_over_n_generic_trampolines" (n-number of banks) (for 4 banks you'd have __sdcc_banked_call_00, __sdcc_banked_call_01, which would switch to the respective bank ... in essence you'd use the trampoline address instead of R2 to encode the destination bank) Resources: 4 byte in calling, 2 byte in called routine, + (n trampolines in common bank), 3 bytes stack, 2 registers (no overhead when called from same bank) d) another variation over your approach, similar to c) "lcall_over_m_specific_trampolines" (with m-number of routines with attribut banked which are called from a different bank) Resources: 0 byte in calling, 0 byte in called routine, + (m trampolines in common bank), 3 bytes stack, 1 registers (no overhead when called from same bank) e) another variation over your approach, similar to d) "lcall_over_mn_specific_trampolines" (this would need trampolines with __trampoline_function_call_from_00, so if a banked function in bank 2 would be called from bank 0 and bank 1 you'd need two trampolines. Trampolines could be of the form: __trampoline_my_func_from_00: mov _PSBANK,#0x02 ; eventually changing a bit would do lcall _my_func mov _PSBANK,#0x00 ; eventually changing a bit would do ret Resources: 0 byte in calling, 0 byte in called routine, + (<m*n trampolines in common bank), 2 bytes stack, 0 registers (no overhead when called from same bank) I personally like d) and e) because if a program is hierarchically organized you often don't need many interbank calls. Within the same code bank the program then runs without overhead. As programs get larger (or cannot be split into functional units) the generic trampolines a,b,c become increasingly more attractive. I don't see us there yet:) Greetings, Frieder |
From: Frieder F. <fri...@we...> - 2005-05-14 22:10:01
|
Hmmm, rereading my post there's at least one mistake: Frieder Ferlemann wrote: > c) another slight variation over your approach: > "R0,R1_indexed_lcall_over_n_generic_trampolines" (n-number of banks) > (for 4 banks you'd have __sdcc_banked_call_00, __sdcc_banked_call_01, > which would switch to the respective bank > ... in essence you'd use the trampoline address instead of R2 > to encode the destination bank) > > Resources: 4 byte in calling, 2 byte in called routine, should be 0 byte in called routine > + (n trampolines in common bank), 3 bytes stack, 2 registers > (no overhead when called from same bank) Luckily didn't even try counting cycles:) Anyway this is a trade-off of resources between caller/switcher/callee and finding the sweet spot depends on the application and the code which is needed for switching banks (bit / byte / byte with bitmask / byte with shift & bitmask/ number of inter_bank_called functions / number of banks ). So most likely THE SOLUTION does not exist. But, ... ;) Greetings, Frieder |
From: Maarten B. <sou...@ds...> - 2005-05-15 17:30:08
|
Thanks for looking into it. I have some comments on your proposals as well. > a) your approach, which I'd like to name: > "R0,R1,R2_indexed_jump_over_1_generic_trampoline" > > Resources: 6 byte in calling, 2 byte in called routine, > + (generic routine in common bank) , 1 byte stack, 3 registers, > > b) a slight variation over your approach a) > "R0,R1,R2_indexed_lcall_over_1_generic_trampoline" > > Resources: 6 byte in calling, 0 byte in called routine, > + (trampoline in common bank), 3 bytes stack, 3 registers, > (no overhead when called from same bank) There is only no overhead when the compiler knows you're calling from the same bank. If the linker decides you're calling from the same bank, it can reduce to 6 bytes calling overhead. > c) another slight variation over your approach: > "R0,R1_indexed_lcall_over_n_generic_trampolines" (n-number of banks) > (for 4 banks you'd have __sdcc_banked_call_00, __sdcc_banked_call_01, > which would switch to the respective bank > ... in essence you'd use the trampoline address instead of R2 > to encode the destination bank) > > Resources: 4 byte in calling, 2 byte in called routine, > + (n trampolines in common bank), 3 bytes stack, 2 registers > (no overhead when called from same bank) The linker must find the destination address and convert that into bank selecting call. > d) another variation over your approach, similar to c) > "lcall_over_m_specific_trampolines" (with m-number of routines > with attribut banked which are called from a different bank) > > Resources: 0 byte in calling, 0 byte in called routine, > + (m trampolines in common bank), 3 bytes stack, 1 registers > (no overhead when called from same bank) > > e) another variation over your approach, similar to d) > "lcall_over_mn_specific_trampolines" > > (this would need trampolines with __trampoline_function_call_from_00, > so if a banked function in bank 2 would be called from bank 0 > and bank 1 you'd need two trampolines. > Trampolines could be of the form: > __trampoline_my_func_from_00: > mov _PSBANK,#0x02 ; eventually changing a bit would do > lcall _my_func > mov _PSBANK,#0x00 ; eventually changing a bit would do > ret > > Resources: 0 byte in calling, 0 byte in called routine, > + (<m*n trampolines in common bank), 2 bytes stack, 0 registers > (no overhead when called from same bank) All your solutions require more stack space and the stack is a limited resource, esp. for large programs. > I personally like d) and e) because if a program is hierarchically > organized you often don't need many interbank calls. Within the > same code bank the program then runs without overhead. > > As programs get larger (or cannot be split into functional units) > the generic trampolines a,b,c become increasingly more attractive. > I don't see us there yet:) If your program is hierarchical you can make the entry point for a calling tree banked and the rest you make either static functions or you use them in "trust me" mode (default non-banked). If "trust me" can be checked by the linker, we could also do11 bit acall/ajmp instructions (near?). In "trust me" mode overhead is still low with few interbank calls, but the library probably needs to reside in the common area. Only the entry functions need return overhead and with a) there is very little trampoline function overhead. Also having many trampoline functions complicates things for users as they must change many routines to their hardware. Not all bankswitching is done inside a uC, mostly outside. And having only one trampoline also spares the common area. That's why I did not go for another variation: f) Like a) but one for every register bank so we can push ar0 and ar1 directly. So my argument is to use as few as possible stack and trampolines. Judicious use of the keyword banked is probably better than bluntly making everything banked with either a command line option or a pragma. Greetings, Maarten |
From: Frieder F. <fri...@we...> - 2005-05-15 20:38:11
|
Maarten Brock wrote: > Thanks for looking into it. I have some comments on your proposals as well. >>b) a slight variation over your approach a) >> "R0,R1,R2_indexed_lcall_over_1_generic_trampoline" >> >> Resources: 6 byte in calling, 0 byte in called routine, >> + (trampoline in common bank), 3 bytes stack, 3 registers, >> (no overhead when called from same bank) > There is only no overhead when the compiler knows you're calling from the same bank. > If the linker decides you're calling from the same bank, it can reduce to 6 bytes calling > overhead. Reading from your comment I assume you'd use the keyword banked without further argument (and thus leave it up to the linker where to put it). I'd rather like to give the compiler a stronger position by using banked(0), banked(1), ... respectively. Traditionally the decision into which bank something is located is done at the linking stage. This is probably suboptimal, the opportunity for some optimations (f.e. using setb/clrb in proposal e)) would be lost. >>c) another slight variation over your approach: >> "R0,R1_indexed_lcall_over_n_generic_trampolines" (n-number of banks) >> (for 4 banks you'd have __sdcc_banked_call_00, __sdcc_banked_call_01, >> which would switch to the respective bank >> ... in essence you'd use the trampoline address instead of R2 >> to encode the destination bank) >> >> Resources: 4 byte in calling, 2 byte in called routine, >> + (n trampolines in common bank), 3 bytes stack, 2 registers >> (no overhead when called from same bank) > The linker must find the destination address and convert that into bank selecting call. with banked(0), banked(1) (as above) the decision would be made by the compiler so this wouldn't be a problem. >>e) another variation over your approach, similar to d) >> "lcall_over_mn_specific_trampolines" >> >> (this would need trampolines with __trampoline_function_call_from_00, >> so if a banked function in bank 2 would be called from bank 0 >> and bank 1 you'd need two trampolines. >> Trampolines could be of the form: >> __trampoline_my_func_from_00: >> mov _PSBANK,#0x02 ; eventually changing a bit would do >> lcall _my_func >> mov _PSBANK,#0x00 ; eventually changing a bit would do >> ret >> >> Resources: 0 byte in calling, 0 byte in called routine, >> + (<m*n trampolines in common bank), 2 bytes stack, 0 registers >> (no overhead when called from same bank) > All your solutions require more stack space and the stack is a limited resource, esp. for > large programs. Ack. It's all a compromise. Guessing about typical stuff now: For most programs you'll be fine with less than 10 stacked inter-bank calls (costing max 20 to 30 byte of additional idata space in my variants). You'd have to migrate idata vars to pdata vars then. If we neglect the "subtle" differences between idata and pdata this adds 30/(128+256)= 8% memory pressure on combined idata/pdata. Seems fair to me. (But if the program needs more than 128byte stack, my argument falls into pieces). >>I personally like d) and e) because if a program is hierarchically >>organized you often don't need many interbank calls. Within the >>same code bank the program then runs without overhead. >> >>As programs get larger (or cannot be split into functional units) >>the generic trampolines a,b,c become increasingly more attractive. >>I don't see us there yet:) > If your program is hierarchical you can make the entry point for a calling tree banked > and the rest you make either static functions or you use them in "trust me" mode > (default non-banked). If "trust me" can be checked by the linker, we could also do11 bit > acall/ajmp instructions (near?). In "trust me" mode overhead is still low with few > interbank calls, but the library probably needs to reside in the common area. Only the > entry functions need return overhead and with a) there is very little trampoline function > overhead. The "trusted me" mode has a similar effect as banked(0), banked(1) but seems more complicated. > Also having many trampoline functions complicates things for users as they must > change many routines to their hardware. I had in mind the user would supply 4 bankswitching MACROs for 4 banks and the compiler would then generate the trampolines automatically. > Not all bankswitching is done inside a uC, Ack, probably a large fraction are devices with 128kByte external Eprom which is switched on A15/A16 by port bits (P3_0, P3_1 typically) > mostly outside. And having only one trampoline also spares the common area. That's > why I did not go for another variation: > > f) Like a) but one for every register bank so we can push ar0 and ar1 directly. Ack, around 4# wouldn't be worth it. > So my argument is to use as few as possible stack and trampolines. Proposal a-c) also use registers. This resource currently comes at no cost but I hope this will change some day: (Functions should pass their register usage upwards so the calling function should not push all the registers it cares about but only those which are used by the callee(tree)). We can probably agree that we are on extreme ends, one side uses (more stack, more code, no registers, few cycles) and the other one (less stack, less code, more registers, more cycles). If an application fits (by code and stack size) into d) or e) it will be superior to a-c). Very nice. If an application doesn't fit (by code _OR_ stack size) into d) or e) it won't work at all. Too poor to rate. If we don't agree on the weighing of these resources you should take the pragmatical approach and go ahead. One thing I'd like to have though is that the compiler should know about the bank it is switching to (by pragma or with a banked(n) keyword) Other arguments/opinions (in the order named?) anyone? Greetings, Frieder |