Forum unknown
· Hardware
#schematics
13 messages in this thread
Larry – I hope you can show me what instance you had a problem with Asm68k
– especially the label change error. The error comes from a different
assembly of some instruction(s) on pass 2. I have tried very hard to crash
the label routines, but maybe I didn't think of all the potential errors
that could be made. That's why I posted the Assembler, so I could get some
help in finding some bugs. As far as I have been able to establish, the
assembler does output correct object for correct source.
I'm very glad to see you here! I think the EQU problem I had may have
been due to misuse of the CAPS switch, though I will have to check further.
I will be looking at it more this weekend, so hopefully I will have more
specific instances to pass on.
One of the major problems I had with it was its inability to
automatically resolve references between sections. Since Metacomco's
assembler does this, all my current code is written without caring about
where the reference is. I would really like to be able to leave it the way
it is, because it allows me to intermix macros, subroutines, and data in a
way that makes it easier for me to look at 6 months down the road, as well
as having some standard macro include files that I call at the beginning of
the file.
I want to mention that I think your program is one of the most important
things that has happened to the Amiga so far. A freely distributable
assembler will do a lot to encourage fast, efficient programs from people
who might otherwise not have bothered with anything but BASIC.
Thanks for the reply and the kind words. At present, the assembler doesn't
resolve references between sections because as I view it, these would be
16-bit relocatible references to different hunks, and as I understand it,
Alink does not support these properly, although Blink does (which I used to
link Asm68k.)
In fact, Blink (and John Toebes) were the inspiriation to attempt to
provide any compatibility with MCC's assembler, rather than rm only to
Motorola's (and in this version, the expression analyser doesn't offer full
compatibility, ala the 4*-6 unary operator restriction.) At any rate, I
have restricted References between sections so bad code wouldn't be
produced. It would probably save hundreds of bytes to remove this, so user
input will help here. The assembler will convert a reference to another
section to a LONG absolute instruction, and provide the linker with the
necessary relocation information, so maybe it's just a syntax quirk to
resolve these the way your source code is used. I will look for any
feedback you can provide next week, and hopefully adjust these and upload a
new version for everyone in a few days soon after. Thanks again.
I see the problem, but would probably prefer that an assembler handle
these references between sections. From my personal point of view, the
stuff I write with references outside the current section can be full
addressing mode, and if I am really trying to shave cycles on a particular
program, I can then tweak the sections to make them all short addresses. To
me, this beats typing a lot of ENTRY ops. Then again, I am only one person,
and others may disagree, so hang on before you jump into any major
changes.
I see the problem, but would probably prefer that an assembler handle
these references between sections. From my personal point of view, the
stuff I write with references outside the current section can be full
addressing mode, and if I am really trying to shave cycles on a particular
program, I can then tweak the sections to make them all short addresses. To
me, this beats typing a lot of ENTRY ops. Then again, I am only one person,
and others may disagree, so hang on before you jump into any major
changes.
Thanks for the reply and the kind words. At present, the assembler doesn't
resolve references between sections because as I view it, these would be
16-bit relocatible references to different hunks, and as I understand it,
Alink does not support these properly, although Blink does (which I used to
link Asm68k.)
In fact, Blink (and John Toebes) were the inspiriation to attempt to
provide any compatibility with MCC's assembler, rather than rm only to
Motorola's (and in this version, the expression analyser doesn't offer full
compatibility, ala the 4*-6 unary operator restriction.) At any rate, I
have restricted References between sections so bad code wouldn't be
produced. It would probably save hundreds of bytes to remove this, so user
input will help here. The assembler will convert a reference to another
section to a LONG absolute instruction, and provide the linker with the
necessary relocation information, so maybe it's just a syntax quirk to
resolve these the way your source code is used. I will look for any
feedback you can provide next week, and hopefully adjust these and upload a
new version for everyone in a few days soon after. Thanks again.
I'm very glad to see you here! I think the EQU problem I had may have
been due to misuse of the CAPS switch, though I will have to check further.
I will be looking at it more this weekend, so hopefully I will have more
specific instances to pass on.
One of the major problems I had with it was its inability to
automatically resolve references between sections. Since Metacomco's
assembler does this, all my current code is written without caring about
where the reference is. I would really like to be able to leave it the way
it is, because it allows me to intermix macros, subroutines, and data in a
way that makes it easier for me to look at 6 months down the road, as well
as having some standard macro include files that I call at the beginning of
the file.
I want to mention that I think your program is one of the most important
things that has happened to the Amiga so far. A freely distributable
assembler will do a lot to encourage fast, efficient programs from people
who might otherwise not have bothered with anything but BASIC.
I have had a further chance to play around with your assembler. First
off, I'd like to say that it looks like it will be a fine one. I am having
a problem with one thing that is most likely something I am doing wrong due
to misunderstanding something or other. The following fragments will serve
to show the problem….
XTRN macro
XREF _LVO\1
endm
call macro
jsr _LVO\1(A6)
endm
…..
XTRN OpenLibrary
…..
call OpenLibrary
This code produces (at "call OpenLibrary") the expected line….
jsr _LVO OpenLibrary(A6)
but I get an error code 48: Unavailable addressing mode used. I tried a
JSR to a label defined within the program with the same addressing mode,
and didn't complain, so I imagine it has something to do with the fact that
the offset I want is externally referenced.
OOPS! That last line (jsr _LVOOpenLibrary(A6) has an extra space in it…
the correct one is without the space.
One more thing I forgot to mention… if I define a macro with more than
one parameter, then try to pass them, I get an error on both substitutions.
By trial and error I found that if I delimit the two parameters with
spaces instead of commas, it works fine. Is this an error in documentation
or in the assembler itself?
OOPS! That last line (jsr _LVOOpenLibrary(A6) has an extra space in it…
the correct one is without the space.
One more thing I forgot to mention… if I define a macro with more than
one parameter, then try to pass them, I get an error on both substitutions.
By trial and error I found that if I delimit the two parameters with
spaces instead of commas, it works fine. Is this an error in documentation
or in the assembler itself?
Larry – As I further check the program since our chat, Asm68k improperly
assumes all external references are 32 bit references, and therefore
refuses to assemble one as a 16-bit external reference. The now forthcoming
beta version will repair this. I don't particularly like the concept, but
the linker takes care of most of the work if the assembler writes the
reference correctly, and woe be the poor programmer that tries a PC rel
reference to the offset.
Larry – As I further check the program since our chat, Asm68k improperly
assumes all external references are 32 bit references, and therefore
refuses to assemble one as a 16-bit external reference. The now forthcoming
beta version will repair this. I don't particularly like the concept, but
the linker takes care of most of the work if the assembler writes the
reference correctly, and woe be the poor programmer that tries a PC rel
reference to the offset.
I have had a further chance to play around with your assembler. First
off, I'd like to say that it looks like it will be a fine one. I am having
a problem with one thing that is most likely something I am doing wrong due
to misunderstanding something or other. The following fragments will serve
to show the problem….
XTRN macro
XREF _LVO\1
endm
call macro
jsr _LVO\1(A6)
endm
…..
XTRN OpenLibrary
…..
call OpenLibrary
This code produces (at "call OpenLibrary") the expected line….
jsr _LVO OpenLibrary(A6)
but I get an error code 48: Unavailable addressing mode used. I tried a
JSR to a label defined within the program with the same addressing mode,
and didn't complain, so I imagine it has something to do with the fact that
the offset I want is externally referenced.