From: Borut R. <bor...@si...> - 2009-11-29 10:44:43
|
Hi sdcc developers, as I already mentioned in previous postings that I'm working on sdcc assembler and linker unification and synchronization with asxxxx version 5.0. *Unification* My goal is to resemble the asxxxx directory structure: common files in asxxsrc and linksrc (currently named link) directories and targets dependent files in separate directories. I already achieved this quite well for sdcc assembler, but the linker is more problematic: asxxxx has a single target independent linker (aslink), while sdcc has a separate linker for each platform. *Polymorphism *I'll solve this problem by different behavior of sdcc linker, depending of the executable name. The intermediate goal is to have single linker executable which will behave differently depending of it's file name: * sdld or sdld8051 - 8051 family linker, including ds390 and ds400 targets * sdld6080 - hc08 platform, probably with cs08 extensions from Gary Osborn * sdldz80 - z80 linker * sdldgb - gb linker The final goal is to have one target independent sdld executable. My goal is also that both asdcc assembler and linker resembles the original asxxxx functionality when called with original asxxxx names: asXXXX and aslink. *Synchronization * I'll do the synchronization with the latest asxxxx version 5.0 in small steps: * sync with asxxxx 1.75 * sync with asxxxx 2.0 * sync with asxxxx 3.11 * sync with asxxxx 4.11 * sync with asxxxx 5.0 **Current status is somewhere between 1.75 and 2.0. Borut |
From: Borut R. <bor...@si...> - 2010-01-09 10:57:47
|
Hello sdcc developers, as you already know, I'm trying to synchronize sdas (sdcc assembler and linker) with the original asxxxx version 5.0. As described in my previous post with the same subject, I first took the "bottom-up" approach, gradually synchronizing the sdcc asxxxx version with the newer asxxxx versinos - verisin after version. But then I realized that asxxxx v5.0 already includes almost everything that was added to the asxxxx version v1.75, used as the base for sdas: gb, hc08 and ds390 targets support, noice, ... Now I think that it would be easier to take the asxxxx v5.0 and include the missing functionality (support for ar libraries, bit acces in bdata, ...). I already discussed this with Maarten Brock and he agrees with the proposed approach. Since I don't wont to (further) destabilize the current sdcc branch and snapshot builds, I propose to create a new branch, named sdas_v50, execute all the synchronization on that branch and re-merge it back to the main sdcc branch once it is stable enough. I would like to hear your opinion, specially if you don't agree with the proposition. Regards, Borut |
From: Borut R. <bor...@si...> - 2010-01-19 20:29:31
|
The branch is created. You can check it out with: svn co https://sdcc.svn.sourceforge.net/svnroot/sdcc/branches/sdas_v50 The sdas sources are already updated with asxxxx v50 version. sdas and sdld binaries compile without problems, but when they are used from sdcc, sdas reports erros due to syntax incompatibilities. Borut Borut Razem wrote: > Hello sdcc developers, > > as you already know, I'm trying to synchronize sdas (sdcc assembler > and linker) with the original asxxxx version 5.0. > > As described in my previous post with the same subject, I first took > the "bottom-up" approach, gradually synchronizing the sdcc asxxxx > version with the newer asxxxx versinos - verisin after version. But > then I realized that asxxxx v5.0 already includes almost everything > that was added to the asxxxx version v1.75, used as the base for sdas: > gb, hc08 and ds390 targets support, noice, ... > > Now I think that it would be easier to take the asxxxx v5.0 and > include the missing functionality (support for ar libraries, bit acces > in bdata, ...). > > I already discussed this with Maarten Brock and he agrees with the > proposed approach. Since I don't wont to (further) destabilize the > current sdcc branch and snapshot builds, I propose to create a new > branch, named sdas_v50, execute all the synchronization on that branch > and re-merge it back to the main sdcc branch once it is stable enough. > > I would like to hear your opinion, specially if you don't agree with > the proposition. > > Regards, > Borut |
From: Bodo W. <bod...@we...> - 2009-11-29 18:22:48
|
Hi Borut, > The final goal is to have one target independent sdld executable. Considering the main task of a linker, this is a good goal. Device dependent behaviour could be generalized into generic object code "commands" i.e. for different jump distances or several arithmetic resolvations. What do you think about 'linker scripts' like those used with GCC? These solve a lot of problems, and users can provide their own if they need some special memory layout. There could be a set of defaults for the standard cases built into the linker or at a certain place in the filesystem, similar to the default libraries. Despite the fact that I don't have time to contribute anything, I'm following the mailing lists' posts since a few years. My personal interest is twofold: First, to enhance SDCC to be usable for the ZX81, which uses a Z80 but is not allowed to use all registers. Second, as a 8051 compiler for a vintage battery charger system which is not developed due to my lack of time. Cheers, Bodo |