See below, please. regards,
Richard Erlacher ----- Original Message ----- From: "Dave McGuire" <[EMAIL PROTECTED]> To: <sdcc-user@lists.sourceforge.net> Sent: Sunday, September 07, 2008 12:34 AM Subject: Re: [Sdcc-user] documentation & open source generally > On Sep 6, 2008, at 8:18 PM, Richard Erlacher wrote: >>>>>> 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. >>> >> I hoped you would ... I just had to get in a jab. > > Yeah, yeah. ;) > >> When I worked in the aerospace/defense industry, they did things >> that way >> too. The same methodology is used in most of the client companies I >> support. People just don't seem to rely much on pulling things out >> of the >> *ss as they may have done in the past. > > So anything short of planning something absolutely to death > constitutes pulling it out of your ass? > > Space shuttle firmware is one thing. That's, what, less than > 0.0001% of the world's software? Seriously. > Not everything done by NASA or anyone else in the aerospace/defense industry is as thoroughly tested as space-shuttle firmware. It's arguable, however, that anything other than a recreational (toy) product should be. In any case, it should be firmly specified before any work is begun, because, if it's not, you won't know what you're working on. > >>> 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. >>> >> How does this relate to assembling a single, monolithic module of >> ASM code >> to generate the required .hex and .omf output? Handling >> relocatables and >> linking them would come later, wouldn't it? Doesn't one have to crawl >> before one walks? > > No, you've got it backwards. Intel hex files contain absolute > addresses, so they must be at the very end of the compiler/assembler > tool chain. (I can't speak to OMF files as I know nothing about > them) Since the assembler doesn't know if the file it's currently > processing is going to be the only file in the project, it can't > assign absolute addresses, and thus only knows where things are if > there's an ORG statement somewhere. This (usually) means that an > assembler that also inextricably does (what we're calling) the link > phase also, can only ever assemble one file at a time. That makes it > pretty difficult to use for anything but the smallest projects, > unless you (ab)use some sort of "include" directive to death. > Yes, .hex files contain absolute addresses. My code has absolute addresses in the .org assignments, too. I can't argue with what you say here, as it's quite true. If an assembler is supposed to produce relocatable code, that necessitates that it feed its output to a linker. I simply was unaware that the SDCC assembler ONLY produces relocatable code. So far, I haven't encountered anything in the doc that suggests that. Since small microcontrollers only require the "smallest" size code body, having only a tiny code space, I'd likely only write small (< 30K lines), single-module monolithic code for 'em. There are a few that support larger (>=256kB) progam stores, and those might be better addressed with multiple modules located at link time. Large code memory (>1MB) would certainly justify such practice. Now, what I've done with the tools I've used so far, has been to set switches to indicate whether absolute or relocatable code was to be generated. There are, of course, many ways to skin this particular cat. If one wants an assembler that's primarily to be used with a compiler and subsequent linker, then it's unnecessary to support such mode switching. In any case, my goal, in this case, is not so much to discuss how things should be, or might be, but rather how they are. I think you've made that clear, in part, at least. > > -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
