Forum unknown
· Programming
C COMPILERS
21 messages in this thread
An excellent How To book on the C language is the "C Primer Plus" by the Waite
Group, published by Sams. You probably should also pick up a copy of "The C
Programming Language" by Kernighan and Ritchie (the famous K&R). Though it this
is less a textbook than a language definition, it does include exercises.
Opinion on the preferred compiler seems to be split. Those who want to link C
segments with Amiga Assembler modules are opting for Lattice. The C-only folks
are heavily in favor of Aztec C, for its fast compile/execute times and smaller
code size. You pays your money and you takes your chance.
That's such a strange thing: most of the assembler I write is to save code
size and get something to run fast. And to customize my startup file. The
Aztec compiler generates better code, so I'd want to use it; but since it
doen't have the assembly hooks, I can't. Oh well, I've ordered it anyhow…
Hmmm.. you can't use Assembler with Aztec??? I heard that it had it's own
built in Assembler. Oh well… I'll keep checking. Doug
It has a built in assembler; but it apparently doen't work with Metacomco
assembly files, such as the assembly code printer drivers and libraries
available.
It has a built in assembler; but it apparently doen't work with Metacomco
assembly files, such as the assembly code printer drivers and libraries
available.
Hmmm.. you can't use Assembler with Aztec??? I heard that it had it's own
built in Assembler. Oh well… I'll keep checking. Doug
Hmmm.. you can't use Assembler with Aztec??? I heard that it had it's own
built in Assembler. Oh well… I'll keep checking. Doug
Hmmm.. you can't use Assembler with Aztec??? I heard that it had it's own
built in Assembler. Oh well… I'll keep checking. Doug
Hmmm.. you can't use Assembler with Aztec??? I heard that it had it's own
built in Assembler. Oh well… I'll keep checking. Doug
Hmmm.. you can't use Assembler with Aztec??? I heard that it had it's own
built in Assembler. Oh well… I'll keep checking. Doug
Have been looking into this prob with the developer's package of Aztec…What
seems to be happening is that the Macro Assembler produces different object
files than does Aztec's own as assembler. Main differences seem to be within
the actual object line specifications. THere is a solution, however: Compile
your assembler files with the Aztec as assembler. Mostly what is needed is
to change the psuedo-ops to the ones recognized by as (not too hard to do;
just tedious). Then compile with as, compile your 'C' modules, then link them
with ln. While this is mostly a stopgap (and a pox on Manx for being
nonstandard!), it does work, as I have done this to the Epson printer driver
source in DL9 wothout too much trouble with the Developer's Version…
John
* RR 12961
Have been looking into this prob with the developer's package of Aztec…What
seems to be happening is that the Macro Assembler produces different object
files than does Aztec's own as assembler. Main differences seem to be within
the actual object line specifications. THere is a solution, however: Compile
your assembler files with the Aztec as assembler. Mostly what is needed is
to change the psuedo-ops to the ones recognized by as (not too hard to do;
just tedious). Then compile with as, compile your 'C' modules, then link them
with ln. While this is mostly a stopgap (and a pox on Manx for being
nonstandard!), it does work, as I have done this to the Epson printer driver
source in DL9 wothout too much trouble with the Developer's Version…
John
* RR 12961
Have been looking into this prob with the developer's package of Aztec…What
seems to be happening is that the Macro Assembler produces different object
files than does Aztec's own as assembler. Main differences seem to be within
the actual object line specifications. THere is a solution, however: Compile
your assembler files with the Aztec as assembler. Mostly what is needed is
to change the psuedo-ops to the ones recognized by as (not too hard to do;
just tedious). Then compile with as, compile your 'C' modules, then link them
with ln. While this is mostly a stopgap (and a pox on Manx for being
nonstandard!), it does work, as I have done this to the Epson printer driver
source in DL9 wothout too much trouble with the Developer's Version…
John
* RR 12961
Have been looking into this prob with the developer's package of Aztec…What
seems to be happening is that the Macro Assembler produces different object
files than does Aztec's own as assembler. Main differences seem to be within
the actual object line specifications. THere is a solution, however: Compile
your assembler files with the Aztec as assembler. Mostly what is needed is
to change the psuedo-ops to the ones recognized by as (not too hard to do;
just tedious). Then compile with as, compile your 'C' modules, then link them
with ln. While this is mostly a stopgap (and a pox on Manx for being
nonstandard!), it does work, as I have done this to the Epson printer driver
source in DL9 wothout too much trouble with the Developer's Version…
John
* RR 12961
Have been looking into this prob with the developer's package of Aztec…What
seems to be happening is that the Macro Assembler produces different object
files than does Aztec's own as assembler. Main differences seem to be within
the actual object line specifications. THere is a solution, however: Compile
your assembler files with the Aztec as assembler. Mostly what is needed is
to change the psuedo-ops to the ones recognized by as (not too hard to do;
just tedious). Then compile with as, compile your 'C' modules, then link them
with ln. While this is mostly a stopgap (and a pox on Manx for being
nonstandard!), it does work, as I have done this to the Epson printer driver
source in DL9 wothout too much trouble with the Developer's Version…
John
* RR 12961
Have been looking into this prob with the developer's package of Aztec…What
seems to be happening is that the Macro Assembler produces different object
files than does Aztec's own as assembler. Main differences seem to be within
the actual object line specifications. THere is a solution, however: Compile
your assembler files with the Aztec as assembler. Mostly what is needed is
to change the psuedo-ops to the ones recognized by as (not too hard to do;
just tedious). Then compile with as, compile your 'C' modules, then link them
with ln. While this is mostly a stopgap (and a pox on Manx for being
nonstandard!), it does work, as I have done this to the Epson printer driver
source in DL9 wothout too much trouble with the Developer's Version…
John
* RR 12961
That's such a strange thing: most of the assembler I write is to save code
size and get something to run fast. And to customize my startup file. The
Aztec compiler generates better code, so I'd want to use it; but since it
doen't have the assembly hooks, I can't. Oh well, I've ordered it anyhow…
That's such a strange thing: most of the assembler I write is to save code
size and get something to run fast. And to customize my startup file. The
Aztec compiler generates better code, so I'd want to use it; but since it
doen't have the assembly hooks, I can't. Oh well, I've ordered it anyhow…
That's such a strange thing: most of the assembler I write is to save code
size and get something to run fast. And to customize my startup file. The
Aztec compiler generates better code, so I'd want to use it; but since it
doen't have the assembly hooks, I can't. Oh well, I've ordered it anyhow…
That's such a strange thing: most of the assembler I write is to save code
size and get something to run fast. And to customize my startup file. The
Aztec compiler generates better code, so I'd want to use it; but since it
doen't have the assembly hooks, I can't. Oh well, I've ordered it anyhow…
That's such a strange thing: most of the assembler I write is to save code
size and get something to run fast. And to customize my startup file. The
Aztec compiler generates better code, so I'd want to use it; but since it
doen't have the assembly hooks, I can't. Oh well, I've ordered it anyhow…