#C Compilers: which one?
56 messages in this thread
Ethan, my vote is for Lattice, for a number of reasons – one big one is the
successful completion of a number of rather heft Amiga projects. These include
CoComm, Board Master, Scheme, the AVT Master, the original PCLO and PCLOplus
programs, a 68705 assembler, a 6809 assembler, the ft9600 remote control
program, as well as a number of small utilities like SetPri, Plug, and others.
Lattice has been reasonably solid through most of it's releases, and it
generally is MUCH portable code, due to the decision *not* to include in-line
assembly code, which (as far as I'm concerned) is the worst evil a C compiler
can contain. It brings out the worst in programmers.
I am currently using 5.02, and have no particular complaints. The debugger is
really nice, too.
One final point is that a great deal of the source code on the BBS's and in the
DL's is in Lattice – Lattice started out as the "official" compiler, ie, it was
supplied to the developers as part of the development package, and as a result
almosts all of the original example code is intended to compile under lattice.
The original Manx stuff not only wouldn't compile, the object format was
incompatable, a stupid move if there ever was one.
A lot of the Manx code, due to the inclusion of in line assembly code, can't be
compiled *or* ported. Yech.
–Ben-
Ben,
The fault of non-portable code rests with the programmer, NOT the compiler
vendor. Consider Lattice's addition of the "chip" keyword for instance. Use
of this extension will make code non-portable. However, I do not fault Lattice
for the extension.
Although I agree with you about in-line assembly code, it does have some
advantages. If a programmer takes advantage of the in-line assembly feature he
is producing non-portable code, just as the programmer who uses the "chip"
keyword.
Manx is a solid product and should not be depracated for the inclusion of
in-line assembly capability.
IMHO 🙂
Dave @OTG
I disagree – I think they should; I think it's one step back for a programmer
to use it – and I see absolutely no necesseity (so I can't spell… <grin>) to
include, or to *use* it.
I'm also not happy with Manx on a number of other points, specifically the 16
bit issue, the object format issue (which you now *may* as an option I believe
specify to be compatible – how absurd);
Lattice is the better compiler currently by any standard that doesn't worship
poor coding style (ie, ilac) and has been as far as I'm concerned since the
beginning.
I'm one who isn't much for gun control – people kill people, as programmers
ruin programmers. However, one can't help but to observe that if gun
manufacturers failed to manufacture guns, few people would be shot. Likewise,
if Manx hadn't put that programmer's crutch in there, portability would be a
LOT less of an issue.
Lattice is the _standard_ product, and is solid as well.
Of course, IBM is a solid product, too. So are boat anchors, eh? <grin>
–Ben-
It may be standard, but it sure isn't solid… at least not in the current
(5.02) revision.
-larry
It's in 5.03, going to 5.04, as I understand it. Solid is relative, as I'm sure
you know. I have a number of solid products that 5.02 has produced, which makes
me reasonably happy. Also, it's being updated quite regularly – and I'd rather
have the features now, with a few broke, than later, like Manx – which is
missing lot's of things, besides having things it shouldn't (opinion).
Solid is coming, certainly. In the mean time, for an "unsolid" product, it does
better than some programs that come to mind such as AmigaDOS, for one.
–Ben-
Ben,
There are no programs that can be written in Lattice that canot be written in
Manx. You are not forced to use those parts of the product that you dislike, no
matter what your reasons for disliking them. When they get it as bug free as
Manx, let me know which leg you are standing on.
-larry
Points well taken.
However, I believe that, when a programmer decides to do a quick hack,
portability not withstanding, a feature such as inline assembly code is nice to
have. Under such circumstances, this feature has merit.
I personally see nothing wrong with Manx's choice of 16 bits for ints. I *DO*
agree with you however, that not supporting the Amiga standard object code
format was a blunder of the first degree.
Lattice is my compiler of choice right now. However, I've found Manx to be a
more stable product, and the Manx compiler is available on a wider range of
PCs.
Dave @OTG
I agree that inline programming is a positive. It is an option, if you
personally don't want to use it no one is going to shoot you. If you feel no
need for portability, then use it. It also can speed crucial segments up
dramatically. Those specific segments can be rewritten as needed, as long as
they aren't too much of the program.
— Ethan
Whew! I was wondering if anyone on this network was going to agree with me 🙂
Dave @OTG
Yeah,
inline asm doesn't kill programs…
PEOPLE kill programs!
<gd&r>
–Gabe <who is getting a bit tired of these gun analogies…>
Why not just put the asm in a seperate file, assemble, then link the .o file
with your c program? You get the same benefits as inline yet remain much more
portable.
-sja
Steve, it's just a matter of being a little bit lazy. Sure you could go
through the trouble of creating a separate module, but if you don't have too
…
Opps (my grammer never was very good :-))
Dave @OTG
Why make it a separate file? Because its more difficult. This is just an
added convenience. And why would that make the program more portable? To port
it you'd still have to either rewrite the asm code or replace it with C code,
all of which could be done the Manx ILAC way. Just edit your source code file
and cut out the ILAC segment and replace it.
— Ethan
Steve,
If a piece of assembly code is modular, and callable as a function, it should
indeed be placed in a separate, linkable file. Inline asm is there to handle
those times when you really can't do that. An example might be a routne that is
called from outside your program, say by an interrupt or a system call. In this
case, it is often impossible to code it in vanilla C, because you have no
control over the state of individual register when the routine is entered, and
no way to restore them when you leave.
Ben's problem is that he has decided that inline assembly is there as a
crutch for those that can't think of a way to do something in C, while the real
reason is quite different.
-larry
I guess you put your finger on it, Dave… inline asm is good for hacks.
I don't like "hacks". I like programs – well crafted, carefully considered,
elagantly structured an dwell documented efforts.
Things that encourage less than that get the thumbs down from me; Things that
encourage style and readability within the C environment get a big thumbs up,
and things that are neutral get a neutral response.
As for Manx being available on a wider range of PC's, good for them. <grin> I
wouldn't want them to go under, really…. they keep Lattice on their
collective toes.
As for Manx being more stable – could well be – I wouldn't know.
The problem with a 16 bit environment is that it encourages small thinking. The
8088/8085 team chose 16 bits for ints, and as a result the processor is
crippled. So is a programmer that constantly builds concepts with 16 bit
limits.
The processor naturally handles 32 bit elements… and the upper level
processor use them naturally. A 32 bit program runs just as well on an 020 or
030 machine, as a 16 bit one does, and doesn't impact you all *that* much on a
16 bit one, either.
32768 to -32xxx makes me feel claustrophobic.
–Ben-
"The problem with… 16 bit[s]… is that it encourages small thinking…
crippled… is a programmer that constantly builds concepts with 16 bit
limits."
I fail to follow your logic. A processor which is 8 bits wide, or 16 bits
wide, or even 32 bits wide, limits a programmer to that bit width. To go
farther requires concatenation of registers or multiple-instruction sequences.
In a similar manner, a C which ONLY had 8 bit integers, or 16 bit, or whatever,
would be similarly limiting: you couldn't do 16 bit math without hoop jumping
if all you had were 8 bit ints.
However, the choice of which bit width to declare the default int size has
absolutely no effect on the size of one's thinking, and certainly does not
"cripple" the programmer (beyond the portability considerations we all
understand). If you need 32 bits, you use 32 bits. If you need 8, you use 8.
Do you use 32 bit Lattice ints to store ASCII characters and 8 bit quantities?
I rather doubt it. If you're going to use the right tool for the job, what
difference does it make which ones are called what, in terms of thinking size
and crippledness?
In fact, I find Manx's approach (short=8 bits, int=16 bits, long=32 bits)
considerably more sensible and logical than almost every other C's approach of
"long >= int >= short", which usually duplicates (read "wastes") one of the
variable types.
BTW, sorry to hear about your claustrophobia. Take four bytes and call me in
the morning. 8)
Rick
Rick,
A slight correction… a Manx 'short' is 16 bits… not 8, that's a byte.
🙂
Keith
Urp… it is to blush… thanks for keeping me honest!
Rick
Ben,
Inline assembly is good for more than 'hacks'. It isthere for those times
when you _must_ fit the system, rather than accepting the generalized solutions
offered by C. I have seen inline asm in code written by people who avoid asm
like the plague, simply because C would not do the job. As well, I have seen
these same people asking if there was a way to do it, with a lot of
high-powered people eventually saying that they couldn't see a way around the
problem.
If you have never had to use it, that'sfine. If you try to avoid it, that's
fine too. I'm happy for you. You should not, however, put down those who
because of what they are doing, find it unavoidable.
Readability of my code should be no concern of yours. Portability of my code
is my choice. In both cases, the finished program gives no indication of either
criteria. What difference does it make to anyone but the author?
As for 16 vs 32 bit ints, well, both compilers handle both. Lattice chose to
default to the big, slow model, with horrendous gyrations needed to generate
small code. Manx chose the other way around. Subjective opinions as to which is
prefereable are welcome. Absolute edicts are not.
-larry
Ben,
Sorry, but Lattice is not yet a solid product. I've been bit by a number of
different compiler bugs during the development of my current project. I've lost
a LOT of time to tracking them down. Granted, some of these bugs were in Beta
patches (that I needed to fix other bugs), and the compiler _is_ getting there,
but it's not quite there yet.
I even got to the point where I went out and _bought_ Manx (bucking the
tides, as usual 🙂 and converted my > 1 meg of source code to Manx, just
because I couldn't lose any more time to chasing bugs that weren't my own (and
compiler bugs are a royal pain to track down to a reproducable sequence of
managably-sized code from 1+ meg). Converting to Manx cost me about 2 days of
work (primarily because "Lattice-style" coding _is_ generally more portable),
but I have not yet tracked down a single bug that I can blame on a compiler bug
(as opposed to a compiler ideosyncracy) with Manx.
In general, I agree that Lattice is a much better product at the design
level. Hopefully, the next release patch-version will make it a stable and
dependable product. I haven't had time to really look at the later beta
patches, so I can't say for sure (although the last level I had tried was
getting there). Only wish that Lattice's compile/link speeds and
debugger-info-handling were on a level with Manx – Manx is a definite win in
those areas.
As usual, Ben, things aren't quite as black-and-white as you portray them.
But you knew that, didn't you? <grin>
…BobR
Bob,
Your discussion above points out another instance where it may not be a good
idea to wed yourself to a particular compiler. Had you used the chip keyword
in your code, you would have found yourself doing some modifications in order
to get Manx to work on it.
Dave @OTG
Dave,
Nope – I answered this "problem" in a different message to you. <grin>
Actually, in this case, I did have to do a bit of reworking, but that was not
because of the CHIP keyword, but because of Manx's insistance of merging all
data into a single segment. I decided to redesign some stuff so that I could
only put the things in Chip that needed to be there. It was a bit of a pain,
and I definitely like Lattice's ways better. Not an issue of portability,
though, just one of more flexible design features.
…BobR
Didn't Lattice also change the "status" of global variables like
'IntuitionBase' 'GfxBase'….
I mean under Lattice 3.03 and Manx 3.4/3.6 you would declare your own
struct IntuitionBase *IntuitionBase; struct GfxBase *GfxBase;
But, Under Lattice 4.0 and 5.0 you have to do
extern struct IntuitionBase *IntuitionBase; extern struct GfxBase *GfxBase;
as those globals are now declared in the standard libraries. That means the
code from Lattice 3 to Lattice 4/5 and from Lattice 4/5 to Manx is less
portable (I guess it's portable but it generates linker warnings.)
Well, of course. <grinning widely> But tell noone, you hear?
–Ben-
A little respect for history would be nice. Lattice didn't begin to improve
their compiler until they adopted many of the innovations which Manx
introduced, such as a good selection of registers for the compiler to use
(early lattice used a6 as the frame pointer, for example), ability to merge
hunks, ffp support, etc., etc., etc.
Both are fine compilers, and the existance of each has greatly enriched the
amiga.
Manx was also the first to provide a really good symbolic debugger with their
product. Of course, there are those who feel that debuggers, along with inline
assembly, are evil distractions to programmers…
sdb
Respect for history? Hmmm, maybe. Like I said, The best thing about Manx is
that it keeps Toebbes and crew on their collective toes.
I personally don't want to know what registers the compiler is using – I take
my parameters from the stack, in sections of code that are not time critical,
when I handle asm interfacing.
As the compiler improves, all I want to see is the compiled and linked
executable get faster and smaller. How and why, I could care less, unless it
impacts how I want to structure the actual C code – like _specific_ registering
of parameters, and so on.
Even if both *are* fine compilers, I currently (and always have, for that
matter) believe that the Lattice is MUCH better, and that if someone is about
to purchase a new compiler, then Lattice is the only reasonable choice. Manx is
not up to snuff on the things that I consider important.
I don't recommend both compilers, or waffle – I have an opoinion, it's backed
by a _lot_ of experience with every version of the Lattice compiler from 3.03
to (almost) the current version, and I see no reason to withhold my opinion –
especially since there are people recommending the Manx compiler, which I see
as bad advice.
–Ben-
Ben,
Manx vs Lattice is a very close contest. A person can't go wrong choosing
either compiler. I recommend Lattice for most uses, but Manx could be your
choice if you simply can't tolerate compiler bugs, or if you must port your
product to a variety of PCs.
This is *not* bad advice.
Dave @OTG
Well, you are certainly entitled to your opinion. I think it *is* bad advice –
you can indeed go wrong with the Manx compiler, as it specifically offers
facilities that encourage sloppy programming.
I contend that the Lattice is a clearly superior choice, from virtually any
standpoint. Bugs are inevetable in any new product, and the 5.0x series is a
new product. Patches are being released regularly, and that is the only area
where the Lattice compiler _could_, if you were really trying, be considered
the "lesser" of the two compilers.
But, if you're going to tak ehtat particular road, all I can say is enjoy it
while you can – because the Lattice compiler is being updated, and they're
proceeding to take away the one valid argument you have.
–Ben-
Ah, but Ben, so is Manx. When Manx adds support for ANSI, and makes a few
other additions they've been promising, I can have my cake and eat it too! But
for now we agree. Lattice is better – for now.
Dave @OTG
Note that it's been almost two years since Manx published an update… I've
heard strong rumors that they will not come out with a new Amiga compiler.
That would be a shame, and catch me completely off guard. The Amiga seems to
be a strong C market; not to develop a new C package for the Amiga just
wouldn't make sense (cents?;-)).
Dave @OTG
Now now, I clearly recall you disapproved of Manx for including a debugger,
since, as I recall, it "encouraged sloppy programming".
Now that Lattice includes a debugger, it's ok? What happens if Lattice decides
to add an asm () keyword? There goes your last argument…
sdb
<stepping on soapbox>… As in all things in our wonderfully capitalistic
running-dog society, competition fosters improvement in most cases. Such is
the case with this compiler fracas.
As it has been said (and written), Lattice was the first, and thus, by default
the best compiler available. Manx came out and, yes, blew away Lattice,
running rings around it in performance (both in compilation, and perf of
compiled code).
Now, after a couple of flips and flops in the race, Lattice again has the lead
with: a better compiler environment, from what I understand (only having used
Lattice, I do not feel qualified to knock Manx); more ANSI compliance; faster,
smaller compiled code.
Undoubtedly, Manx' next release will contain some bells and whistles that
Lattice ain't got. So what? *I* have chose to stick with Lattice. I agree
with Ben's opinion that the presence of John Toebes is a benefit that has (thus
far) no Manx equivalent. For those who prefer Manx, they will benefit too.
As for the argument about ILAC, IMO it *IS* an evil that should be avoided at
all costs IF portability is your desire. If, OTOH, you want only to use
something for yourself (/your company) and portability is not a concern, but
performance IS, then ILAC *could* be of benefit. Ben's argument about
including it as a separate, callable module simply makes more sense on the
whole, because you never REALLY know if you're ever going to port something to
another compiler &/or machine. If you ANSI compliant code, and stuff all your
assembler into a separate module, then porting, even to other MACHINES (why
WOULD one? Shucks, Look at microemacs, it has adherents on ALL machines) is
made easier.
<stepping off soapbox> –Gabe
Dave,
Getting rid of the chip keyword is a global replace option on an
editor, getting rid of in-line assembly is a whole different story.
Don
Don,
Step one is getting rid of the chip keyword. Step two is figuring out a way to
get whatever it is into chip memory.
Use of the chip keyword leads to non-portable code. Perhaps the effort in
porting it is not as severe as fixing in-line assembly stuff, but I doubt that
the fix is trivial in all cases.
Dave @OTG
Dave,
Use of the "chip" keyword is very portable. It just takes a little work on
the programmer's part. In my standard header file, I have the following:
#define CHIP
#ifdef AMIGA
#ifdef LATTICE
#undef CHIP
#define CHIP __chip
#endif
#endif
Then in my code, of course, I use the CHIP macro. Quite portable. I do the
similar things with Function Prototypes and Pre-Compiled headers. Makes for
code that takes advantage of the environment, but at the same time is more
portable (on some levels).
Of course, we can blame our tools or we can blame our styles.
…BobR
Bob,
What do you do if you're using Manx on the Amiga. CHIP becomes nothing, and
you haven't moved your data into chip memory.
Dave @OTG
Dave,
I _can_ tell the Manx linker to put all of the data segment into Chip. Not
an optimal solution, but it is possible, and I don't have to change any code.
Of course, since this was a "real" project, I took the time to do it right. But
we all know that portability almost always involves trade-offs. My choice is
to usually be portable to a certain extent, and then evaluate the trade-offs
and "cheat" on portability where appropriate.
…BobR
Ah,
I wasn't aware that Manx's linker could do such things. Still, if you didn't
want everything in chip memory, you'd have to ensure (perhaps by overlaying)
that only the data you wanted put in chip memory actually got put in chip
memory. This requirement in turn would affect the way you programmed your
module, and therefore IS a portability issue.
Stuborn, ain't I?
Dave @OTG 🙂
Dave,
You're not being stubborn, just confusing issues of portability with issues
of architectural design. Portability issues generally (but not always) involve
trade-offs. As an example, when I'm writing a program for which I don't give a
hoot about portability, I'll generally use the Amiga-specific DOS file calls
Open(), Read(), Write(), etc. rather than using the (almost) equivalent open(),
read, write() functions of the "standard" library. It's more efficient. Of
course, when I'm writing with portability in mind, I'll accept the extra
overhead and use the standard library functions 'cause it's more portable.
I agree that the differences between Manx and Lattice regarding the manner
in which Graphics-memory-specific data is handled leads to having to redesign
(to make optimal use of the architectural implementations). I bit that bullet
when I converted my 1+ meg source code. It wasn't a matter of portability,
however. In fact, I did the conversion to Manx first and got it working
(albeit less efficiently), and _then_ addressed the design issues.
…BobR
P.S. – Sorry about the time-lag in reply. I was out-of-town for the weekend
and have a bit of catching-up to do with the message base! <argh>
Who's kidding who here? If code uses CHIP memory, it means it also uses Amiga
graphics/audio primitives which are NOT portable in the first place. I think
this discussion is pointless.
Martin,
NOT SO!
If I'm creating a public domain utility and wish to make source code available,
I should support both Manx and Lattice. Therefore, I should NOT use the chip
keyword under such circumstances.
Dave @OTG
Dave,
You're missing the point. You can write code that works with both Lattice
and Manx, and still make use of the extended features of Lattice such as the
use of Function Prototypes and the __chip keyword.
…BobR
Bob,
I'm still not 100% convinced that in all cases you simply get rid of the chip
keyword and viola!, everythings ducky with Manx.
What if you're concerned about the amount of chip memory usage. If you need to
load only data items that must be in chip memory into chip memory, you'd have
to do some juggling after eliminating the chip keyword to get Manx to fit the
bill. Not much juggling, but some. In this light, use of the chip keyword,
ahough not disasterous, may require a progammer to do some extra work, should
the code be ported to Manx.
As with any portability decision, the question is how likely is it that I'd
have to port to another compiler, and how much effort will I have making that
port? With the chip keyword, the answers probably are "I probably won't ever
need to port this to Manx.", and "If I have to port to Manx, it won't be too
much extra work." With these answers in mind, you use the chip keyword.
My only point in all this, is that, "Hey! This chip keyword is a keen idea.",
as opposed to "Stupid Lattice. Making a feature that Manx doesn't support.
<grrrr>." 🙂
The same arguments apply to use of inline assembly code. Neat feature, but be
sure to ask yourself the magic portability questions before taking advantage of
this feature.
Dave @OTG
We're talking portability between C compilers… not across machines, here.
OR across languages, given your background.
My position is that (a) c is the only valid _serious_ development language for
the Amiga at this time for historical reasons (availability of source and etc)
and (b) Lattice is the only viable choice since the example source is in
Lattice, and Manx is not portable to Latitice.
–Ben–
Ben,
You mentioned that most of the available source code examples are/were
written in Lattice… while this might have been true at one time (and possibly
still is…) it seems that most everything I get ahold of these days was
written in (or ported to) Manx. Maybe this happened because of the bad state
of affairs the Lattice compiler was in for so long… but there _is_ a LOT of
Manx source code examples out there.
Keith "my 2 cents" Young
It's who you're getting your source code from, Keith – if you go for the
developers, you'll find Lattice well in the majority.
There *is* a lot of Manx junk in the Dls, unfortuneatly – it's too bad, since
it's quite often not portable. Might as well be written in BASIC.
–Ben-
I'm not sure that's true either Ben… the disks given out at the D.C.
Developers Conference had a lot of 'manx' source code on them… and these are
_the_ developers :-).
Keith
Ben,
You are basing your evaluation of Manx on your experiences with Lattice. Not
really too accurate a yardstick I think. Perhaps you should take a look at Manx
before making pronouncements like "Manx is not portable to Lattice".
-larry
Actually, the chip keyword would let you (and ARexx) pull all those references
together _automatically_ and get them into their own file. It would be very
easy to do, indeed. Inline asm essentially breaks the _entire_ module that it
is included in, and would force you to re-write it wholesale. For EVERY module
it was used in.
Since manx forces all the storage into one place (or so someone just said –
sounds stupid to me!) removing the chip keyword and compiling would be all you
need. Cross-system compiling would be worse, because by definition, if you
needed chip ram, it probably won't work on any lesser machine than the AMiga.
And they're virtually ALL lesser machines. <grin>
–Ben-
Ben,
In most instances you're right. However, as good Amiga programmers (we're all
good Amiga programmers, right? -)) we shouldn't hog the systems resources, nor
should we create situations in which a program could work (if properly written)
but does not.
Not liking hacks either (most of the time), I don't view lumping code, and data
hunks together into a single module and forcing the whole thing, into chip
memory. Older Amigas only have 512K of chip memory, but may have fast memory
available. The proper approach is to specify chip memory only for graphics
items, and let the loader decide where to put the rest of the stuff (assuming
you like multitasking and aren't intent on taking over the system).
Dave @OTG
And isn't _that_ the truth!
–Ben-
Just a note to add to what you said. (I don't have Lattice….yet….)
Version 5.04 should be out within a month or so, according to someone on
USENET.
Steve
Isn't that what they said last month Steve :-).
Dave @OTG
I remember your dislike of inline code from a TransAmi article not so
long back.
— Ethan
You do indeed. <grin>