Forum unknown
· Sound/Music/Speech
#music on the amiga
17 messages in this thread
Nick- C does *NOT* compile to anywhere NEAR as good as machine code!
I guarantee that any C code you can produce will be about 3 to 4 times the
size as hand-coded assembler, when compiled! Try it for yourself, one day!
Naturally, there are C compilers, and there are C compilers. The best being
Green-Hills, from what I've been told. But even THEN, you can usually get at
least a 50% speed increase if you write in pure assembler! As an example of
this, the Amiga flood-fill routines were written in GreenHills C, in OS 1.1.
But in OS1.2, they have downcoded them into Assembler, and they are now
running over 100% faster!
What???? Granted, you right for small benchmarks, anyone can use the little
assembler tricks to speed up and decrease code size. Have you done it (gone
thru the C-to-assembler) conversion of say, a 128K-512K size of program?? If
I had the time and ambition, yes I could get a C program smaller, using real
tight coding techniques and so forth. But realistically, if I'm writing an
ass'y language program, I myself don't even bother with that type of
'optimizing' *UNLESS* (like in the example you pointed out) it's really
needed. I have not written a quarter-meg size assembly program and the same
incantation in "C", so I can't say exactly what percentage you'd get in code
reduction. I've written an *AWFUL LOT* of assembly code (for many processors)
and an *AWFUL LOT* of 'C' code, also for manyu processors and I can tell you
the C compilers I've seen aren't too bad. If you take into account all the
code the run-time libraries 'generate' when linked in (it can a huge amount
with a dumb linker,) yes, C 'generates' a lot of code — but it's not C's
fault! Except for maybe a compiler for the 8085 (which was never remotely
designed for anything above assembler instruction set wise) the newer C
compilers do awfully good keeping up with assembly coded programs! Sometimes
I read the code generated with the new C compilers and say to myself "Gee,
that's a neat trick, I wish I'd have used that my last assembly program." !!!
Nick.
Honestly Nick. The advantage you get between Assembler over C stays,
irregardless of how much code is involved. I've got almost quarter meg of
assembler code in my game, so far… and I'll bet it would be a megabyte if
in Compiled C. Not only that, it'd run MUCH MUCH slower!
You can do intelligent things with registers that cannot be expressed in C…
Like :
MULS D0,D1 DIVS D2,D1
Which very few C compilers will ever be able to intelligently generate!
What it does, is multiply two 16bit numbers, giving a 32bit result in d1, and
then immediately after it, divides the 32bit result by a 16bit quantity in
d2, leaving the result as a 16bit result in D1. In C, the above code would
probably have been over 400% larger, and at *LEAST* 400% slower, cos it would
have done everything as 32bits to gain the same effect. Either that, or the
C compiler is *DAMN GOOD* but I've not seen one that IS, … yet.
For an example of some Assembler on Amy, look at Aterm.S in the download
library here online. It assembles down to about a 6K object code which is
equivolent to about a 30K compiled C program that does a similar thing.
I'm not disputing the obvious advantages of C, namely that program
development is FAR easier, and less bugs are resultant because register and
status problems are avoided, since they are no longer required. However, you
do NOT get something for nothing:- and you lose out on being 'in touch' with
the machine you are programming. Thus code cannot be TOTALLY optimised. My
work requires that I get the most performance out of a machine that it can
give. That means programming in optimised assembler simply to get the 'video
frame rate' as fast as possible. As an example of a poorly programmed game
written in C, take a look at Artic Fox by Electronic Arts. Since it was
written in C, it is VERY slow!! At best 2 frames per second.. and usually
less than 1! Just imagine how much faster that program would be if written
in machine code!! — Jez.
OK, Jez, but your playing a video game (apparently) and need that stuff — I
can't argue with you there. In my environment I've got software to write and
work to get done, we can't waste time diddling with what the object code
looks like…I've (we've) got product to get out. C is the best tool we can
get, given the current technology, C is the best tradeoff between assembly
language and other higher level languages. Maybe your people don't really
know now to program right (….I'm ducking…) but if you know how the
compiler generates code and what code a certain statement will generate, then
why not code in 'C?' I know (almost) exactly what the compilers will
generate for code and write my 'C' program to fit the various
compilers….They all 'think' about the same.
Yeah, your average 'C' compiler generates a "couple" of instructions per
average statement, but is there any other way to do it? You can be careful
to code in a way the compiler generates code, which isn't hard — you must
just realize the 'philosophy' in which the compiler thinks, I do, and it
hasn't put a damper on my 'C' programming technique (will you call it?)
All I'm trying to say is that I think we're arguing two different issues…
Whether 'C' works efficiently and effectively to produce a reasonable
product, in a reasonable time frame, which works, which performs to
expectations… and whether 'C' is better than assembly language. I'm not
saying specifically, hands down, etc., that 'C' is better than assembly,
*BUT* practically, when you get down to (programmer) throughput and deadlines
'C' definately comes in first in my opinion.
With the large memory spaces of todays machines, so what if the code's
larger? It's not a big deal. Just write the major portion in 'C' and leave
the rest (the real time portion) to assembly. The trade-off's between
productivity and real-output seem to make your argument a moot point. It's C!
OK, Jez, but your playing a video game (apparently) and need that stuff — I
can't argue with you there. In my environment I've got software to write and
work to get done, we can't waste time diddling with what the object code
looks like…I've (we've) got product to get out. C is the best tool we can
get, given the current technology, C is the best tradeoff between assembly
language and other higher level languages. Maybe your people don't really
know now to program right (….I'm ducking…) but if you know how the
compiler generates code and what code a certain statement will generate, then
why not code in 'C?' I know (almost) exactly what the compilers will
generate for code and write my 'C' program to fit the various
compilers….They all 'think' about the same.
Yeah, your average 'C' compiler generates a "couple" of instructions per
average statement, but is there any other way to do it? You can be careful
to code in a way the compiler generates code, which isn't hard — you must
just realize the 'philosophy' in which the compiler thinks, I do, and it
hasn't put a damper on my 'C' programming technique (will you call it?)
All I'm trying to say is that I think we're arguing two different issues…
Whether 'C' works efficiently and effectively to produce a reasonable
product, in a reasonable time frame, which works, which performs to
expectations… and whether 'C' is better than assembly language. I'm not
saying specifically, hands down, etc., that 'C' is better than assembly,
*BUT* practically, when you get down to (programmer) throughput and deadlines
'C' definately comes in first in my opinion.
With the large memory spaces of todays machines, so what if the code's
larger? It's not a big deal. Just write the major portion in 'C' and leave
the rest (the real time portion) to assembly. The trade-off's between
productivity and real-output seem to make your argument a moot point. It's C!
Honestly Nick. The advantage you get between Assembler over C stays,
irregardless of how much code is involved. I've got almost quarter meg of
assembler code in my game, so far… and I'll bet it would be a megabyte if
in Compiled C. Not only that, it'd run MUCH MUCH slower!
You can do intelligent things with registers that cannot be expressed in C…
Like :
MULS D0,D1 DIVS D2,D1
Which very few C compilers will ever be able to intelligently generate!
What it does, is multiply two 16bit numbers, giving a 32bit result in d1, and
then immediately after it, divides the 32bit result by a 16bit quantity in
d2, leaving the result as a 16bit result in D1. In C, the above code would
probably have been over 400% larger, and at *LEAST* 400% slower, cos it would
have done everything as 32bits to gain the same effect. Either that, or the
C compiler is *DAMN GOOD* but I've not seen one that IS, … yet.
For an example of some Assembler on Amy, look at Aterm.S in the download
library here online. It assembles down to about a 6K object code which is
equivolent to about a 30K compiled C program that does a similar thing.
I'm not disputing the obvious advantages of C, namely that program
development is FAR easier, and less bugs are resultant because register and
status problems are avoided, since they are no longer required. However, you
do NOT get something for nothing:- and you lose out on being 'in touch' with
the machine you are programming. Thus code cannot be TOTALLY optimised. My
work requires that I get the most performance out of a machine that it can
give. That means programming in optimised assembler simply to get the 'video
frame rate' as fast as possible. As an example of a poorly programmed game
written in C, take a look at Artic Fox by Electronic Arts. Since it was
written in C, it is VERY slow!! At best 2 frames per second.. and usually
less than 1! Just imagine how much faster that program would be if written
in machine code!! — Jez.
Nah… I have written >100k programs, same program, in both 'c' and
assembler…. Lattice 'c' for the amiga, as a matter of fact… and I ended
up with a 60k program that runs a heck of a lot faster, where about 40 per
cent of the final product is in assembler. I wrote it in 'c' first, because
it was easy, then in assembler because the performance just wasn't there. and
dropped 40k of code in the process. 'c' just can't cut it against a good
assembly programmer. –Ben–
If you'd have used Aztec it would have given you a 30% reduction of code size
to start with.
Yeah, I hear that… sometimes…. others say that the Aztec doesn't hold a
candle to the Lattice (Microsystems says so, to be exact), and I bet you for
SURE that aztec wouldn't have generated the code sequences that drive the
high performance parts of my software; I use ALL the registers in some
sections… ANY 'c' compiler has to use some registers just to tell if it's
underwear is on frontwise. Also, as a 'c' user of long standing (I love 'c',
by the way, despite it's very few shortcomings), I feel quite sure that
writing 'c' code to perform as this particular assembler code does would
yeild virtually unreadable 'c' code. And by perform as, I mean in the same
logical sequence… No way for speed. No. Way. –Ben–
Aztec blows the socks off of Lattice. I don't know what MSS is doing, but I
own both…and NEVER use Lattice unless I have to. I'm very big on Aztec.
BUT…I accept the possiblity that AZTEC may do something that MSS wants to
do in a very poor way…perhaps ports..I dont know, I havn't played with
either in almost a month. larry
Ok…. just responding to a dart thrown at my code reduction… some guy was
implying that a 'c' compiler could beat my coding… Gets me a little hot, I
guess, even tho the assumption is groundless. –Ben–
Aztec blows the socks off of Lattice. I don't know what MSS is doing, but I
own both…and NEVER use Lattice unless I have to. I'm very big on Aztec.
BUT…I accept the possiblity that AZTEC may do something that MSS wants to
do in a very poor way…perhaps ports..I dont know, I havn't played with
either in almost a month. larry
Yeah, I hear that… sometimes…. others say that the Aztec doesn't hold a
candle to the Lattice (Microsystems says so, to be exact), and I bet you for
SURE that aztec wouldn't have generated the code sequences that drive the
high performance parts of my software; I use ALL the registers in some
sections… ANY 'c' compiler has to use some registers just to tell if it's
underwear is on frontwise. Also, as a 'c' user of long standing (I love 'c',
by the way, despite it's very few shortcomings), I feel quite sure that
writing 'c' code to perform as this particular assembler code does would
yeild virtually unreadable 'c' code. And by perform as, I mean in the same
logical sequence… No way for speed. No. Way. –Ben–
If you'd have used Aztec it would have given you a 30% reduction of code size
to start with.
Nah… I have written >100k programs, same program, in both 'c' and
assembler…. Lattice 'c' for the amiga, as a matter of fact… and I ended
up with a 60k program that runs a heck of a lot faster, where about 40 per
cent of the final product is in assembler. I wrote it in 'c' first, because
it was easy, then in assembler because the performance just wasn't there. and
dropped 40k of code in the process. 'c' just can't cut it against a good
assembly programmer. –Ben–
What???? Granted, you right for small benchmarks, anyone can use the little
assembler tricks to speed up and decrease code size. Have you done it (gone
thru the C-to-assembler) conversion of say, a 128K-512K size of program?? If
I had the time and ambition, yes I could get a C program smaller, using real
tight coding techniques and so forth. But realistically, if I'm writing an
ass'y language program, I myself don't even bother with that type of
'optimizing' *UNLESS* (like in the example you pointed out) it's really
needed. I have not written a quarter-meg size assembly program and the same
incantation in "C", so I can't say exactly what percentage you'd get in code
reduction. I've written an *AWFUL LOT* of assembly code (for many processors)
and an *AWFUL LOT* of 'C' code, also for manyu processors and I can tell you
the C compilers I've seen aren't too bad. If you take into account all the
code the run-time libraries 'generate' when linked in (it can a huge amount
with a dumb linker,) yes, C 'generates' a lot of code — but it's not C's
fault! Except for maybe a compiler for the 8085 (which was never remotely
designed for anything above assembler instruction set wise) the newer C
compilers do awfully good keeping up with assembly coded programs! Sometimes
I read the code generated with the new C compilers and say to myself "Gee,
that's a neat trick, I wish I'd have used that my last assembly program." !!!
Nick.