| Title: | AMIGA NOTES |
| Notice: | Join us in the *NEW* conference - HYDRA::AMIGA_V2 |
| Moderator: | HYDRA::MOORE |
| Created: | Sat Apr 26 1986 |
| Last Modified: | Wed Feb 05 1992 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5378 |
| Total number of notes: | 38326 |
This weekend I ran into a couple of problems with my assembler
(METACOMCO) that have me a little perplexed.
o Problem: The assembler doesn't seem to recognize macros that are part
of include files. I INLCUDE'd the dos.i file into my
program and then invoked the DOSNAME macro. The assembler
said 'Illegal opcode'. I then moved the macro into my source
file and it worked. I know that the assembler is finding the
file because an EQU'd symbol was resolved from it (MODE_NEWFILE).
(BTW: The include files I'm using came with the assembler.)
o Problem: After fixing the first problem (above) I got a clean build
(via Blink) of the program. However, neither Metascope or
RUN would load it (Metascope says - 'Load error'and RUN says -
'File not an object file'). Sooooo, I pulled out all INCLUDEs
from the source and coded in the values that I needed, rebuilt
and everything works fine!
I would really like to know how to SUCCESSFULLY use INCLUDE files as they
make development and later modification easier. So what am I doing wrong??
Jim Goddard
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2013.1 | Never mind | NAC::GODDARD | Mon Dec 19 1988 08:49 | 13 | |
Sorry to have bothered you but I figured out both problems:
o Problem #1 - pilot error (:-o) I'm still not used
to the way the assembler handles case in labels.
(i.e. DOSNAME not= dosname) I guess you C programmers
are used to this though.
o Problem #2 - Removing a SECTION pseudo-op which
followed the INCLUDEs made the 'load' problem go
away. Hmmmm? Still don't understand this....any
thoughts?
| |||||
| 2013.2 | Maybe a linker problem? | STAR::BANKS | In Search of Mediocrity | Mon Dec 19 1988 10:36 | 21 |
Concerning the second problem: I have a sort of shot in the dark:
If you create a HUNK or section of zero length, for instance, something
that you want to force to be the last thing loaded into a final
load file hunk that contains only a symbol definition that flags
the end of the world, BLINK will generate garbage. If the SECTION
you took out of the front of your code was something of this nature,
it may be your problem.
Two ways to veryfiy that this is your problem:
1) If you just have a SYMBOL EQU * or some other label def, change
it to allocate at least a byte into that section.
2) Find a bunch of free time, and waste it by trying to ALINK the
program instead. If the resultant image is runnable, this is your
problem.
Unfortunately, while the second solution is a workaround, it does
produce load files that are a bunch larger than they need to be
(but not as a result of the zero length section).
| |||||