see below, please. regards,
Richard Erlacher ----- Original Message ----- From: "Richard Gray" <[EMAIL PROTECTED]> To: <sdcc-user@lists.sourceforge.net> Sent: Thursday, August 28, 2008 6:40 AM Subject: Re: [Sdcc-user] Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > On Thursday 28 August 2008 12:52:37 Richard Erlacher wrote: >> see below, please. >> >> regards, >> >> Richard Erlacher > <snip> >> Not quite ... that is, not from the extremely basic level. For example >> ... >> Assume that I have code that runs in another environment and now I want >> to >> compile it into an executable for my MCU. I'm staring at a Windows >> Desktop >> ... now what? The <3.13.1 A Step by Step Introduction> refers to inline >> assembly language code. Maybe a few words about where to start would be >> a >> good thing. > > There is a PDF manual included in the distribution, and an HTML one too in > the > linux/unix distribution at least, but I wouldn't describe it as "step by > step", and is at best a nudge in the right direction. If you want a PDF > version I'll happily mail it to you if that would help? The manual does > describe how to create inline assembler, interrupt routines (including > NMI's), and other little gems. > That's true. There's a PDF version available, and Frieder referred to that. I have it, of course. It says little about how, under Windows, the directories are organized, though it does say, "the default directory for gcc-builds where include, library and documentation files are stored is now in /usr/local/share." Is that relevant? > > Much more can be learned from examining the supplied .h files (and example > files, in some cases) for the target architecture you're using. I've only > recently started using the Z80 (Z180 variant) target, and much of what > I've > learned is from experimentation. I started with the Z80 back when it was pup, in '76 or so. It wasn't my first CPU. Aside from a little fiddling with it under CP/M, I've never written any 'C' code for it. My work was all done in ASM. I don't use it any longer, however, as nobody's asked me to do that. I do use old Z80 hardware to stimulate systems under test, when it seems appropriate, though that's been a while, too. > I have found that except for the most > trivial programs, you will need to break your work down into separate > assembler sources and then assemble and link everything at the end. The > load > map file is absolutely invaluable and I would always urge anyone to > examine > it thoroughly, and even an examination of the emitted hex file wouldn't > hurt > either. > If it weren't for that admonition to "read the code" ... Everybody thinks their code is "self-documenting" though ... and it seldom is. 'C' programmers seem to pride themselves on how unreadable and impenetrable their coding style is, and while the originators of the language provided a mechanism for providing relevant and meaningful comments, it's used very little. The problem begins and ends with the fact that code should never precede a completed, approved, set in stone, set of documentation. It seldom does, which is why there are bugs ... er ... I mean ... undocumented features ... discovered in nearly any software set from time to time. Now, SDCC is a great concept if, for example, it's easy to integrate with an assembler, a linker, a simulator, a librarian, and all the other utilities that are helpful in developing code. I've taken a look at it at about annual intervals, and wish it were so. I just learned that the SiLabs environment (IDE) without which it's apparently a pain to use their MCU's, relies upon OMF files produced by SDCC tools, among others. That's why I'm taking another look. The small bits of code I usually prepare for the 805x-series (up to, say, 12k-15k lines of ASM) are generally monolithic, hence, don't require the linker, etc. Up to now, I've written code segments and de-loused them separately, since the things I do, though sometimes bigger than 8kB of object code, are seldom terribly complex. After that, I simply combine those portions of code as macros or as subroutines. > > As for C, Kernighan and Ritchie's ANSI C is probably regarded as the > defininitive reference. > > http://en.wikipedia.org/wiki/The_C_Programming_Language_(book) > Yes, I have a couple of versions of that, the printed versions, I mean. I used Turbo-C back when Borland was just starting up, and later in combination with Prolog. You can't escape K&R when learning 'C' even though it's no longer the standard. > -- > > ------------------------------------------------------------------------- ------------------------------------------------------------------------- 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 Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
