Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #265 > unrolled thread

"LINKER", a program found on Asimov's "EDASM.DSK"

Back to article view | Back to comp.sys.apple2.programmer

Contents

  "LINKER", a program found on Asimov's "EDASM.DSK" A2CPM <a2@wilserv.com> - 2012-04-08 21:51 -0700
    Re: "LINKER", a program found on Asimov's "EDASM.DSK" MarkLim <markpmlim@yahoo.com.sg> - 2012-04-09 06:18 -0700
      Re: "LINKER", a program found on Asimov's "EDASM.DSK" A2CPM <a2@wilserv.com> - 2012-04-10 11:44 -0700
        Re: "LINKER", a program found on Asimov's "EDASM.DSK" MarkLim <markpmlim@yahoo.com.sg> - 2012-04-10 14:23 -0700
          Re: "LINKER", a program found on Asimov's "EDASM.DSK" A2CPM <a2@wilserv.com> - 2012-04-12 12:05 -0700
            Re: "LINKER", a program found on Asimov's "EDASM.DSK" Steven Hirsch <snhirsch@gmail.com> - 2012-04-12 15:37 -0400
            Re: "LINKER", a program found on Asimov's "EDASM.DSK" David Schmenk <dschmenk@gmail.com> - 2012-04-12 13:49 -0700
              Re: "LINKER", a program found on Asimov's "EDASM.DSK" A2CPM <a2@wilserv.com> - 2012-04-12 17:52 -0700
              Re: "LINKER", a program found on Asimov's "EDASM.DSK" Steven Hirsch <snhirsch@gmail.com> - 2012-04-13 16:57 -0400

#265 — "LINKER", a program found on Asimov's "EDASM.DSK"

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

[toc] | [next] | [standalone]

#266

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

[toc] | [prev] | [next] | [standalone]

#268

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

[toc] | [prev] | [next] | [standalone]

#269

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

[toc] | [prev] | [next] | [standalone]

#271

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

[toc] | [prev] | [next] | [standalone]

#272

On 04/12/2012 03:05 PM, A2CPM wrote:
> 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.

On the first point, sounds like you need the equivalent of the 'PHASE' 
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.

[toc] | [prev] | [next] | [standalone]

#273

On Thursday, April 12, 2012 12:05:38 PM UTC-7, A2CPM wrote:
> 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

Willi-

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...

[toc] | [prev] | [next] | [standalone]

#274

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

[toc] | [prev] | [next] | [standalone]

#275

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 
trouble.

Willi, if you ever disassemble the assembler please consider adding this?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web