Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"LINKER", a program found on Asimov's "EDASM.DSK"
107 views
Skip to first unread message
A2CPM
Apr 9, 2012, 12:51:22 AM4/9/12
to
Hi, y'all!
First of all, if you're going to play with "LINKER", do NOT just
launch it. First, launch "EDASM.SYSTEM". Then, enter 'EXIT LINKER'.
If you start "LINKER" without going through "EDASM.SYSTEM", any error
messages issued by "LINKER" will disappear before you get to read
them. I wasted LOTS of time before I finally figured that one out.
After displaying a title, "LINKER" will prompt you with "COMMAND
FILENAME?". You must respond with the name of a previously prepared
text file that contains the names of 'REL' files to be linked together
plus optional command lines. Command lines can contain one of the
following commands: 'BIN', 'REL', 'SYS', 'OPT', 'ORG' or 'ALN'. These
commands must NOT start in column one of a command line and MUST be
upper case. I must have spun my wheels for a couple of days because I
assumed that the commands in command lines would be converted to upper
case and I did NOT check the code to see if such a conversion actually
took place. A classic case of "assume" makes an ass out of me. (not
U, of course).
'BIN', 'SYS' or 'REL' probably must be the first command line, but
I need to check that this is true. 'REL' doesn't make much sense to
me because, if you're linking 'REL' files together, why designate the
output file as a 'REL' file. 'ALN', when placed ahead of the name of
a 'REL' file, will force the data in the file to be aligned to a 256
byte boundary. I have not yet played with the 'ORG' or 'OPT'
commands. The 'ORG' command probably works as you would expect. The
source for "LINKER' contains a table for use with the 'OPT' command
that consists of the letters 'M', 'E', 'S', 'X', 'N', 'D' and 'P'.
'M' controls the generation of a map file. The default is to generate
this file and the default name is "EDASM.LINKMAP. The exact syntax of
the 'OPT' command is not known to me, at this moment. Oh, yeah, you
may have a problem viewing the map file if you don't print it because
it contains formfeed characters.
More later, after I've had some rest...
Willi
First of all, if you're going to play with "LINKER", do NOT just
launch it. First, launch "EDASM.SYSTEM". Then, enter 'EXIT LINKER'.
If you start "LINKER" without going through "EDASM.SYSTEM", any error
messages issued by "LINKER" will disappear before you get to read
them. I wasted LOTS of time before I finally figured that one out.
After displaying a title, "LINKER" will prompt you with "COMMAND
FILENAME?". You must respond with the name of a previously prepared
text file that contains the names of 'REL' files to be linked together
plus optional command lines. Command lines can contain one of the
following commands: 'BIN', 'REL', 'SYS', 'OPT', 'ORG' or 'ALN'. These
commands must NOT start in column one of a command line and MUST be
upper case. I must have spun my wheels for a couple of days because I
assumed that the commands in command lines would be converted to upper
case and I did NOT check the code to see if such a conversion actually
took place. A classic case of "assume" makes an ass out of me. (not
U, of course).
'BIN', 'SYS' or 'REL' probably must be the first command line, but
I need to check that this is true. 'REL' doesn't make much sense to
me because, if you're linking 'REL' files together, why designate the
output file as a 'REL' file. 'ALN', when placed ahead of the name of
a 'REL' file, will force the data in the file to be aligned to a 256
byte boundary. I have not yet played with the 'ORG' or 'OPT'
commands. The 'ORG' command probably works as you would expect. The
source for "LINKER' contains a table for use with the 'OPT' command
that consists of the letters 'M', 'E', 'S', 'X', 'N', 'D' and 'P'.
'M' controls the generation of a map file. The default is to generate
this file and the default name is "EDASM.LINKMAP. The exact syntax of
the 'OPT' command is not known to me, at this moment. Oh, yeah, you
may have a problem viewing the map file if you don't print it because
it contains formfeed characters.
More later, after I've had some rest...
Willi
MarkLim
Apr 9, 2012, 9:18:14 AM4/9/12
to
Let me add on to what Willi had written.
In 1987 Call-A.P.P.L.E. published a series of articles by Bob Bishop
on how to write relocatable code using EdAsm. The linker loader used
was sold by Interactive Arts. Not many programmers were aware of the
existence of this linker and even fewer knew the EdAsm package sold by
APDA (which was managed by the Call-A.P.P.L.E. group) included another
linker.
Using some of his ideas and to demonstrate some of EdAsm's features, I
have written 3 trivial programs.
Program 1:
REL
ORG $3000
ENTRY HOHUM
ANYLABEL LDA #9
RTS
HOHUM LDA #>ANYLABEL
RTS
ExtLabel ENTRY ExtLabel
LDA #1
RTS
Save this file as "HOHUM".
(Don't forget to type "NEW")
Program 2:
REL
ORG $1000
EXTRN HOHUM
EXTRN ExtLabel
LOOP JSR HOHUM
LDA #>ExtLabel
LDY #<ExtLabel
JMP LOOP
Save this file as "CALLHOHUM.S"
Program 2:
REL
ORG $2000
EXTRN UNDEFINED
LOOP JSR UNDEFINED
LDX $10
JMP LOOP
Save this file as "CALLUNDEF.S"
Assemble all three 3 files by issuing something like this:
ASM HOHUM.S,HOHUM
And don't forget to type "NEW" or the editor will complain.
3 object files of type REL will be created.
Finally, type the following lines and save this file as "LINKHOHUM"
REL TEST.OBJ0
ORG $900
OPT +X,+E
CALLHOHUM
CALLUNDEF
HOHUM
Note: the last 3 lines are the pathnames to the REL files and must
have no leading spaces.
The first 3 lines are pseudo codes (akin to opcodes) and operands like
an assembly source
line. They must be preceded by at least 1 space/blank.
If you want to automate the entire process, use what is known as an
assembly control file. Just type the following lines using EdAsm's
Editor & save it as "ACF.S"
ASM HOHUM.S,HOHUM
ASM CALLHOHUM.S,CALLHOHUM
ASM CALLUNDEF.S,CALLUNDEF
EXIT /EDASM/LINKER
Then just type:
EXEC ACF.S
If there are no errors during assembly, then you should see:
PRODOS LINKER 1.0
COMMAND FILENAME?
Type "LINKHOHUM" and you should see the final object file TEST.OBJ0.
(You may have to change the path to the linker. On my disk, the root
directory is "EDASM".) If you wish filetype of TEST.OBJ0 to be BIN (or
SYS), edit the first line of the "LINKHOHUM" file & change "REL" to
"BIN" or "SYS"
In addition, you may see 6 other files; the file "EDASM.LINKMAP" can
be
loaded into EdAsm's editor.
Mark
A2CPM
Apr 10, 2012, 2:44:32 PM4/10/12
to
Hi, y'all!
When I wrote "more later" in my prior message in this thread, I
had planned on doing what Mark has done. But Mark has presented a
MUCH BETTER example than I thought about doing. NICE JOB, Mark!!!
Willi
When I wrote "more later" in my prior message in this thread, I
had planned on doing what Mark has done. But Mark has presented a
MUCH BETTER example than I thought about doing. NICE JOB, Mark!!!
Willi
MarkLim
Apr 10, 2012, 5:23:56 PM4/10/12
to
Thanks. You could carry on explaining the other pseudo codes or
switches of the OPT pseudo code.
I must admit one of your phrases, "EXIT LINKER", trigger off the idea
of using of the ACF.s file to control the assembly process. Although I
am aware of its existence, normally I use it to get back to
BASIC.SYSTEM.
In fact, another way to get the Linker running is to use XLOAD, do a
MON and then 2000G. The 1st approach is more elegant; probably what
the Linker's author have in mind.
Mark
A2CPM
Apr 12, 2012, 3:05:38 PM4/12/12
to
Hi, y'all!
Before I was made aware of the information available on Dr.
Matthews site, I created a source file for "EDASM.ASM". If you
display the catalog for "EDASM.DSK", you will see that the auxiliary
address for "EDASM.ASM" is $3000. But "EDASM.ASM" is actually loaded
at $6800. Then, $6800 to $77FF is copied to $D000 to $DFFF in bank
1. So, the source file I created for "EDASM.ASM" has two 'ORG'
statements, one for $D000 and one for $7800.
As a test for "LINKER", I broke the source file I generated for
"EDASM.ASM" into two parts and added ENTRY and EXTRN mnemonics to the
two parts to allow references between the two pieces to be satisfied.
But a comparison of the module created by "LINKER" against "EDASM.ASM"
reveals that "LINKER" can apparently only create modules that occupy
contiguous memory. All the references from the first assembly (loaded
at $6800 but lives at $D000 in bank 1) to the second assembly (loaded
at $7800 and runs there) were off by $5900. An attempt to inform
"LINKER" that the second 'REL' file actually starts at $7800, not
$D100, by inserting ' ORG $7800' before the line specifying the second
'REL' file was rejected by "LINKER". Also, "LINKER" did not correctly
resolve inter-module references when there was an offset from an
address defined by an 'EXTRN'. Example: ' LDA OUTREF+1' where
'OUTREF' is defined in an 'EXTRN' statement.
Willi
Before I was made aware of the information available on Dr.
Matthews site, I created a source file for "EDASM.ASM". If you
display the catalog for "EDASM.DSK", you will see that the auxiliary
address for "EDASM.ASM" is $3000. But "EDASM.ASM" is actually loaded
at $6800. Then, $6800 to $77FF is copied to $D000 to $DFFF in bank
1. So, the source file I created for "EDASM.ASM" has two 'ORG'
statements, one for $D000 and one for $7800.
As a test for "LINKER", I broke the source file I generated for
"EDASM.ASM" into two parts and added ENTRY and EXTRN mnemonics to the
two parts to allow references between the two pieces to be satisfied.
But a comparison of the module created by "LINKER" against "EDASM.ASM"
reveals that "LINKER" can apparently only create modules that occupy
contiguous memory. All the references from the first assembly (loaded
at $6800 but lives at $D000 in bank 1) to the second assembly (loaded
at $7800 and runs there) were off by $5900. An attempt to inform
"LINKER" that the second 'REL' file actually starts at $7800, not
$D100, by inserting ' ORG $7800' before the line specifying the second
'REL' file was rejected by "LINKER". Also, "LINKER" did not correctly
resolve inter-module references when there was an offset from an
address defined by an 'EXTRN'. Example: ' LDA OUTREF+1' where
'OUTREF' is defined in an 'EXTRN' statement.
Willi
Steven Hirsch
Apr 12, 2012, 3:37:43 PM4/12/12
to
directive from Microsoft M80 (and others). "ORG" is usually taken to mean
"..load AND run at this address" while "PHASE" means "..load in the natural
position relative to the last effective origin, but resolve references as if
it were running at the specific argument to PHASE". In other words, it's
specifically designed for code that will be relocated at runtime.
(FYI: The ALDS version of M80 is very handy for producing 6502 code, if you
don't mind cross-assembling under CP/M. It has features that the Apple world
didn't catch up with until OMF capable tools existed. And even then, I'm not
sure that the later 16-bit assemblers had all the bells and whistles)
On the second point: Extern arithmetic of that type is expected as base
functionality in a linker. I'm surprised it cannot handle that.
David Schmenk
Apr 12, 2012, 4:49:53 PM4/12/12
to
I'm glad you're looking at this. It looks like the LINKER isn't doing quite what it should. EDASM will place the offset calculation into the REL file. It is up to the linker/loader to add the offset into the external address' base. I've been finding out how to run through the fixup table and can now successfully load REL files generated by EDASM and link in PLASMAs runtime library (including offsets to EXTRNs). You can easily fix the LINKER by having it add in the value at the fixup address with the EXTRNally resolved address.
As for using multiple ORG statements, that is probably causing confusion with the REL directive. Even though you are assembling a REL file, it still requires an ORG statement to set a base address for the assembly. The ORG value is saved in the AUX field of the file, much like a BIN file, and used when calculating the relocation offset. (Note: Virtual ][ has a bug where it forgets the AUX value between runs when mounting a directory as a ProDOS volume) I think having an ORG directive is pointless when generating a REL file, but that's how it works. I discovered that placing multiple ORG directives in the ASM source will generate multiple object files, one for each ORG. Wanting to build a single binary that would relocate certain sections to different addresses required an additional tool to reconnect the separate object files back into one. I had to build using the SYS objective in order to get everything assembled at the address I wanted it.
Dave...
A2CPM
Apr 12, 2012, 8:52:56 PM4/12/12
to
Hi, Dave!
Thanks for pointing out that the auxiliary address of the 'REL'
file has a meaningful value. I missed that and concluded that
"LINKER" wasn't worth messing with. Now that I'm a bit wiser I'm
going to see if I can find the problem with references to an external
address using an offset not being correct. Perhaps, while I'm doing
that, I can find a way to use the 'REL' file's auxiliary address.
Willi
Thanks for pointing out that the auxiliary address of the 'REL'
file has a meaningful value. I missed that and concluded that
"LINKER" wasn't worth messing with. Now that I'm a bit wiser I'm
going to see if I can find the problem with references to an external
address using an offset not being correct. Perhaps, while I'm doing
that, I can find a way to use the 'REL' file's auxiliary address.
Willi
Steven Hirsch
Apr 13, 2012, 4:57:51 PM4/13/12
to
On 04/12/2012 04:49 PM, David Schmenk wrote:
> As for using multiple ORG statements, that is probably causing confusion
> with the REL directive. Even though you are assembling a REL file, it
> still requires an ORG statement to set a base address for the assembly.
> The ORG value is saved in the AUX field of the file, much like a BIN file,
> and used when calculating the relocation offset. (Note: Virtual ][ has a
> bug where it forgets the AUX value between runs when mounting a directory
> as a ProDOS volume) I think having an ORG directive is pointless when
> generating a REL file, but that's how it works. I discovered that placing
> multiple ORG directives in the ASM source will generate multiple object
> files, one for each ORG. Wanting to build a single binary that would
> relocate certain sections to different addresses required an additional
> tool to reconnect the separate object files back into one. I had to build
> using the SYS objective in order to get everything assembled at the address
> I wanted it.
Yes. If .PHASE was implemented properly you wouldn't need to go to all that
> As for using multiple ORG statements, that is probably causing confusion
> with the REL directive. Even though you are assembling a REL file, it
> still requires an ORG statement to set a base address for the assembly.
> The ORG value is saved in the AUX field of the file, much like a BIN file,
> and used when calculating the relocation offset. (Note: Virtual ][ has a
> bug where it forgets the AUX value between runs when mounting a directory
> as a ProDOS volume) I think having an ORG directive is pointless when
> generating a REL file, but that's how it works. I discovered that placing
> multiple ORG directives in the ASM source will generate multiple object
> files, one for each ORG. Wanting to build a single binary that would
> relocate certain sections to different addresses required an additional
> tool to reconnect the separate object files back into one. I had to build
> using the SYS objective in order to get everything assembled at the address
> I wanted it.
trouble.
Willi, if you ever disassemble the assembler please consider adding this?
0 new messages