From: Richard E. <ed...@id...> - 2008-09-07 16:55:18
|
See below, please. regards, Richard Erlacher ----- Original Message ----- From: "Dave McGuire" <mc...@ne...> To: <sdc...@li...> Sent: Sunday, September 07, 2008 12:41 AM Subject: Re: [Sdcc-user] documentation & open source generally > On Sep 7, 2008, at 12:58 AM, Richard Erlacher wrote: >>>> Most of the assemblers I've used over the years do exactly that, as >>>> they're >>>> processor-specific and not intended for use together with other >>>> tools. >>> >>> This is actually rather rare. Yes, it does happen (CP/M's >>> assembler comes to mind) but it's not the norm. >> >> There were several assemblers associated with CP/M, namely ASM, >> MASM, M80, >> MAC, and RMAC. IIRC, RMAC produced rel files that fed L80, the >> linker. > > Yes, and while I'm a CP/M fan and probably always will be, that's > thirty-year-old technology. Things have evolved considerably since > then. > While some new strategies for database processing have evolved, those old assemblers, linkers, etc, all seem to work just as well today as they ever did. Since MCU programs tend to be quite small, there's no need for such things as assemblers, linkers, etc, to evolve. They already work very well, and needn't be "fixed." > >> Wasn't it kind-of similar in the PC-DOS environment? I didn't use >> TASM (BORLAND) more than once or twice. What did it do? > > I was never much of a PC programmer, but TASM definitely produced > relocatable object modules, but you could hard-code the addresses > with an origin statement if you wanted to. Pretty much the same as > asx8051. TASM didn't produce executables directly; it was shipped > with TLINK that produced .COM and .EXE files from .OBJ files. As it > turns out, TLINK was useful for lots of different types of > development (I used it with Clipper, a dBase compiler) in which the > compiler (or assembler) produced relocatable object modules. > >> I think all its outputs >> were page-relocatable based on segment boundaries. All that stuff >> was so >> automated that one didn't have to "know" anything. > > Its output files were fully relocatable, not restricted to segment > boundaries. However, you could fake it if you wanted to, even if > your .OBJ files were assembled from source files which contained > explicit origin statements, by changing the segment registers outside > of the module. > >>>> So you're saying this one isn't able to generate .hex and >>>> .omf files directly, is that right? >>> >>> The assembler? No, it's not. That's the linker's job. >>> >> That surprises me only because the ASEM-51 that I've been >> using generates the hex and debug (OMF) files directly. >> It's newer than the SDCC assembler. > > Yes, that part surprises me. How would one build a project with > multiple source files, without needing to explicitly specify the code > origin in each one, and without assembling all of the files in a > single invocation of the assembler (if it can do that)? > The key, I guess, is to recall that MCU's have very small code memory, so it's not inconceivable that one would write the code as a single module. > >>>> Do you know of any assemblers, not associated with one >>>> compiler or another, that behave in this way? I've not encounterd >>>> them, >>>> though I've used numerous compiler/assembler/linker/debugger >>>> suites. I'm >>>> sure I've got at least a half-dozen assemblers that simply take a >>>> source >>>> file and produce .hex or, in the case of MOT processors, .s19 >>>> output. >>> >>> I've got a few myself. None that are at all recent, though. >>> >> I doubt any new instructions will be added, since there are >> only one or two empty spaces in the instruction map. >> It's been like that for decades, so there's been no need for >> "new" assemblers. > > Touche', and point well taken. But not many people develop > production embedded software under CP/M these days...although we > could if we wanted to. ;) > I don't use CP/M aside from the box that spools serial I/O to one of the plotters. > >> SDCC has been around since the mid-'90's hasn't it? The >> assembler SDCC uses is older than SDCC, isn't it? > > Yes, the assembler suite (if memory serves) originally came from a > PDP-11 implementation running under RT-11. That gave me a big smile. :) > > -Dave > It's quite common to see traces of DEC software in assemblers, linkers, etc, as so many people had access to the sources, and so many people actually understood how they work. CP/M was said, by some, to be based on OS-8. I gave away my 8" source diskettes for OS-8 some years back, since I didn't have the DF32's for which it was apparently designed. My understanding was that, when CP/M was being designed, half the winos on skid row could "drive" OS8, as it was so widely used. That made its console interface very attractive. I'm not sure that's true, however. > > -- > Dave McGuire > Port Charlotte, FL > |