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.
> 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)?
>>> 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. ;)
> 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
>
--
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
