this is the specification for the ladsoft variant of IEEE-695, given in
ASCII format.  Records are expected to conform to the IEEE specifications,
however, the contents and meanings of some records may differ.

The LADsoft Linker is not IEEE-compliant however, and may not accept
files formatted by other tools.  Also it does not presently do type checking.
There is liberal use of comment markers for a variety of purposes, and,
while debug info is according to the standard format the interpretation
of it may not.

The object file format used by ladsoft tools has the following general
layout

module begin record
processor specific stuff
date record
(optional) name of autodependency files
(optional) name of include files
header end record
section definitions
label definitions
symbol end record (pass 2 seperator)
type definitions
segment data
module end record.

Checksum records are interspersed at regular intervals.

When debug information is enabled, there is an extra section ??LINE which
holds line number information.  There are seven bytes per line, in the
following format:

	0 - byte index to file
	1 - word line number
	3 - dword address in code

The following sections outline the data in each part of the object file.

1) module begin record

MB<platform>,<CNT><filename>.

	platform - the target platform
	filename - the name of the source file

2) processor specific stuff

AD<mau size>,<number of maus in processor word>,<flag>.

	mau-size 	- normally bits/byte
	number of maus  - normally max bytes in largest integer data
	flag		- M = big endian, L = little endian

C0104,<flags>.
	flags	- architecture-specific flags

3) date record

DT<date>.

	date		- ascii representation of date file was translated

4) autodependency files

CO105,<CNT><NAME>.

	name 	- name of file

	the name in the MB record is not listed in this list.

5) include files

C0102,<CNT><NAME>.

	name	- name of include file

	include files are referrenced in the linnum segment starting from
	zero and in the order encountered.

	the name in the MB record is listed in this list.

6) header end record

C0101,<CNT><COMMENT>.

7) section definitions

for each section, we have the following records:

the section may be referenced at any time using the R<num> variable.

ST<num>,<attribs>,<CNT><NAME>.

	num - section number
	attribs - list of attribs
	name - name of section

SA<num>,<align>.

	num - section number
	align = alignment

ASS<num>,<size>.

	num - section number
	size - size of section

ASL<num>,<address>.

	this record ONLY comes as a result of linkage edition.

	num - section number
	address - the absolute address to load at.


In addition there may be a single assignment to the G variable.

ASG,<addr>.

	addr - a simple expression indicating where to start the code.
		ex:
		ASG,R1,2+.

8) label definitions.

There are three types of labels, globals, externals, and locals.

Each type of label has an associated variable that tells its location.
The variables, which are also used as types for some commands, are
as follows:

	I<num>	- global
	X<num>	- external
	N<num>	- local

There is an additional variable which may only be used in fixups on segmented
architectures (this is not part of the standard).

	Y<num>	- gives the R-value of the segment an external is located in


The following commands deal with labels

N<varname>,<CNT><NAME>.

	varname - the linkage name of the I X or N variable
	NAME	- the ascii equivalent


AS<varname>,<expr>.

	varname - the linkage name of the variable
	expr	- a simple expression telling where the variable is located

AT<varname>,<type>.
or ATN<num>,<type>,<filenum>.

The first form is used for global and external variables, the second form
is required to associate a local variable with a specific file.

	varname - linkage name of the variable
	num - the number of the N-variable
	type - either a debug type index or a T# variable which specifies
		an extended type.
	filenum - the number of the input file this is to be associated with


9) symbol end record

C0100,<CNT><COMMENT>.

10) type definitions

There are three components to type info.  All components must match
for two types to be compatible.  Not all components are in all type records.

components:
	debug type number or debug type constructor number
	IEEE type number
	IEEE local variable name.

If a debug constructor number is encountered, then one or more of the following
pieces of information are constructor-specific.

TY<num>,<list of components>.

we won't discuss ladsoft debug components here, except to indicate that
T0 (ieee type 0) is a match-all type.  Ordinal types do not need type
definitions as they are assigned debug type numbers.

11) segment data

SB<num>.
	num - number of section to put data in.

There are two types of section data supported.

LD<hex data>.

	hex data is a list of bytes (similar to the contents of a s-record)
	to be used directly.

LR(<expression>,<size>).

	this is a fixup record.  Expression must evaluate to the target
	location, and size must be the size of the fixup.  The location
	the fixup is applied to depends on the contents of previous LD and
	LR records, and the base of the section.  Note: LR and LD data
	specifiers NEVER specify overlapping data, the LR data is inserted
	into the data stream.

12) module end record.

ME.

13) checksum records

CS<num>.
	the negative sum of all non-control characters in the file
	from the beginning of the file (or last CS command). 

CS.
	clear the checksum to zero without checking for errors.