On Sep 6, 2008, at 6:43 PM, Richard Erlacher wrote:
>>> 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?
I'm just going to ignore that, if you don't mind.
>> 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.
In my house? I'm a professional software developer, and have been
for many years. I've worked for quite a few companies, and have
never seen the methodology you describe seriously employed.
Furthermore, I know quite a few other professional developers, and
many of them have assured me that you're quite full of crap on this
topic. Those assurances came during the lifetime of this thread as
well as during the exact same conversation that occurred on the
classiccmp list back in 2001.
> 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.
Just because something isn't planned to death before it even
begins doesn't mean it is "ad hoc".
>> 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?
The --code-loc and --data-loc directives should be self-
explanatory, but if they aren't, they're in the SDCC documentation.
The "-plosgff" directives given to asx8051 are documented in the
"usage" screen output if you type "asx8051" with no parameters. They
control listing file generation and formatting, and treatment of
symbols. There's no black magic there; they are fairly straightforward.
Let me know how you make out.
-Dave
--
Dave McGuire
Port Charlotte, FL
-------------------------------------------------------------------------
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
