Aztec C vrs 1.3!
16 messages in this thread
I've always thought of C as a sort of "universal macro assembler". Its
instructions are close enough to the metal of the machine that you think in
terms of bytes and memory locations rather than virtual variables. My first
exposure to C was after having finished a large project in macro assembler in
which I had written some structures which were VERY similar to C (without
knowing it!), thus enhancing the association.
I usually label C as a "mid-level language" rather than a HLL because, although
it has the structures of a HLL, it just doesn't "feel" like one to me. I have
this theory that herein lies the reason that some folks love, and others hate,
C. It almost seems as if those of us coming up from assembler and nuts and
bolts love C because it feels very comfortable… just a step up from
assembler. It further seems that most people coming at C from the other
direction — Pascal, for example — find C familiar but distasteful. Take this
with a grain of salt, because I have no evidence. Anyone caring to corroborate
or disagree is welcome to comment.
As far as your comments about trying to write real-time games and the like in
C, agreed. Every application has an ideal language.
Rick
One very nice feature of "C" the portable assmebler (sounds like a movie) is
portability. But the problem is that you have to make sure and write portable
code. Lots of different ways to do things with the micros out there. At one
time we used a language called M O L that was basicly a assembler with
different syntax. For example in INTEL speak you might say MOV AX,BX which
seems (to me) to be backward. So in MOL it was BX:AX Which I thought made more
sence. MOL was also kinda (sorta) neat in that you could take a program
written in 8080 and compile it with 8086 templetes and get 8086 OBJECT. It was
a little ahead and a lot too wierd for its time. You know I firmly believe
that lots of Assembly haters would like it better if they learned it on a
simple machine. I myself came around after being forced to write an interrupt
routine for the 6502. Now that is a nice understandable micro. Imagine
starting off with a beast like the 8086! I had to use it for a while and grew
to like the 68K line. A nice thought out cpu in comparison to the Kludge bag
Intel line of rewarmed junk!
Agreed! Me, I cut my teeth on a 4K 6800 system, then moved up to a 6809. Did a
little work on the 6502 but wasn't happy with the way the index registers were
set up (eight bits each and each one is only good for certain modes)… plus I
missed the two accumulators. 8) Since then I've been through the 8048 through
8052, 80×86, 32010, 680×0, IBM mainframe assembly (did you know that THAT puppy
has no subroutine stack? "BALR"; yuck!), MACRO-32, you name it. And after all
of that, I STILL love assembly language. Even on a <blech> 8086 it has some
nice qualities. But if I had started on a 68000 or 8086 I think I would have
developed a fear of it due to the complexities involved.
Rick
You know the thing I hate most about assembly is all of the extra gobbildy goop
you have to type in to make it assemble. I guess I am a unstructured
programer. I will never make a good german!
"… all of the extra gobbildy goop you have to type in to make it assemble."
Mmm? What extra gobbildy goop? There really isn't much more than any
similarly structured program in a HLL.
Given that you are comparing a language which requires data declaration (in
other words, we exclude BASIC and FORTRAN and the like), there really isn't
much overhead for assembler. You may have to specify where you want the
program to start in memory (using the ORG pseudo-op or equivalent) on some
systems, but there is nearly always a default, and other systems (like the
Amiga) take care of that at load time. You have to declare your variables, but
as I said, most HLLs require that too. You have to label the start and end of
the program (opening and closing braces/brackets in a HLL), and the "transfer
address"; where the program starts executing ( "main()" in C). I can't really
think of anything that stands out as being excessive. Maybe you could give me
an example?
Rick
I think he means having to code the while look instead of having the compiler
code it for you. -msl-
No I wasnt comparing it to a HLL. I just found the transition from a hardware
manual on the 8086 to MASM a big bore. Take a quick routine written with the
Mini-Assembler on the ii+ and compare it to the same thing written on a machine
runing Masm. I admit I am a Hack. Not Hacker. So that is part of the problem
no doubt. Some of the "tricks" needed to link and compile programs are a bit
excesive. My fav example is MPW for the Mac. Who in the hell came up with
that? Im sure that part of it is also the short fuse I have for programs that
make me think in a too structured form. I worked with a guy who would spend up
to three months thinking about a program before he even turned on the power.
And even with all this extra thought he would spend more time debuging than
anyone I know. Thats who I think of when I get twitchy over some languages
fussyness factor. Heres an example of how errors are handled between two C
compilers. After transfering files between machines an EOF char gets lodged
inside the end of a text file. One compiler finds it and says Illegal char and
stops the compi+I@from finishing. The other reports it and compiles te file
Ignoring the offending char. Guess which one I like?
Richard your summary of attitudes towards C based on where the people come
from (assembler or HLL) parallels my experience.
Rick,
Well, you are close. I come to C from both directions. Your comments about it
being 'in between' are exactly right, and for that reason I am not fond of it.
-larry
Larry,
I, for one, really like C. After reading The C Programming Language I could
not help but admire the elegance, simplicity, and power of C. I'll be the
first to admit that the K&R version of C does too little in the way of alerting
the programmer to potential problems in his or her source code, but these
shortcommings have been largely overcome by the as-yet unofficial ANSI standard
(Lint also works wonders in this regard).
Dave
Dan,
Well, _sometimes_ it does too little about telling you the problems in your
code, while at other times it gripes and moans about the most trivial things.
Lint is an exception. It gripes and moans about everything, effectively burying
the important stuff in the quagmire of pickiness.
-larry
About the only time I ever use lint is to clean up code after a project has
completed. I agree with you….using it during the developement phase is
almost totally useless.
Steve
Steve,
I must take exception to your comment about Lint. If you program with Lattice
C, I'd agree with you. However, Manx C does not yet support prototypes, and
will let you get away with murder in your code – Manx assumes you know what
you're doing, oftentimes to your determent. My approach with Lint under Manx C
is to go full speed ahead coding, until I've detected a run-time bug. If a
+ick perusal of the source code oesn't reveal the problem, I use lint.
However, I also do some development under Lattice C. The benefits of using
Lint are greatly diminished with Lattice, because their C supports prototypes
and is much more informative about possible source code problems.
Dave
Actually, I've never used Lint in the Amiga programming environment. Whenever I
have used it, it was in programming under UNIX. As I said, for me and the way
I code and test my programs, it's of very little use to me. I've programmed in
C for quite a while now, and I'm generally able to find my errors relatively
quickly. (Knock on wood). 🙂 In the past, (under UNIX), when I have had a
very difficult problem to figure out Lint was of absolutely no use to me
whatsoever, simply because the errors were logic errors, or run time errors.
Larry, the "D" in "D Hankins" stands for "Dave", not "Dan" <grin>. Have you had
an opportunity to play with Gimpel Lint for the Amiga? You can selectively turn
off error/warning messages that you don't care to see.
As I see it, the biggest advantages that assembly has over C, is that assembly
language programs can be made MUCH smaller than their C counterparts, and also
somewhat faster. However, I think you pay a price in development time,
portability, and subsequent code modification when you develop in assembly. As
a developer, one has to way the benefits of the two approaches (assembly versus
high level language).
Dave
Dave,
Sorry about the name. Either there is another 'Hankins' with first name Dan,
or I have somehow had it wrong all along.
Yes, I've played with Gimpel's lint, and yes, I know you can selectively turn
off error messages. The problem I see with that approach is that many of the
messages might indeed point to a real problem at some time, and turning them
off would seem to be inviting trouble.
For me, assembler has two more distinct advantages. The first is that I am
far more comfortable with it than I am with C, and the second is that I can
code faster in assembler than in C, the latter likely being a direct result of
the former. Portability matters not one bit to me, because as soon as I use any
machine specific code, portability is out the window anyway, and I seldom write
anything that does not have at least some machine specific code (otherwise, why
bother? I may as well write for the lowest common denominator).
I am also comfortable with high level languages. To me, C is neither low nor
high level, is ambivalent in its degree of checking, and far too much is 'left
up to the compiler writer'. I haven't even mentioned readability yet. There is
a good reason that human languages use more alphabetic characters than
punctuation, and compiler inventors would do well to remember that.
Ahh… search is finished… there _is_ a Dan hankins who posts to Usenet
from Portal. Sorry for the mixup.
-larry