#C Compilers: which one?
35 messages in this thread
So in short, Ben, you recommend that everyone switch to Lattice and then we'll
have no problems, right? Aside from the ANSI C stuff, which I wish Manx would
do RSN, why are all those other Lattice-isms good for us? And where is all the
Manx code with inline asm? I see very little of it. You make it sound like a
big reason to avoid Manx – simply because some bad programmers use it? Next
you're going to tell me that Manx leads to immorality and bad coding practices,
right? 🙂 – John Foust
I do have Lattice 4.0, and about four other compilers for my PC. So I have
plenty of documentation. 🙂 I haven't seen 'cpr' except for a few minutes at
an AmiEXPO. Sorry Ben. What's wrong with the Manx 'make'? I'd say 'sdb' is
more broken than 'make': The lack of FFP support in 'sdb' really annoys me.
John,
This is Dave *not* Ben. What's wrong with make? Try "make directory:file" for
example. And if you get that to work, then try "make directory:file.o", and if
you figure out how to get that to work, finally have make follow dependancy
rules that work across different directories.
Manx's make is broken.
Both sdb and cpr have shortcommings. Both can be improved. However, I favor
cpr.
Dave @OTG
Is 'make foo:roo' legal? My 'makefile's understand dependencies on files that
are in other directories… For example, I have a SUPP: directory for
InterChange. If I'm in the Sculpt module directory, called /sc, and something
in SUPP: needs making, the makefile 'cd's to SUPP:, makes, then comes back and
finishes. Is that what you mean?
I'm not a 'serious' C programmer (yet), but I always see this thing 'foo' being
mentioned. What is it?
I'm not sure of its orgin, but 'foo' is used to mean "any program" or "any
function".
Dave @OTG
Yeah, it's the generic name used in tests. I myself use gaga. In the UK, they
seem to like using fred.
Luciano,
The word "foo" is used to denote any function, program, variable, etc.
when describing, or demonstrating a piece of code. You'll also see "bar" used
in the same way.
Those terms' origins are deep in the history of the computer, just as
the word "bug" is deeply rooted in computer history. Way back when, things
easily got out of hand and became FUBAR (cleaned up…that is an acronym for
Fouled Up Beyond All Recognition <I'll let you figure what got cleaned up>) and
verbaly…that translates to "foobar". Programs thus were "foobar" so must
have consisted of "foo" and "bar".
The usage of "foo" and "bar" slowly became generic for anything in a
program when trying to explain it or demonstrate a usage, etc.
Don
p.s. The history of "bug" came from way back where computers took up whole
rooms, had lots of tubes and generated tons of heat. When something would go
wrong…it wasn't at all uncommon to find an insect (literaly…fly, moth, or
what have you) who got fried and shorted a circuit. Thus, if something wasn't
working right…there was a "bug" in it.
Don, don't forget SNAFU (Situation Normal All Fouled Up), it goes hand in
hand with FUBAR.
Speaking of history: I read about an old vacuum tube computer that was afraid
of the dark. They used a lot of those NE-2 neon bulbs in various parts of the
circuitry. The NE-2's would change properties depending upon the amount of
ambient light. When they would turn off most of the lights in the computer
room, the computer would crash. As long as the lights stayed on, the computer
would keep working.
We've come a long way.
Geo
Geo,
I knew about SNAFU…but never heard the one about the computer that
was afraid of the dark. I'll have to keep that one for future tidbits.
Don
yet another variation on FUBAR…
TARFUN… Things Are Really Fouled Up Now.
-larry
Does Lattice's make accept the colon in a dependency? I can't imagine how it
would parse it… What's the difference between
object:foo.o: source:foo.c
and
object: foo.o: source:foo.c
See?
Dave,
It's not the ':' that screws up the parser. It's the same for any multiple
path dependencies. (see my example in my message to John).
…BobR
Maybe I should send you one of my makefiles, and you can look at it to see if
it's doing what you think it isn't doing. 🙂
Dave,
well, I'm afraid I have led a deprived life. I've never seen the UNIX
make, since that seems to be the one you are comparing to. I've only been
exposed to the Manx one, and it is quite functional in my case.
Brian J. Bartlett
Brian,
I was comparing Manx's make to Lattice's lmk. Manx's make is a semi-functional
utility 🙂
Dave @OTG
Dave,
I'll have to take your word for it, since it's been highly functional
here. I must be missing something.
Brian J. Bartlett
Brian,
I am refering to Manx's make utility not understanding
c.o:
default rules across files. You can work around this shortcomming, but you
shouldn't have to.
Dave @OTG
Dave,
a working make utility? Mine has been quite functional for as long as I
have had Manx. I don't know what version you were looking at.
Brian J. Bartlett
The same version you've probably got. Max's make cannot understand dependancy
rules that span directories – a sin I find difficult to forgive.
Dave @OTG
Dave,
I use a PD make, and have yet to find a problem with it. As with anything
supplied with a compiler package as a 'frill', I will look at it and either use
it or not, depending on how it is. Good example is editors. I have at least 4
or maybe 5 packages that come with their own editor, and don't use any of them.
Can you imagine anyone actually using LSE?
-larry
I haven't had time to really evaluate LSE. On the surface LSE seems ok, but my
editor of choice at the moment is probably a heck of a lot better. Believe it
or not, some developers still use ed! Once an editor is learned, there is a
tremendous disincentive to try something new.
Make is such an integral part of the development process that I'd think you'd
make sure it worked if you were selling it along with a compiler. Then again,
who ever heard of buying a compiler because it had the better make utility? 🙂
Dave @OTG
Oh, I've just had it with the C compiler wars. It's like the real issues for
real developers suddenly don't matter any more, the only thing that counts is
some untested, flashy new features that saves 10 percent on some obscure type
of function call. I've got several megs of source code here. I'm not even
going to switch to the newer Manx until I'm confident it's not going to
introduce bugs into my shipping code. Why should I have taken the chance to
jump to Lattice 5.0 without waiting a reasonable time to let them shake the
bugs out of it – even if I had been using Lattice to start with? It just
doesn't make sense to me.
Immoral? That's easy: "not moral". 🙂
John,
There are a number of issues where Lattice does provide some real
improvements over Manx (and also some areas where Manx has the advantage). I
find Manx's biggest shortcoming in that you are limited to a single data
segment, which means that I have a choice of either putting all of my data into
Graphics memory if something is required there, duplicating the required
Graphics memory both in the compiled-code (presumably in Fast memory) and in
allocated memory at run-time, or externalizing that data and having to load the
data at run-time separate from the executable load module. Personally, I'm not
crazy about any of these options, and find that Lattice's manner (particularly
the pre-5.0 manner of compiling the graphics data as a separate object module
targeted for Graphics memory) allows me far greater flexibility. The 'chip'
keyword is also useful if I only need a small number of definitions, but isn't
really needed (IMNSHO).
…BobR
Bob,
On the otherhand, lc seems to insist on breaking stuff down into an excessive
number of segments. If your program is small enough, you can get around this
with SMALLDATA and SMALLCODE. I've got a 150K program which takes about 6
seconds to load from ram:! Breaking code into an excessive number of segments
makes the loader go into overdrive, not a pretty sight :-).
Dave @OTG
Dave,
There is a way around Lattice's tendencies to create many, many tiny hunks.
Granted that it's not the "default", but that's why God invented 'make' <grin>.
All you have to do is give cute names to the various segments created during
the compile process, using the same name for the segments that you'd like to
coalesce during the link process. Blink will happily combine hunks of the same
type and name, so that there is middle ground between the extremes of
SmallCode/SmallData and overly-excessive scatter loading.
Note that I said that you had to use "cute" names for the segment. That's to
keep you from getting bored while setting up your makefile. It's not the most
pleasant task, but it does give you a lot of control over the structure of the
final executable module.
Hope this helps….BobR
I can hardly wait. I think I'll name the segments, grr, argh, and ?#*!!!
(well, maybe not ?#!!!) 🙂
Dave @OTG