see below, please. regards,
Richard Erlacher ----- Original Message ----- From: "Art Clarke" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, September 07, 2008 7:17 PM Subject: Re: [Sdcc-user] documentation & open source generally > Richard Erlacher wrote: >> See below, please. > >> updated code, would work perfectly well, too. (using the term >> "perfectly" >> rather loosely) > > I think 'quite adequately' would be more accurate! > Probably so. > >> straight-lined bit of code, whichever seems appropriate. Of course, I >> couldn't do that with the SDCC assembler, as it doesn't support macros, >> so >> another mechanism would have to be used. > > You are using one tool out of a chain, that chain being specifically a > 'Small Device C Compiler'. > As it's sole reason for existing is to compile C code into something > that an MCU can use, why on earth would it support macros? > Actually I haven't used it myself at all. I've used ASEM-51 which is a macro assembler, and on my 'XP box it assembles a >4000-line block of ASM code into a .HEX file in the time it takes me to remove my finger from the <enter> key. The object code occupies somewhat over 8kB of code space. I find that adequate. In fact, I'd find anything to be adequate if it could perform its function in so short a time, namely by the time I remove my finger from the <enter> key. > > If you want an assembler for the target MCU there are a number of > options available, usually from the manufacturer of the MCU at little or > no cost. Some of them even support macros! > Of that I'm quite aware. > > Why keep on about the assembler within the SDCC tool chain not fitting > your narrow perspective of the world when it obviously was designed to > fit another (and possibly just as narrow) set of requirements? > I asked the question about the assembler, not because of the fact that I used macros in the specific piece of code to which I was referring, as I actually knew that the SDCC assembler couldn't process macros, but because I wanted, at the outset, to approach the problem of getting from text/source file to object file from the what I, and perhaps most others, perceive as the most basic path, namely .ASM => .HEX. As it turns out, that is actually not the shortest path if one uses macros, but that's also an important piece of information to have. If I were presenting a tutorial on SDCC, I'd begin with an ASM file and go from there. There seems to be no shorter process. Assemble, link, debug, fix ... you get what I mean. If there were a simulator that could handle more of the variants, perhaps that would be useful, too. Since I know a little bit about such things, perhaps I'll write one later on, as time allows. > > Unless I miss the mark more than usual, your background, training and > experience would give you a pretty good head start over many others in > writing documentation. > I recognize that. My somewhat obsessive/compulsive nature, where documentation is concerned, may also contribute. > > How about using it to pull together what is now available on SDCC? > I've mentioned a time or two that THAT is my specific goal. Pulling together the necessary information is not so easy, though, since most folks seem to feel that it's important to determine how to use these tools largely by experimentation. I've repeatedly pointed out that what's important is not how one CAN use the tools, but how they were intended to be used. There's also an important distinction between the use of SDCC under Windows and the use of SDCC under LINUX. I want to broach the Windows side of things first because I feel the doc is weakest there. > > Keeping in mind that it is a 'Small Device C Compiler', use that as a > basis to test (in C and using the whole tool chain) the accuracy of that > documentation, develop corrections for it and expand on it. > I've watched SDCC develop over the years since the mid-'90's when I encountered it in one of the then-popular newsgroups. The purpose for which I found it interesting was evaluating multiple processor cores for a given application. So far, I've not gotten to use it for that purpose. > > There will be quite a few people who will be grateful for such an effort. > > Art C > > ------------------------------------------------------------------------- ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
