Forum unknown
· Programming
#Linking C & Assem Files
53 messages in this thread
Help! I am trying to write a printer driver using Aztec-C and Amiga Macro
Assembler. What I have done thus far is write the ".c" and ".asm" files,
compile the ".c" files with Aztec-C, and assemble the ".asm" files with Amiga
Macro Assembler. When I try to link the Aztec-C object files with the Macro
Assembler object files I get an error message stating that there is invalid
object code in the Aztec-C object files. I noticed that there is a file in
the lib directory on the Macro Assembler disk called Astartup.obj which is
the "Amiga startup file to be used when linking both C and Assem programs
together." How do I incorporate this file into the linking process (there
are no instructions on how to do this in the documentation that came with
Macro Assembler)? I have the commercial version of Aztec-C and version 1.0
of the Amiga Macro Assembler. If anyone can help me out with this problem,
please leave me a message in this SIG or on EasyPlex. Thanks. — Fred
Kohler 75365,1460 —
Fred, Why don't you just use the Aztec Assembler?? Or, you can convert the
code with acvt ( I think that's the one). best sdb
I have tried to assemble the files init.asm, printertag.asm, and
wait.asm listed in Appendix I of the Rom Kernal Manual with the Aztec
Assembler but the assembly always aborts for one reason or another (such as
undefined symbols or unknown opcodes/directives). I have also tried
converting the code with acvt. I think this works OK but some of the files
are converted into UNK00.obj. What the heck does UNK00 mean? Unknown? I am
now at the point where I am thinking of returning Aztec-C back to Manx,
getting my money back, and purchasing Lattice-C. It may take Lattice-C a
little bit longer to compile C source files than Aztec-C, but at least you
can use the Amiga Macro Assembler to link together Lattice-C object files and
Amiga Macro Assembler object files. After my experiences with Aztec-C I
would strongly discourage anyone from purchasing it if they are planning to
write device drivers for the Amiga because it doesn't appear that Amiga Macro
Assembler object files can be linked to Aztec-C object files. The acvt
utility may work but don't forget that you also have to convert amiga.lib on
the Macro Assembler disk also if you are going to attempt to link the files
together with the Aztec Linker. By the way, Manx has a BBS and their
response to this was "this package was developed with C programming as its
primary consideration." In my opinion, Manx made a big mistake in having
their assembler put out object code that is not able to be linked to Macro
Assembler object code. If you have any more suggestions, please let me know.
That's certainly the largest problem with Aztec. And it seems really stupid
on their part. Instead of spending the time to write the acvt utility, they
could have spent the 10-15 minutes necessary to rewrite their compiler using
the proper function conventions. At least from what I've heard, they aren't
using anything that would prevent them from conforming to the standard. And
that would allow you to use their linker with Macro Assembler modules.
-Dave Haynie
So what you're saying Dave is that it is not possible to link the C and
Assembler object codes together if Aztec-C and Amiga Macro Assembler
generated the respective codes? Even with acvt, I haven't been able to do
it. The result —> I'll be returning Aztec-C to Manx and ordering
Lattice-C. It may take Lattice-C twice as long to compile the source code,
bu at least I'll be able to link Lattice-C object code to Amiga Macro
Assembler object code. — Fred Kohler 75365,1460 —
I'm not sure I understand just why you would want to use the Amiga Assembler!
Aztec C comes with it's own macro assembler which is MUCH faster than the Amiga
assembler! Why pay for yet another assembler?
Rick Schaeffer
Rick, there are nowhere near as many directives for the Aztec C macro
assembler as there are for the Amiga macro assembler. In order to assemble
the ".asm" files listed in the Rom Kernal Manual you practically have to
re-write the entire source code. For example, there are no XREF or XDEF
directives in the Aztec C macro assembler. I tried assembling the ".asm"
files listed in the Rom Kernal Manual in the exact form they were given and
the Aztec macro assembler kept giving "unknown opcode or directive" errors.
I don't need the hassle of trying to figure out how to convert the ".asm"
files to a form acceptable to the Aztec C macro assembler. True, it does
assemble much faster than the Amiga assembler but you end up taking more time
converting the source code than it's worth. Therefore, I have ordered
Lattice C and will be returning my commercial version of Aztec C to Manx for
a refund next week. Even though Lattice C compiles source code slower than
Aztec C, I consider it to be a better product AT THIS TIME. If Manx ever
makes their object code compatible with Amiga object code (which it isn't
according to Jim Goodnow, creator of Aztec C), I will then consider Aztec C
to be the superior product. — Fred Kohler 75365,1460 —
How hard would it be to write a preprocessor that digests Amiga Assembler
source and produces code that the Aztec assembler will accept? If it's
do-able, some enterprising Amiga hacker with access to the specs for each
could make a lot of friends by writing one.
Richard, Jim Goodnow left me a message on the Manx BBS that the first update
to Aztec-C for the Amiga will include an Alink facility so that Aztec-C
object files can be linked with Macro Assembler object files. I'll be
getting Lattice-C Monday but I will also hang onto my Aztec-C since I get a
year of "free" updates with my commercial version. — Fred Kohler 75365,1460
Richard, Jim Goodnow left me a message on the Manx BBS that the first update
to Aztec-C for the Amiga will include an Alink facility so that Aztec-C
object files can be linked with Macro Assembler object files. I'll be
getting Lattice-C Monday but I will also hang onto my Aztec-C since I get a
year of "free" updates with my commercial version. — Fred Kohler 75365,1460
couldn't one create a set of #defines and the like to use the C preprocessor
to do the massagement of the Amiga Assembler files into a form useable by
Aztec? Put those #defines into a “generic include file'' and let the C
preprocessor rip.
couldn't one create a set of #defines and the like to use the C preprocessor
to do the massagement of the Amiga Assembler files into a form useable by
Aztec? Put those #defines into a “generic include file'' and let the C
preprocessor rip.
How hard would it be to write a preprocessor that digests Amiga Assembler
source and produces code that the Aztec assembler will accept? If it's
do-able, some enterprising Amiga hacker with access to the specs for each
could make a lot of friends by writing one.
I see what you mean. I didn't realize there were that many differences. Of
course, you will have to give up more than just compile speed if you go to
Lattice. Your C object files will average well over 100% larger and will
generally not be as fast at execution as Aztec…especially floating point
operations (see AZLAT.DOC in dl8 for actual timings). Aztec also provides
quite a few library functions that are handy and were either not provided by
Lattice or were provided but don't work. The AmigaDos Execute function, for
instance, doesn't work properly (it leaves little orphaned chunks of memory
around, and doesn't return the exit status of the program executed). Aztec
provides one which is fully functional.
I hope you don't think I'm Aztec salesman or anything…I'm not! Just *real*
pleased with the product. Rick Schaeffer
Rick, I ordered Lattice-C and will be getting it on Monday. However, I will
also be hanging on to my Aztec-C because Jim Goodnow left me a message on the
Manx BBS that the first update will include an Alink facility so that Aztec-C
object files can be linked with Amiga Macro Assembler object files (you get 1
year of "free" updates with the commercial version of Aztec-C). The reason I
didn't cancel my order for Lattice-C is that I need a printer driver for my
Epson LQ-800 NOW! Text works fine with the Epson driver in Preferences but
graphics do not (circles print out as ovals – due to the fact that the LQ-800
has a 24-pin print head). I am just learning how to program in C and 68000
Assembler — when I get proficient at C I want a good C compiler. Hence, my
decision to keep my Aztec-C. Maybe somebody will purchase my Lattice-C from
me after it has proven to be extinct. — Fred Kohler 75365,1460 —
Rick, I ordered Lattice-C and will be getting it on Monday. However, I will
also be hanging on to my Aztec-C because Jim Goodnow left me a message on the
Manx BBS that the first update will include an Alink facility so that Aztec-C
object files can be linked with Amiga Macro Assembler object files (you get 1
year of "free" updates with the commercial version of Aztec-C). The reason I
didn't cancel my order for Lattice-C is that I need a printer driver for my
Epson LQ-800 NOW! Text works fine with the Epson driver in Preferences but
graphics do not (circles print out as ovals – due to the fact that the LQ-800
has a 24-pin print head). I am just learning how to program in C and 68000
Assembler — when I get proficient at C I want a good C compiler. Hence, my
decision to keep my Aztec-C. Maybe somebody will purchase my Lattice-C from
me after it has proven to be extinct. — Fred Kohler 75365,1460 —
I see what you mean. I didn't realize there were that many differences. Of
course, you will have to give up more than just compile speed if you go to
Lattice. Your C object files will average well over 100% larger and will
generally not be as fast at execution as Aztec…especially floating point
operations (see AZLAT.DOC in dl8 for actual timings). Aztec also provides
quite a few library functions that are handy and were either not provided by
Lattice or were provided but don't work. The AmigaDos Execute function, for
instance, doesn't work properly (it leaves little orphaned chunks of memory
around, and doesn't return the exit status of the program executed). Aztec
provides one which is fully functional.
I hope you don't think I'm Aztec salesman or anything…I'm not! Just *real*
pleased with the product. Rick Schaeffer
If there are no XREF and XDEF, how do you link Aztec assembly files with
other object code files?
You put the names in a public or global directive, and use a_ if you are
linking with C. sdb (Hi cheath)
You put the names in a public or global directive, and use a_ if you are
linking with C. sdb (Hi cheath)
If there are no XREF and XDEF, how do you link Aztec assembly files with
other object code files?
Rick, there are nowhere near as many directives for the Aztec C macro
assembler as there are for the Amiga macro assembler. In order to assemble
the ".asm" files listed in the Rom Kernal Manual you practically have to
re-write the entire source code. For example, there are no XREF or XDEF
directives in the Aztec C macro assembler. I tried assembling the ".asm"
files listed in the Rom Kernal Manual in the exact form they were given and
the Aztec macro assembler kept giving "unknown opcode or directive" errors.
I don't need the hassle of trying to figure out how to convert the ".asm"
files to a form acceptable to the Aztec C macro assembler. True, it does
assemble much faster than the Amiga assembler but you end up taking more time
converting the source code than it's worth. Therefore, I have ordered
Lattice C and will be returning my commercial version of Aztec C to Manx for
a refund next week. Even though Lattice C compiles source code slower than
Aztec C, I consider it to be a better product AT THIS TIME. If Manx ever
makes their object code compatible with Amiga object code (which it isn't
according to Jim Goodnow, creator of Aztec C), I will then consider Aztec C
to be the superior product. — Fred Kohler 75365,1460 —
Rick, there are nowhere near as many directives for the Aztec C macro
assembler as there are for the Amiga macro assembler. In order to assemble
the ".asm" files listed in the Rom Kernal Manual you practically have to
re-write the entire source code. For example, there are no XREF or XDEF
directives in the Aztec C macro assembler. I tried assembling the ".asm"
files listed in the Rom Kernal Manual in the exact form they were given and
the Aztec macro assembler kept giving "unknown opcode or directive" errors.
I don't need the hassle of trying to figure out how to convert the ".asm"
files to a form acceptable to the Aztec C macro assembler. True, it does
assemble much faster than the Amiga assembler but you end up taking more time
converting the source code than it's worth. Therefore, I have ordered
Lattice C and will be returning my commercial version of Aztec C to Manx for
a refund next week. Even though Lattice C compiles source code slower than
Aztec C, I consider it to be a better product AT THIS TIME. If Manx ever
makes their object code compatible with Amiga object code (which it isn't
according to Jim Goodnow, creator of Aztec C), I will then consider Aztec C
to be the superior product. — Fred Kohler 75365,1460 —
Rick, there are nowhere near as many directives for the Aztec C macro
assembler as there are for the Amiga macro assembler. In order to assemble
the ".asm" files listed in the Rom Kernal Manual you practically have to
re-write the entire source code. For example, there are no XREF or XDEF
directives in the Aztec C macro assembler. I tried assembling the ".asm"
files listed in the Rom Kernal Manual in the exact form they were given and
the Aztec macro assembler kept giving "unknown opcode or directive" errors.
I don't need the hassle of trying to figure out how to convert the ".asm"
files to a form acceptable to the Aztec C macro assembler. True, it does
assemble much faster than the Amiga assembler but you end up taking more time
converting the source code than it's worth. Therefore, I have ordered
Lattice C and will be returning my commercial version of Aztec C to Manx for
a refund next week. Even though Lattice C compiles source code slower than
Aztec C, I consider it to be a better product AT THIS TIME. If Manx ever
makes their object code compatible with Amiga object code (which it isn't
according to Jim Goodnow, creator of Aztec C), I will then consider Aztec C
to be the superior product. — Fred Kohler 75365,1460 —
Rick, there are nowhere near as many directives for the Aztec C macro
assembler as there are for the Amiga macro assembler. In order to assemble
the ".asm" files listed in the Rom Kernal Manual you practically have to
re-write the entire source code. For example, there are no XREF or XDEF
directives in the Aztec C macro assembler. I tried assembling the ".asm"
files listed in the Rom Kernal Manual in the exact form they were given and
the Aztec macro assembler kept giving "unknown opcode or directive" errors.
I don't need the hassle of trying to figure out how to convert the ".asm"
files to a form acceptable to the Aztec C macro assembler. True, it does
assemble much faster than the Amiga assembler but you end up taking more time
converting the source code than it's worth. Therefore, I have ordered
Lattice C and will be returning my commercial version of Aztec C to Manx for
a refund next week. Even though Lattice C compiles source code slower than
Aztec C, I consider it to be a better product AT THIS TIME. If Manx ever
makes their object code compatible with Amiga object code (which it isn't
according to Jim Goodnow, creator of Aztec C), I will then consider Aztec C
to be the superior product. — Fred Kohler 75365,1460 —
Rick, there are nowhere near as many directives for the Aztec C macro
assembler as there are for the Amiga macro assembler. In order to assemble
the ".asm" files listed in the Rom Kernal Manual you practically have to
re-write the entire source code. For example, there are no XREF or XDEF
directives in the Aztec C macro assembler. I tried assembling the ".asm"
files listed in the Rom Kernal Manual in the exact form they were given and
the Aztec macro assembler kept giving "unknown opcode or directive" errors.
I don't need the hassle of trying to figure out how to convert the ".asm"
files to a form acceptable to the Aztec C macro assembler. True, it does
assemble much faster than the Amiga assembler but you end up taking more time
converting the source code than it's worth. Therefore, I have ordered
Lattice C and will be returning my commercial version of Aztec C to Manx for
a refund next week. Even though Lattice C compiles source code slower than
Aztec C, I consider it to be a better product AT THIS TIME. If Manx ever
makes their object code compatible with Amiga object code (which it isn't
according to Jim Goodnow, creator of Aztec C), I will then consider Aztec C
to be the superior product. — Fred Kohler 75365,1460 —
I'm not sure I understand just why you would want to use the Amiga Assembler!
Aztec C comes with it's own macro assembler which is MUCH faster than the Amiga
assembler! Why pay for yet another assembler?
Rick Schaeffer
I'm not sure I understand just why you would want to use the Amiga Assembler!
Aztec C comes with it's own macro assembler which is MUCH faster than the Amiga
assembler! Why pay for yet another assembler?
Rick Schaeffer
I'm not sure I understand just why you would want to use the Amiga Assembler!
Aztec C comes with it's own macro assembler which is MUCH faster than the Amiga
assembler! Why pay for yet another assembler?
Rick Schaeffer
I'm not sure I understand just why you would want to use the Amiga Assembler!
Aztec C comes with it's own macro assembler which is MUCH faster than the Amiga
assembler! Why pay for yet another assembler?
Rick Schaeffer
I'm not sure I understand just why you would want to use the Amiga Assembler!
Aztec C comes with it's own macro assembler which is MUCH faster than the Amiga
assembler! Why pay for yet another assembler?
Rick Schaeffer
So what you're saying Dave is that it is not possible to link the C and
Assembler object codes together if Aztec-C and Amiga Macro Assembler
generated the respective codes? Even with acvt, I haven't been able to do
it. The result —> I'll be returning Aztec-C to Manx and ordering
Lattice-C. It may take Lattice-C twice as long to compile the source code,
bu at least I'll be able to link Lattice-C object code to Amiga Macro
Assembler object code. — Fred Kohler 75365,1460 —
So what you're saying Dave is that it is not possible to link the C and
Assembler object codes together if Aztec-C and Amiga Macro Assembler
generated the respective codes? Even with acvt, I haven't been able to do
it. The result —> I'll be returning Aztec-C to Manx and ordering
Lattice-C. It may take Lattice-C twice as long to compile the source code,
bu at least I'll be able to link Lattice-C object code to Amiga Macro
Assembler object code. — Fred Kohler 75365,1460 —
So what you're saying Dave is that it is not possible to link the C and
Assembler object codes together if Aztec-C and Amiga Macro Assembler
generated the respective codes? Even with acvt, I haven't been able to do
it. The result —> I'll be returning Aztec-C to Manx and ordering
Lattice-C. It may take Lattice-C twice as long to compile the source code,
bu at least I'll be able to link Lattice-C object code to Amiga Macro
Assembler object code. — Fred Kohler 75365,1460 —
So what you're saying Dave is that it is not possible to link the C and
Assembler object codes together if Aztec-C and Amiga Macro Assembler
generated the respective codes? Even with acvt, I haven't been able to do
it. The result —> I'll be returning Aztec-C to Manx and ordering
Lattice-C. It may take Lattice-C twice as long to compile the source code,
bu at least I'll be able to link Lattice-C object code to Amiga Macro
Assembler object code. — Fred Kohler 75365,1460 —
So what you're saying Dave is that it is not possible to link the C and
Assembler object codes together if Aztec-C and Amiga Macro Assembler
generated the respective codes? Even with acvt, I haven't been able to do
it. The result —> I'll be returning Aztec-C to Manx and ordering
Lattice-C. It may take Lattice-C twice as long to compile the source code,
bu at least I'll be able to link Lattice-C object code to Amiga Macro
Assembler object code. — Fred Kohler 75365,1460 —
Don't know why they did it that way, but based on the quality of the package,
I am willing to give them the benefit of doubt. The macro assembler produces
loadable files (loadable without further linking) while the manx linker seems
to be doing this step as well… Personally, I haven't found the need for the
macro assembler since I got Aztec, and I have been writing a *lot* more
assembler lately… sdb
Don't know why they did it that way, but based on the quality of the package,
I am willing to give them the benefit of doubt. The macro assembler produces
loadable files (loadable without further linking) while the manx linker seems
to be doing this step as well… Personally, I haven't found the need for the
macro assembler since I got Aztec, and I have been writing a *lot* more
assembler lately… sdb
That's certainly the largest problem with Aztec. And it seems really stupid
on their part. Instead of spending the time to write the acvt utility, they
could have spent the 10-15 minutes necessary to rewrite their compiler using
the proper function conventions. At least from what I've heard, they aren't
using anything that would prevent them from conforming to the standard. And
that would allow you to use their linker with Macro Assembler modules.
-Dave Haynie
That's certainly the largest problem with Aztec. And it seems really stupid
on their part. Instead of spending the time to write the acvt utility, they
could have spent the 10-15 minutes necessary to rewrite their compiler using
the proper function conventions. At least from what I've heard, they aren't
using anything that would prevent them from conforming to the standard. And
that would allow you to use their linker with Macro Assembler modules.
-Dave Haynie
That's certainly the largest problem with Aztec. And it seems really stupid
on their part. Instead of spending the time to write the acvt utility, they
could have spent the 10-15 minutes necessary to rewrite their compiler using
the proper function conventions. At least from what I've heard, they aren't
using anything that would prevent them from conforming to the standard. And
that would allow you to use their linker with Macro Assembler modules.
-Dave Haynie
That's certainly the largest problem with Aztec. And it seems really stupid
on their part. Instead of spending the time to write the acvt utility, they
could have spent the 10-15 minutes necessary to rewrite their compiler using
the proper function conventions. At least from what I've heard, they aren't
using anything that would prevent them from conforming to the standard. And
that would allow you to use their linker with Macro Assembler modules.
-Dave Haynie
That's certainly the largest problem with Aztec. And it seems really stupid
on their part. Instead of spending the time to write the acvt utility, they
could have spent the 10-15 minutes necessary to rewrite their compiler using
the proper function conventions. At least from what I've heard, they aren't
using anything that would prevent them from conforming to the standard. And
that would allow you to use their linker with Macro Assembler modules.
-Dave Haynie
Well, I haven't tried it, but it looks like it wouldn't be hard. Can't you
just replace the XDEF XREF with public?? I have to disagree with you on the
subject of manx – I find it remarkably fine. I haven't tried to write a
device driver, but I do a lot of assembly programming mixed with C, and
having the assembler on hand is a real blessing. You also should not have to
convert amiga lib – just put the LVOwhatever as equates in the file, or if
you can get it to work with the manx, you don't even have to do that – just
use LVOxxx. Sorry you had a rough time with it. Best sdb
Just got my Aztec, it appears that the assembler conversion is mostly
replacing xref/xdef with public, and SECTION stuff with cseg's and dseg's,
and commenting out ttl's. I still wish I could get Aztec code into standard
amiga object format… Also wish they hadn't used the ".o" extension, since
now I'm confuciousing differenct .o files. Actually what I REALLY wish was
that there was only one .O format…
Just got my Aztec, it appears that the assembler conversion is mostly
replacing xref/xdef with public, and SECTION stuff with cseg's and dseg's,
and commenting out ttl's. I still wish I could get Aztec code into standard
amiga object format… Also wish they hadn't used the ".o" extension, since
now I'm confuciousing differenct .o files. Actually what I REALLY wish was
that there was only one .O format…
Well, I haven't tried it, but it looks like it wouldn't be hard. Can't you
just replace the XDEF XREF with public?? I have to disagree with you on the
subject of manx – I find it remarkably fine. I haven't tried to write a
device driver, but I do a lot of assembly programming mixed with C, and
having the assembler on hand is a real blessing. You also should not have to
convert amiga lib – just put the LVOwhatever as equates in the file, or if
you can get it to work with the manx, you don't even have to do that – just
use LVOxxx. Sorry you had a rough time with it. Best sdb
I have tried to assemble the files init.asm, printertag.asm, and
wait.asm listed in Appendix I of the Rom Kernal Manual with the Aztec
Assembler but the assembly always aborts for one reason or another (such as
undefined symbols or unknown opcodes/directives). I have also tried
converting the code with acvt. I think this works OK but some of the files
are converted into UNK00.obj. What the heck does UNK00 mean? Unknown? I am
now at the point where I am thinking of returning Aztec-C back to Manx,
getting my money back, and purchasing Lattice-C. It may take Lattice-C a
little bit longer to compile C source files than Aztec-C, but at least you
can use the Amiga Macro Assembler to link together Lattice-C object files and
Amiga Macro Assembler object files. After my experiences with Aztec-C I
would strongly discourage anyone from purchasing it if they are planning to
write device drivers for the Amiga because it doesn't appear that Amiga Macro
Assembler object files can be linked to Aztec-C object files. The acvt
utility may work but don't forget that you also have to convert amiga.lib on
the Macro Assembler disk also if you are going to attempt to link the files
together with the Aztec Linker. By the way, Manx has a BBS and their
response to this was "this package was developed with C programming as its
primary consideration." In my opinion, Manx made a big mistake in having
their assembler put out object code that is not able to be linked to Macro
Assembler object code. If you have any more suggestions, please let me know.
I have tried to assemble the files init.asm, printertag.asm, and
wait.asm listed in Appendix I of the Rom Kernal Manual with the Aztec
Assembler but the assembly always aborts for one reason or another (such as
undefined symbols or unknown opcodes/directives). I have also tried
converting the code with acvt. I think this works OK but some of the files
are converted into UNK00.obj. What the heck does UNK00 mean? Unknown? I am
now at the point where I am thinking of returning Aztec-C back to Manx,
getting my money back, and purchasing Lattice-C. It may take Lattice-C a
little bit longer to compile C source files than Aztec-C, but at least you
can use the Amiga Macro Assembler to link together Lattice-C object files and
Amiga Macro Assembler object files. After my experiences with Aztec-C I
would strongly discourage anyone from purchasing it if they are planning to
write device drivers for the Amiga because it doesn't appear that Amiga Macro
Assembler object files can be linked to Aztec-C object files. The acvt
utility may work but don't forget that you also have to convert amiga.lib on
the Macro Assembler disk also if you are going to attempt to link the files
together with the Aztec Linker. By the way, Manx has a BBS and their
response to this was "this package was developed with C programming as its
primary consideration." In my opinion, Manx made a big mistake in having
their assembler put out object code that is not able to be linked to Macro
Assembler object code. If you have any more suggestions, please let me know.
I have tried to assemble the files init.asm, printertag.asm, and
wait.asm listed in Appendix I of the Rom Kernal Manual with the Aztec
Assembler but the assembly always aborts for one reason or another (such as
undefined symbols or unknown opcodes/directives). I have also tried
converting the code with acvt. I think this works OK but some of the files
are converted into UNK00.obj. What the heck does UNK00 mean? Unknown? I am
now at the point where I am thinking of returning Aztec-C back to Manx,
getting my money back, and purchasing Lattice-C. It may take Lattice-C a
little bit longer to compile C source files than Aztec-C, but at least you
can use the Amiga Macro Assembler to link together Lattice-C object files and
Amiga Macro Assembler object files. After my experiences with Aztec-C I
would strongly discourage anyone from purchasing it if they are planning to
write device drivers for the Amiga because it doesn't appear that Amiga Macro
Assembler object files can be linked to Aztec-C object files. The acvt
utility may work but don't forget that you also have to convert amiga.lib on
the Macro Assembler disk also if you are going to attempt to link the files
together with the Aztec Linker. By the way, Manx has a BBS and their
response to this was "this package was developed with C programming as its
primary consideration." In my opinion, Manx made a big mistake in having
their assembler put out object code that is not able to be linked to Macro
Assembler object code. If you have any more suggestions, please let me know.
Fred, Why don't you just use the Aztec Assembler?? Or, you can convert the
code with acvt ( I think that's the one). best sdb
Fred, Why don't you just use the Aztec Assembler?? Or, you can convert the
code with acvt ( I think that's the one). best sdb
Fred, Why don't you just use the Aztec Assembler?? Or, you can convert the
code with acvt ( I think that's the one). best sdb