We have been using CSI's Link product and have had problems with it
generating "extended" OMF-386 records that out emulator doesn't really
like and with the moving of initialized data from ROM to RAM. The CSI
product only seems to support generation of a "compressed" initialized
data segment for the ROM and a macro to "de-compress" it for inclusion
in the start-up code. While this approach is ideal for minimizing ROM
space, it really precludes being able to update the initialized data
from a running system even if the ROM is really a Flash ROM.
All thoughts and suggestions welcome. Thanks.
I wrote one for my own use, which I have distributed zero-price for
other people to use. You will find details on my web page.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
;-) steffen
James T. White schrieb:
> Would anyone care to share their thoughts on Linker/Locator programs
> (commercial, shareware, and freeware) for use in developing embedded
> 80x86 applications.
>
> We have been using CSI's Link product and have had problems with it
> generating "extended" OMF-386 records that out emulator doesn't really
> like and with the moving of initialized data from ROM to RAM. The CSI
> product only seems to support generation of a "compressed" initialized
> data segment for the ROM and a macro to "de-compress" it for inclusion
> in the start-up code. While this approach is ideal for minimizing ROM
> space, it really precludes being able to update the initialized data
> from a running system even if the ROM is really a Flash ROM.
>
> All thoughts and suggestions welcome. Thanks.
I've been using Borland C 4.5 , Borland-TASM 3.1 and Paradigm Linker and
Locater (Version 5.1) .
It works fine !
;-) steffen
--
----------------------------------------------------------------------------------
Steffen Ziemann
Software+Systeme Erfurt GmbH Telefon: +49 36203 96343
Fichtenweg 8 Fax : +49 36203
96333
D-99198 Erfurt-Kerspleben E-Mail:
Steffen...@sse-erfurt.de
----------------------------------------------------------------------------------
> Would anyone care to share their thoughts on Linker/Locator programs
> (commercial, shareware, and freeware) for use in developing embedded
> 80x86 applications.
>
> We have been using CSI's Link product and have had problems with it
> generating "extended" OMF-386 records that out emulator doesn't really
>
> like and with the moving of initialized data from ROM to RAM. The CSI
>
> product only seems to support generation of a "compressed" initialized
>
> data segment for the ROM and a macro to "de-compress" it for inclusion
>
> in the start-up code. While this approach is ideal for minimizing ROM
>
> space, it really precludes being able to update the initialized data
> from a running system even if the ROM is really a Flash ROM.
>
> All thoughts and suggestions welcome. Thanks.
I have found that most of these 1/2 measures ( hack's to get
dos/win32 compilers to work on embedded apps) are at best mediocre.
The best system that I have used and I find it to be an excellent all
round teaching tool as well, is the Hitech 80x86 embedded development
environment .
It has an IDE and is stacked with features.
Its primary function is as an embedded IDE for x86 systems.
check out .. http://www.hitech.com.au
They seem to have a cut down version available ...
>James T. White schrieb:
>
>> Would anyone care to share their thoughts on Linker/Locator programs
>> (commercial, shareware, and freeware) for use in developing embedded
>> 80x86 applications.
>
>I've been using Borland C 4.5 , Borland-TASM 3.1 and Paradigm Linker and
>Locater (Version 5.1) .
How did you cope with the different debug info format used by tools
version 3.1 and 4.5? Or you didn't use Turbo Debugger at all?
TIA
____________________________________________________________
Evandro Menezes Austin, TX USA
Tel:+1-512-502-9199 ICQ:7957253
mailto:eva...@geocities.com http://over.to/evandro
Bob McConnell
>I have also used a program first published in the Jan. 90 issue of Dr.
>Dobb's. The article was titled "Location is Everything", I believe the
>author was Mark Nelson. I got the source from the CD/ROM, but it
>should be an any of the DDJ archive mirrors. I have used it with both
>MSC 5.1/MASM 5.1 and MSC 6.0/MASM 6.0 combinations. It should
>also work with the Borland compilers, since it converts the EXE file.
>
>Bob McConnell
There is also the free locator by Rick Naro (of Paradigm) with source
available at:
http://www.esl-hub.demon.co.uk/embed/808x/index.htm
This stuff used to be kept at the Ausonics site but that's now dead.
Ken.
>> Would anyone care to share their thoughts on Linker/Locator programs
>> (commercial, shareware, and freeware) for use in developing embedded
>> 80x86 applications.
>I wrote one for my own use, which I have distributed zero-price for
>other people to use. You will find details on my web page.
You can get ftp://ftp.worcester.com/pub/joe/alink.tar.Z
It includes source. Here is the readme file:
Absolute Linker Program
Version 1.0
INTRODUCTION
This program accepts MS-DOS .OBJ and .LIB files and an entered set
of absolute segment addresses and generates a simple binary image file
suitable for use as a .COM file, ROM, boot program or device driver. Most
(all?) standard MS-DOS linkers can only generate a contiguous image which is
less than 64K and which begins at 0. This program can generate any size
image (any memory model may be used) and each segment in the image can be
placed anywhere in the 1MB memory map.
COMPILING
Compile under UNIX or in MS-DOS compact model
COMMAND FORMAT and OPERATION
alink [-q] [-o outputfile] [-l listingfile] files
'-q' Quiet mode: Suppresses messages
'files' List object file and library file names. Also, text files
containing whitespace separated lists of more file names may be
specified
After the command is invoked, it displays a list of the segments and class
groupings on the output. You then enter segment positioning data in this
format:
XXXXX[,YYYYY] list
Where:
XXXXX is a absolute 20-bit address in hexadecimal indicating where the
segments in the list are to be linked.
YYYYY is an optional load address if it's to be different from the link
address.
list is the names of the segments. If a class name is given, all
the segments in the class are specified. Private segments may
also be specified by giving them in this format: SEGMENT(MODULE)
EXAMPLES
To generate a .COM file using Turbo-C:
test.c: main() { printf("Hello world\n"); }
>tcc -c -mt test.c
>alink -o test.com c0t.obj test.obj cs.lib
Segments: _TEXT _BSSEND _EMUSEG _SCNSEG _BSS _CRTSEG _DATA _CVTSEG
Classes: 'BSS'(_BSS) 'STACK'(_BSSEND) 'DATA'(_EMUSEG,_DATA,_SCNSEG,_CRTSEG,
_CVTSEG) 'CODE'(_TEXT)
>0 CODE DATA BSS STACK
Example of embedded system. The linker says:
Segments: _TEXT _SCNSEG _BSS _DATA _CVTSEG _START(c0t.asm)
Classes: BSS(_BSS) DATA(_DATA,_SCNSEG,_CVTSEG) CODE(_TEXT)
Then you could respond with:
> 00000 BSS
> 0F000 _TEXT DATA
> FFFF0,FFF0 _START(c0t.asm)
This would be appropriate for burning a 4K ROM for an embedded system where
only 16-bits of address decoding are present and where 32K of RAM exists at
address 0 and where the ROM exists at address 0F000. The private segment
'_START(c0t.asm)' could be this:
_START segment byte
assume cs:_START
xor ax,ax
mov ds,ax
mov ss,ax
mov sp,08000H
jmp FAR PTR _main
_START ends
- A simple startup routine for a Turbo-C program. Since the upper 4 bits of
the address are ignored, the ROM exists at 0F000 as well as FF000. You want
the startup code to be linked for FFFF0 (the reset CS:IP value) therefore,
but to be placed at 0FFF0 in the image.
FEATURES/RESTRICTIONS
* The first byte of the generated output file is the first byte
generated, not address 0 (unless code or data are generated there).
In the above example, the first byte of the output file is address
0F000 and the output file is 4K in size.
* A very detailed listing including a symbol cross-referencing listing
and a list showing where each module is placed is generated if the
'-l' option is used.
* All symbols are case sensitive
* There is no limit to the size of the binary image file EXCEPT that
all of the generated code for it must fit in RAM when the linker is
running (I.E., the entire 1MB image does not have to fit in ram if
4K is generated at 0 and 4K is generated at FF000).
* No error checking is performed on external references.
If an external reference is out of range, an invalid address will
be generated.
* Segment overflow, group overflow and segment overlap checking is
performed, however.
* 32-bit 386 code is not supported. If someone knows the format of
the 386 .OBJ file records, please send it to me so I can eliminate
this restriction.
* Works on Xenix for Xenix .o files as well.
Joseph H. Allen (jha...@world.std.com)
--
/* jha...@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Oops; that's ftp://ftp.worcester.com/pub/joe/alink.zip
Am currently using the Concurrent Sciences (CSI) linker. It is very good,
especially if you're
doing protected mode programming. It creates TSS, GDT & IDT tables
automatically. It also
can automatically compress code & data and supplies a few macros that can be
used during
startup tp easily relocate code & data to ram from rom.
Hope this helps.
Joe Cossette
Syzygy International Corp.
http://www.syzygycorp.com/syzygy/