C or Assembly?
ALLAN LUND JENSEN
>
>Just read a few of the conversations on the advantages/disadvantages
>of writing in C and in assembly (i.e. HEY READ THIS or something like
>that). Anyway I'll add my two cents worth. Currently I'm in my
>junior year as a computer science major and until now I've focused
>my studies in the tamer languages (Pascal,C, and yes even Fortran(it
>was required)) but I know there is real power behind assembly. Not
>to say that C isn't powerful 'cause it can do some great things. But
>what I want to known is can some of you guys and gals recommend some
>Amiga specific texts which would correspond well to what I might be
>taught here at the university? I must confess that until now I have
>been (and may still be) a little intimidated by assembly. Any advice
>or suggestions? All info appreciated. Thanks.
>
>Robert
>rban...@whale.st.usm.edu
>
>
Amiga specific assembly texts? Well, I guess that depends on what you wanna
make in assembler. Applications or games? If you want to make applications then
I suggest you get a hold of books by Paul Overaa. He has written a few books on
the subject. The title escapes me, but I seem to recall they were published by
Bruce Smith Books.
Games? Check out Aminet. As far as I recall dev/ holds some text about the
subject. HowToCode could be especially helpfull. Or try to get hold of some
backissues of Amiga Format, they one had an assembly tutorial made by Pete
Molyneux (or whatever his name is). Oh, and get The Hardware Reference Guide.
I think you'll find that most games programmers are more or less self taught.
They have learned it by looking at other people source code.
Anyway, best of luck to ya. Remember: When at first you don't succeed...give
up :)
mjp...@vaxg.isc.rit.edu
>
>Just read a few of the conversations on the advantages/disadvantages
>of writing in C and in assembly (i.e. HEY READ THIS or something like
>that). Anyway I'll add my two cents worth. Currently I'm in my
>junior year as a computer science major and until now I've focused
>my studies in the tamer languages (Pascal,C, and yes even Fortran(it
>was required)) but I know there is real power behind assembly. Not
>to say that C isn't powerful 'cause it can do some great things. But
>what I want to known is can some of you guys and gals recommend some
>Amiga specific texts which would correspond well to what I might be
>taught here at the university? I must confess that until now I have
>been (and may still be) a little intimidated by assembly. Any advice
>or suggestions? All info appreciated. Thanks.
>
>Robert
>rban...@whale.st.usm.edu
I'd advise you to stay away from it. I am a senior in CS, and know assembly and
C both. If you really have to try it, I liked Tab Books Amiga Assembly Language
by Jake Commander. But the thing is this: most C compilers output code 90%+ as
fast as asm by an expert assembly language programmer. I have seldom found
places where my compiler's (SAS6.55) code could be dramatically improved. If
you want to write the next DOOM clone, yeah, c2p has to be done in asm for
speed. But you can write in C a whole lat faster and more bug free than in asm.
In addition, the compiler does things like automatic register profiling and
assignment - it figures out what part of your code uses which variables the
most and puts them in the registers for those times.
mjp...@vaxa.isc.rit.edu
> Senior in CS... where did you get your 90% from?
From compiler profiling tests. Sorry you don't like it.
>
> In simple loop C is ~50% slower from my tests. That is with simple
> tiny loop, where C does not run out of register. With more complex
> loop you can see 400% performance degradation with the same algo
> from asm to C.
And this is exactly where C will fail. Simple tests are like that. C is
designed for projects and big programs. Look at the dis-assemble file from a
good compiler that has optimization. Not too much different from how most
people would hand code it.
> Actually you dont use many trick for c2p, where I see C compiler fail
> is that they run out of register faster then a programmer do.
Yeah. SAS/C, for example, uses A4 for its local stack. That's it. Big register
usage here.
>
> On most cpu I would say its true that you can write alot more in C VS
> asm... but I find 680x0 with a a macro assembler very productive.
> And I dunno about C vs asm code stability... depand on the person.
680x0 is a GREAT assembly language. My favorite. Did you ever try to work on a
project with >2 people in asm? Nightmare material. Link in a routine you wrote
6 monthes ago and try to remember all of the side effects that it had that you
couldn't have in C (like changing a register, a global variable, or maybe even
the stack pointer). Programming in C makes your code easier to understand,
maintain, and use modularly.
>
> Overall, I would defenetly sugest NOT to ignore assembly language even
> if you dont plan on writing code in it.
Right. If you have time/patience, learn both. But if you want to get something
done that is maintainable and understandable stick with C. Better yet, C++.
>
> Stephan
>
>
>
Tran Thai
: ...
: taught here at the university? I must confess that until now I have
: been (and may still be) a little intimidated by assembly. Any advice
: or suggestions? All info appreciated. Thanks.
Assembly can be... but not 680x0 with a good macro assembler.
1) get yourself a good editor and interface it to your assembler of
choice (Basm, genam, m68...)
2) Find an asm tutorial on how to work with intuition (2.x+)
When you have something that assemble and can give you visual feedback
(A basic printf) you can start to experiment...
Stephan
Tran Thai
: In article <45go5o$b...@thorn.cc.usm.edu>, rban...@whale.st.usm.edu (Robert Ofarrell Bankston) writes:
: >
: >Just read a few of the conversations on the advantages/disadvantages
: >of writing in C and in assembly (i.e. HEY READ THIS or something like
: >that). Anyway I'll add my two cents worth. Currently I'm in my
: >junior year as a computer science major and until now I've focused
: >my studies in the tamer languages (Pascal,C, and yes even Fortran(it
: >was required)) but I know there is real power behind assembly. Not
: >to say that C isn't powerful 'cause it can do some great things. But
: >what I want to known is can some of you guys and gals recommend some
: >Amiga specific texts which would correspond well to what I might be
: >been (and may still be) a little intimidated by assembly. Any advice
: >or suggestions? All info appreciated. Thanks.
: >Robert
: >rban...@whale.st.usm.edu
: I'd advise you to stay away from it. I am a senior in CS, and know assembly and
: C both. If you really have to try it, I liked Tab Books Amiga Assembly Language
: by Jake Commander. But the thing is this: most C compilers output code 90%+ as
: fast as asm by an expert assembly language programmer. I have seldom found
: places where my compiler's (SAS6.55) code could be dramatically improved. If
: you want to write the next DOOM clone, yeah, c2p has to be done in asm for
: speed. But you can write in C a whole lat faster and more bug free than in asm.
: In addition, the compiler does things like automatic register profiling and
: assignment - it figures out what part of your code uses which variables the
: most and puts them in the registers for those times.
Senior in CS... where did you get your 90% from?
In simple loop C is ~50% slower from my tests. That is with simple
tiny loop, where C does not run out of register. With more complex
loop you can see 400% performance degradation with the same algo
from asm to C.
Actually you dont use many trick for c2p, where I see C compiler fail
is that they run out of register faster then a programmer do.
On most cpu I would say its true that you can write alot more in C VS
asm... but I find 680x0 with a a macro assembler very productive.
And I dunno about C vs asm code stability... depand on the person.
Overall, I would defenetly sugest NOT to ignore assembly language even
if you dont plan on writing code in it.
Stephan
Martin Frost
In article <45ik9c$t...@odin.diku.dk>, ALLAN LUND JENSEN <diku2803> writes:
>[...]
> Games? Check out Aminet. As far as I recall dev/ holds some text about the
>subject. HowToCode could be especially helpfull. Or try to get hold of some
>backissues of Amiga Format, they one had an assembly tutorial made by Pete
>Molyneux (or whatever his name is).
the instructions were doing etc, and the library of routines supplied were
appallingly slow, and contained some 'unrecommended' prgramming styles
(eg poking interrupt vectors directly etc). There were two good points
however: one, the copy of Devpac 2 on the disk with the first issue of the
series, and two, any sourcecode is useful, even only for seeing what is wrong
with it...
> Oh, and get The Hardware Reference Guide.
unless the first instruction of your program is move.w #$7fff,$dff09a...
> I think you'll find that most games programmers are more or less self taught.
>They have learned it by looking at other people source code.
Arno Eigenwillig
> Yeah. SAS/C, for example, uses A4 for its local stack.
data segment.
-- __
__/// Arno Eigenwillig /\ <ar...@yaps.rhein.de> \/ PGP key
\XX/ V+49-2225-5870 /\ <Arnooo @ #amigager> \/ available
Heinz Wrobel
: Yeah. SAS/C, for example, uses A4 for its local stack. That's it. Big register
No.
--
Heinz Wrobel Private Mail: he...@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email
mjp...@vaxf.isc.rit.edu
>mjp...@vaxa.isc.rit.edu wrote:
>: Yeah. SAS/C, for example, uses A4 for its local stack. That's it. Big register
>
>No.
>
Page 193 of the SAS/C System User's Guide says :
"When you link your program, all data in the near data and near BSS hunks are
merged into one data section. When you run your program, the startup module i
loads the address of the near data section into register A4..."
Local stack, not global (A7) stack.
Doug Walker
In article <460v8g$d...@news.isc.rit.edu>, mjp...@vaxf.isc.rit.edu writes:
|> In article <heinz...@hwg.muc.de>, he...@hwg.muc.de (Heinz Wrobel) writes:
|> >mjp...@vaxa.isc.rit.edu wrote:
|> >: Yeah. SAS/C, for example, uses A4 for its local stack. That's it. Big register
|> >
|> >No.
|> >
|>
|> Page 193 of the SAS/C System User's Guide says :
|> "When you link your program, all data in the near data and near BSS hunks are
|> merged into one data section. When you run your program, the startup module i
|> loads the address of the near data section into register A4..."
|>
|> Local stack, not global (A7) stack.
A4 is not a stack, it's the data section for the program (unless you've
compiled with the DATA=FAR or FARONLY option). A7 is not a "global"
stack, it's the stack for your task. There's no such thing as a "local"
or a "global" stack.
A stack is a section of memory that is used to push and pop data items
during program execution. At any one time during execution, various
pieces of memory on the stack might contain automatic variables,
function parameters, function return values, etc. At a different time,
the same piece of memory might contain a different value. Thus, the
stack is very dynamic. It is used to hold information needed by specific
instances of a function - automatic (local) variables, parameters, return
addresses, aggregate return values, and so forth. There is one stack for
each task/process in the system.
The data section of the program, on the other hand, is not dynamic. Each
memory location in the data section is assigned to hold the value of one
global variable, string literal, or auto aggregate initializer. Thus, the
data section is definately not a stack.
With DATA=FAR, we leave A4 alone - it is not used for anything. This allows
you to mix DATA=NEAR and DATA=FAR code in the same program. If you use
DATA=FARONLY, we do use A4, which means you can't use near data in the whole
program, but it does give you register A4 back for the code generator to
use. With DATA=FARONLY, A7 is the only register we need to get access to
your program's variables unless you use stack extension (which uses A5).
We do not use a stack frame register, all references are made relative to
register A7 (unless you use STACKEXT).
--
***** / wal...@unx.sas.com
*|_o_o|\\ Doug Walker< BIX, Portal: djwalker
*|. o.| || \ AOL: weissblau
| o |//
======
Any opinions expressed are mine, not those of SAS Institute, Inc.
Michael van Elst
>Page 193 of the SAS/C System User's Guide says :
>"When you link your program, all data in the near data and near BSS hunks are
>merged into one data section. When you run your program, the startup module i
>loads the address of the near data section into register A4..."
>Local stack, not global (A7) stack.
You quoted it yourself. It is the near data section, it is not a stack
and it is global data. The stack uses A7.
Regards,
--
Michael van Elst
Internet: mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Tran Thai
: In article <diddyDG...@netcom.com>, di...@netcom.com (Tran Thai) writes:
: > Senior in CS... where did you get your 90% from?
: From compiler profiling tests. Sorry you don't like it.
I dont find the same result... Your asm version must not have been
optimized.
: >
: > In simple loop C is ~50% slower from my tests. That is with simple
: > tiny loop, where C does not run out of register. With more complex
: > loop you can see 400% performance degradation with the same algo
: > from asm to C.
: And this is exactly where C will fail. Simple tests are like that. C is
: designed for projects and big programs. Look at the dis-assemble file from a
: good compiler that has optimization. Not too much different from how most
: people would hand code it.
Simple code is where the CPU can pass alot of its time.... For example
innner loop for YUV<=>RGB, polygon rendering, backface testing, rgb->ham
, chunky<=>plannar, ARGB pixel operation, etc...
And from my test, gcc/sas cannot code anywhere near the 10% you stated.
And complex formula, if not broken down, I would stick with C... My brain
cant handle jugling with to many variable at one time :)
But we can prove all this via real life test?
I dont personally care to have code that dont reside in a loop opitimized
and thats where I will keep it in 'regular' C. Usually I will try to
optimize the algorithm I use in C after profiling, and only recode the
algo in asm when I have the time or its a must (in that case even as
little as 10% can mean alot)
: > Actually you dont use many trick for c2p, where I see C compiler fail
: > is that they run out of register faster then a programmer do.
: Yeah. SAS/C, for example, uses A4 for its local stack. That's it. Big register
: usage here.
I also use a4 for my 'local stack', Actually my program structure.
But this dont stop me from knowing when I should save it on the stack
to speedup an innerloop.
: >
: > On most cpu I would say its true that you can write alot more in C VS
: > asm... but I find 680x0 with a a macro assembler very productive.
: > And I dunno about C vs asm code stability... depand on the person.
: 680x0 is a GREAT assembly language. My favorite. Did you ever try to work on a
: project with >2 people in asm? Nightmare material. Link in a routine you wrote
: 6 monthes ago and try to remember all of the side effects that it had that you
: couldn't have in C (like changing a register, a global variable, or maybe even
: the stack pointer). Programming in C makes your code easier to understand,
: maintain, and use modularly.
No, max 2 people at a time... And we cutup the work by window/library.
We dont tend to work in each other routine or even program, and we use
tagged functions unless its a lowlevel one. This make function very easy
to work with and upgrade.
This remind me, I miss local subroutine in C.
: >
: > Overall, I would defenetly sugest NOT to ignore assembly language even
: > if you dont plan on writing code in it.
: Right. If you have time/patience, learn both. But if you want to get something
: done that is maintainable and understandable stick with C. Better yet, C++.
C code can be total chaos written by unexperienced people. But yea, if one
had the time to only learn one or the other I would stick with C...
Only a nerd can say this, but I have alot more fun writting 680x0 then C.
Stephan