>>Why didn't it work before - with Intel's linker? What's the
>>difference in the function between Intel's linker and other linker?
>
The Microsoft .obj format is a mutilated subset of the
original Intel iAPX86 Relocatable Object File Format.
The DOS linkers do two operations at one time: bind
different object modules together and locate them
to pre-determined memory addresses (almost). The
canonical offset part of the address will be located,
but the segment part is relocatable relative to the
file start. If the ultimate target is a .com file,
there must be no segment relocations left in the .exe
file, so it can be converted to a .com file with the
exe2bin utility.
The Intel relocation scheme separates the linking
and locating steps: there are two utilities: link
and locate. Link binds the relocatable modules
together and produces a bound, still relocatable
output file in the same .obj format. Locate locates
the relocatable sections (or some of them) in the
input file and outputs a located file in the
.obj format. The located file can later be bound
with other files to create e.g. overlays or
system ROM calls.
The Microsoft and Intel object formats are not
entirely compatible. With some limitations, it is
possible to write a converter for transforming
an Intel file to the Microsoft format for final
linking with a DOS linker.
HTH
Tauno Voipio
tauno voipio @ iki fi
PS. 'No start address' means that you have not specified
the program starting point in the 'end' directive of the
main module.
TV
Reply by Anthony Fremont●April 1, 20042004-04-01
"PISZCZ, Bogdan"
> One more question:
> Why didn't it work before - with Intel's linker? What's the difference
in
> the function between Intel's linker and other linker?
The version of the Intel linker that you have doesnt know how to do
this:
http://www.iro.umontreal.ca/~feeley/cours/ift2240/doc/assembly/programsegmentprefix.html
The compilers and assemblers produce raw object code that is not yet
ready to load into memory. Unless otherwise specified within the
module, the object code will expect to be loaded starting at memory
location 0. Modules may also contain references to other modules, but
the compiler/assembler doesn't yet know where these other modules will
be loaded into memory. The OS (if present) also needs a mechanism to
enter/exit your main module. The linker must perform all these
functions and more.
Reply by Hans-Bernhard Broeker●April 1, 20042004-04-01
PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:
> Nevertheless, both, the TASM linker and the MASM 6.11 linker produce the
> warning "no stack segment" or "no stack", respectively.
IIRC, that warning is expected if you're building a tiny-model program
in raw assembler without specifying you want to build a .com program.
And it's harmless.
> Regarding the warning "program has no starting address" (produced
> only by MASM 6.11 linker): doesn't the OS locate the program in the
> memory (i.e. assign the program its starting address)?
That missing "starting address" is the ORG statement you've been told
about before.
> Why doesn't the TASM linker complain either?
Because it's designed to allow sloppier coding. It even says so in
its manual somewhere. I.e. if you omit some setting, it'll just
assume you meant the usual value of that setting.
> Why didn't it work before - with Intel's linker? What's the
> difference in the function between Intel's linker and other linker?
They're different linkers, written at different times by different
people. Which means they're *completely* different, probably. Asking
for individual differences doesn't really make sense in that
situation.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
>>> What I don?t understand: how can an ASCII file run on a processor,
>>> with or without OS?
>>
>> It isn't. It's converted back into binary before being run.
>>
>
>
>Why isn't a binary file transferred straight to the microcontroller,
>without being subjected to an interim (hexadecimal or ASCII) form
>convertion?
You need some kind of protocol for transferring the program from the
development system to the target system. How would the target system
know when the data starts and when it ends, how do you specify load
addresses to the loader etc. if you only have a blob of bytes ?
Those old HEX formats were developed when paper tapes were common. If
you are transferring the 0x00 byte in binary, how do you know when
this is actual data and not part of the blank leader or trailer ?
Instead of dedicated tape punches and readers with some kind of
parallel interface, it was quite common to use a Teletype with a paper
tape punch to generate the tape and transfer the tape to an other
Teletype paper tape reader or a dedicated paper tape reader to load
the program each time the target system was started. The Teletype only
had 7 bits+parity, so how would you transfer 8 bit bytes ?
Later on the serial port --> Teletype --> paper tape -->Teletype -->
serial port chain was replaced by direct serial port --> serial port
connection without changing the protocol.
Paul
Reply by Ben Bradley●April 1, 20042004-04-01
In comp.arch.embedded, "PISZCZ, Bogdan" <b.piszcz@t-online.de> wrote:
>On 31 Mar 2004 03:48:40 GMT, Grant Edwards <grante@visi.com> wrote:
>
>> On 2004-03-31, PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:
>>
>>> But the .hex file is loaded into memory and launched on an embedded
>>> system.
>>
>> Then there's a loader program running on the embedded system
>> that's converting the hex file back into binary before running
>> it.
>>
>>> What I don?t understand: how can an ASCII file run on a processor,
>>> with or without OS?
>>
>> It isn't. It's converted back into binary before being run.
>>
>
>
>Why isn't a binary file transferred straight to the microcontroller,
>without being subjected to an interim (hexadecimal or ASCII) form
>convertion?
>
>There is no point in converting a binary file (filename without extension
>in the pertaining case) into a hexadecimal ASCII file (filename.hex) and
>then back into a binary file, isn't it?
Yes, but these object files have traditionally (a long, long time
ago, in a development system far, far away) been put on various media
such as punched paper tape (IIR it was 7 bits, or if 8, it was used as
7-bit ASCII with the 8th bit unused or used for parity), and errors
were quite possible in the transfer to the final device (processor RAM
or EPROM, emulator or EPROM programmer). The Intel hex, Motorola 's'
and other such formats have checksum bytes at the end of each 'block'
so a problem such as a dropped bit was at least detected.
But you're right, nowadays everything is on 'reliable' media (such
as floppy disk or tcp/ip networks) that have their own CRC checks, so
binary files will work fine. Only an old fart would know why those
.hex files were ever used.
I remember the first Z8 OTP I tried to program, when they were
about $15 each. I really felt awful when I saw I had programmed it
with an image of the .hex file. I knew better, but somehow I had
picked the wrong option on the programmer.
On 31 Mar 2004 03:48:40 GMT, Grant Edwards <grante@visi.com> wrote:
> On 2004-03-31, PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:
>
>> But the .hex file is loaded into memory and launched on an embedded
>> system.
>
> Then there's a loader program running on the embedded system
> that's converting the hex file back into binary before running
> it.
>
>> What I don?t understand: how can an ASCII file run on a processor,
>> with or without OS?
>
> It isn't. It's converted back into binary before being run.
>
Why isn't a binary file transferred straight to the microcontroller,
without being subjected to an interim (hexadecimal or ASCII) form
convertion?
There is no point in converting a binary file (filename without extension
in the pertaining case) into a hexadecimal ASCII file (filename.hex) and
then back into a binary file, isn't it?
Bogdan
Reply by PISZCZ, Bogdan●March 31, 20042004-03-31
On Wed, 31 Mar 2004 11:16:01 +0200, Arash Salarian <arash dot salarian at
epfl dot ch> wrote:
> Your problem is obviously with the linker. It is the linker that produces
> the .exe file and nothing else can do it. Now, I don't have intel's
> linker
> but in dos world and x86 domain, you can use ANY linker (microsofts' or
> borlands' link program) to link your intel .obj files and make an exe.
Well, I took other linkers, and ...
... IT WORKS !!!!!!!!!!!!!!!!!!!!!!!!!
Thank you very much!
(Are you a Guru? :-) )
Nevertheless, both, the TASM linker and the MASM 6.11 linker produce the
warning "no stack segment" or "no stack", respectively. Furthermore: the
MASM6.11 linker produces another warning: "program has no starting
address" but in spite of that the program does run properly (in both
cases). However, in my source code I did initialise both, the stack
segment and even the top of the stack although, I think, both
unnecessarily (what for should I initialise the stack segment, if I don't
use it?). But this initialisation doesn't prevent the linkers from
producing the warnings.
Regarding the warning "program has no starting address" (produced only by
MASM 6.11 linker):
doesn't the OS locate the program in the memory (i.e. assign the program
its starting address)?
Why doesn't the TASM linker complain either?
One more question:
Why didn't it work before - with Intel's linker? What's the difference in
the function between Intel's linker and other linker?
Bogdan
Reply by George Neuner●March 31, 20042004-03-31
On Wed, 31 Mar 2004 02:06:51 +0200, "PISZCZ, Bogdan"
<b.piszcz@t-online.de> wrote:
>On Tue, 30 Mar 2004 15:33:45 +0200, Meindert Sprang
><mhsprang@NOcustomSPAMware.nl> wrote:
>
>> An .exe program starts at 0000h. And this is default when no .ORG is
>> given.
>> Only a .com needs to be a 0100h.
>>
>> Meindert
>
>I was also before aware of the fact, that an .exe at 0h and a .com at 100h
>starts. But what causes the program to start at the one or at the other
>one address? Is it only the .exe or the .com extension or are there other
>mechanisms? Are there more differences between them?
>
EXEs don't start at address 0h, they are "relocated" by the system
loader (see below). COM files are a historical relic which predate
modern compiler and OS features such as relocatable code and virtual
memory.
DOS divides memory into 16 byte "paragraphs", an address is computed
by ((segment * 16) + offset). Both the segment and the offset are
16bit values, but DOS is (historically) limited to the 1MB address
space of the 8086.
The first few kilobytes of RAM are reserved by the BIOS and by DOS.
100h:0h (((256 *16) + 0) = 4096) was initially picked as a known safe
place to load a program. You can specify other load addresses as long
as you know the target memory is unused.
COM files are limited to one 64KB segment for code and a total of 64KB
for all program data (static and runtime) and the runtime stack. They
are written using the small address model (16bit pointers) and are not
relocatable (though the code may be position independent).
EXE files can have multiple code and static data segments and can be
written using any address model appropriate for the processor and
operating system. EXE files are relocatable - the files contain
addtional information which allows the operating system to put the
code and static data anywhere in memory and to patch the code so it
will run wherever it is located.
EXE files are far more flexible than COM files and you should use them
if your application is intended to run under an operating system.
George
==============================================
Send real email to GNEUNER2 at COMCAST dot NET
Reply by John Atwood●March 31, 20042004-03-31
PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:
>On Tue, 30 Mar 2004 15:33:45 +0200, Meindert Sprang
><mhsprang@NOcustomSPAMware.nl> wrote:
>> An .exe program starts at 0000h. And this is default when no .ORG is
>> given.
>> Only a .com needs to be a 0100h.
>
>I was also before aware of the fact, that an .exe at 0h and a .com at 100h
>starts. But what causes the program to start at the one or at the other
>one address? Is it only the .exe or the .com extension or are there other
>mechanisms? Are there more differences between them?
>
>Do you know a web site or a paper printed documentation about this item?
>Could you mail it to me (the latter as scanned picture, for instance, or
>the author and title) ? – Thanks
Search for "Program Segment Prefix"
might also help to learn to use debug.
John
Reply by Arash Salarian●March 31, 20042004-03-31
> > LINK86 FILE.OBJ TO FILE.EXE EXE
> >
>
> Now, I've also tried with the linker option "exe", but my link86 (version
> 2.7) doesn't support such an option -it produces an error massage.
>
> Is there any newer version of link86, which does support this option?
> Could you mail it to me?
>
Your problem is obviously with the linker. It is the linker that produces
the .exe file and nothing else can do it. Now, I don't have intel's linker
but in dos world and x86 domain, you can use ANY linker (microsofts' or
borlands' link program) to link your intel .obj files and make an exe. I'm
sure you can find TASM or MASM much more easily on the web and then you can
only use the link program if you really want to keep with ASM86 syntax. The
options for the linker are different but there are lots of resources on web
for theses programs.
However, my suggestion is to switch to TASM ro MASM. The reason is after a
while you'll realize that they are actually the standard by which 99.9% of
ASM progams for DOS has been written and virtually any resource you find on
web, like source codes or libraries are for these assemblers and ASM86 is
something nobody actually use.
Regards
Arash
ps. You may look for ASM386 as well. If you find it, the linker that comes
with it should solve your problem.