From: Richard E. <ed...@id...> - 2008-09-06 22:44:32
|
See below, please. regards, Richard Erlacher ----- Original Message ----- From: "Dave McGuire" <mc...@ne...> To: <sdc...@li...> Sent: Saturday, September 06, 2008 12:47 PM Subject: Re: [Sdcc-user] documentation & open source generally > On Sep 6, 2008, at 2:14 PM, Richard Erlacher wrote: >> I really wish you'd quit imposing your agenda on the discussion. > > That is not my intention. I have no agenda here other than to get > you to actually try SDCC instead of complaining about it. > >> This has >> nothing to do with the tools vs. workman issue, but, rather, has to >> do with >> the fact that just because the compiler doesn't produce the code >> the coder >> wanted, doesn't mean that there's a bug in the compiler. >> >> Further, the fact that a programmer, on occasion, abuses the language, >> doesn't mean that he's incompetent. It simply means he's committed an >> error. That's not grounds for banishment from the programmer >> community. > > Perhaps. I've written my fair share of bugs, as all of us have. > But if someone can't differentiate between a compiler bug and a bug > in their own program in a language as simple as C, then...well, > banishment would be my first choice. I tend to be somewhat > unforgiving of bad programmers. > How can you be so sure you're not among them? > >> The discussion, with the exception of the "wild-hares" you've >> occasionally >> chosen to pursue, is about the widely agreed-upon notion that the >> documentation is in dire need of repair/rework. > > And I agree as well. > >> There's nothing that can be >> done about the fact that objective documentation wasn't generated >> in advance >> of the coding. There's nothing that can be done about the fact >> that full >> and complete documentation was not provided at the outset. > > That's what I've been trying to get you to understand. It NEVER > is. That's not the way software is written. And if it ever was > written that way, it's a wonder we ever got out of that era. > Software development is an evolutionary process. It is very, very > different from other forms of engineering. > Maybe it's not done that way in your house ... not everywhere, though. However, successful software enterprises have, over the years, found that establishing requirements in advance of coding effort and insisting that they all be met before approving the software product is essential to good software practice. It allows multiple programmers to work toward a common goal, keeping everyone "on the same page." Not everything can be done ad-hoc. Small programs, perhaps, that can be produced by a single programmer working alone and taking responsibility for meeting all pre-imposed requirements, can be allowed to proceed without formal pre-coding documentation. Those requirements, however, must be recorded, so that the folks who will acceptance-test the work product can base their testing on the same criteria that the programmer has agreed to meet. > >> Now, I asked you a question several rounds ago ... Given what >> appears to be >> an acceptable ASM file, how would I use the assemblers, in this >> case the one >> for 805x-types, to generate a hex and an OMF file using the SDCC >> tools? >> What are the steps, in sequence, that I have to go through, under >> Windows, >> at a DOS prompt, from within a directory containing both the >> assembler and >> the source file, in order to get from my plain-text ASM file to the >> desired >> output? > > Here are some snippets from one of my projects. The project is a > four digit non-multiplexed Nixie tube clock based on a Philips > P89C660 microcontroller, which is an mcs51-architecture chip with an > I2C controller and some other peripherals on-chip. The firmware is > written in C, but I wrote an assembly language handler for the chip's > I2C subsystem. This is all done with SDCC v2.7.0. My Makefile > assembles that piece of code (using asx8051) to a relocatable object > module (.rel file) and then includes it in the link phase. Here is > the asx8051 command line I use to assemble this module. (I do this > via a Makefile) > > $ asx8051 -plosgff i2c_support.s > > This results in i2c_support.rel. The Makefile then compiles a > couple of C source files, generating .rel files for them as well. At > this point, with the C source files and the i2c_support.s assembly > language source file compiled/assembled to .rel files, (as you > probably know) there's no distinction between them. The final link > of those .rel files is done with a command line like this: > > $ sdcc --code-loc 0x2000 --data-loc 0x23 nixie-4.rel rtc.rel > entry.rel i2c_support.rel > ... and what is the significance of each of those apparent directives? Remember, I'm starting with an ASM file and not the output from the compiler. Where, if at all, are these directives documented, or, how did you find out what they are and when/why they're needed? > > This results in nixie-4.ihx, which I then run through packihx and > rename to nixie-4.hex. > > (The --code-loc and --data-loc options are specific to my code, as > I have some position-sensitive stuff in there like interrupt vectors > in assembly routines..) > > I've not yet used OMF51-format debugging support, but adding > --debug to your command lines should do the trick there. > > Let me know how it goes, and let me know if any other details on > my code or setup would be helpful. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL > ------------------------------------------------------------------------- |