Jump to content

  • Log In with Google      Sign In   
  • Create Account

Why bother to learn assembler?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Gandalf   Members   -  Reputation: 122

Posted 20 January 2000 - 08:01 PM

Is it really possible to make a better grapic engine with assembler? Isn´t that very hard and rather meaningless? Every game company I have visit only use DirectDraw/3D.

Sponsor:

#2 SteveC   Members   -  Reputation: 122

Posted 20 January 2000 - 08:16 PM

I''ve also heard a lot of folks frown upon assembly in other applications as well. And for the vast majority of stuff, including most game development, you can just go with C/C++ or whatever.

The critical thing is to profile the application and find the CPU bound bottlenecks, and only then consider hand-written assembly.

I''m in favor of it under these circumstances for a couple of reasons:

1) You may not be able to use the compiler that will generate the fastest code because you don''t have access to it or cannot incorporate it into your build process.

2) Even when using these compilers you can often still squeeze a bit more performance out of a handwritten assembly routine, particularly if it is a task that loops over a large amount of data.

3) Your compiler may not support the latest instruction sets ( such as SIMD ) available on the platform you are developing on. Or you may have to set the rest of the app to choose the lowest target processor, but you could always do special builds of modules to get processor specific code, but that complicates the build process.

I''ve had experiences at work where I''ve had to prove that the hand written assembly I wrote was faster than the optimizing compiler we had access to. It was, but not by that much, however, since we were trying to squeeze every ounce out of it, we went with the hand written assembly.


#3 I-Shaolin   Members   -  Reputation: 138

Posted 20 January 2000 - 11:09 PM

Well, I hate to burst everyone's bubble here, but you still need to know assembly. If you are aspiring to become a professional game developer, then assembler is still very much needed.

Although optimizing compilers are good for handling a lot of things, many subtle hardware details can only be truly exploited using assembly. You'll find this especially true with console development. Take the Playstation for example. It is capable of performing some tasts asynchronously. By knowing the number of cycles these tasks take, you can squeeze out the most performance of the system with assembly by minimizing the wait time of the system.

True, not everything is written in assembly, but many console graphics engines are still pure assembly, and this is not going to change with new sustems like the PSX2, since they have even more exploitable hardware.

Edited by - I-Shaolin on 1/21/00 5:11:23 AM

#4 Gandalf   Members   -  Reputation: 122

Posted 20 January 2000 - 11:37 PM

Anyone know any good books in assmbly? And the best compiler? Asm? Is it very hard to learn (compare to c++)?

#5 SiCrane   Moderators   -  Reputation: 9662

Posted 21 January 2000 - 06:54 AM

Three common asm compilers: nasm, masm, tasm.
I''ve found tasm to be fastest, but nasm is free. masm seems also likely to mess with your code even if you tell it nicely to not mess with it.

Assembly isn''t hard to learn once you figure out how the higher level functions look in assembly. Then you basically start working at that higher level.

Another reason to work with assembly directly is that some compilers incorrectly optimized numerical algorithms. i.e. it thinks that (x * y) * z is the same as (z * x) * y. For some values of x,y, and z that isn''t true. Especially when x, y or z are close to machine epsilon

#6 foofightr   Members   -  Reputation: 130

Posted 21 January 2000 - 08:36 AM

when is (x * y) * z not the same as (z * x) * y ?

It''s the law of multiplicative associativity, or something.. i forget the correct term

#7 Notwen   Members   -  Reputation: 122

Posted 21 January 2000 - 09:17 AM

Unfortunately, a computer is not a pure mathematical realm, and is forced to deal with actually implementing the numbers.

Because of this, ordering can make a difference if you are dealing with numbers that approach either an underflow or overflow condition.

For example:

really small float A * really small float B* really big float C
can result in 0 while

really small float A * really big float C * really small float B does not.



really small float A

Notwen

#8 I-Shaolin   Members   -  Reputation: 138

Posted 21 January 2000 - 11:59 AM

Well, here is the address to a sight that has an online book about assembly. I don''t know how good it is, but from what I glanced at, it seems like a good starting point.

http://webster.cs.ucr.edu/Page_asm/ArtOfAsm.html

Also, learning assembly is more of a new way of programming, instead of just learning another language. Every CPU has a different instruction set, but once you learn assembly on one processor, you can pick up other processors rather quickly. It''s a lot like being able to pick up new programming langueages a lot faster after you have learned your first one.

I personally don''t find assembly difficult. In fact, it''s rather easy. You just have to think a little lower level than you''re used to. In fact, many programmers who first learn assembly have the urge to start writing everything in assembly since they feel they have more control.

#9 bit   Members   -  Reputation: 122

Posted 21 January 2000 - 12:38 PM

Hey guys, don''t forget about my Win32 ASM Game Programming Series here on gamedev. It isn''t the most comprehensive piece of text on learning asm, but I have heard good things about it.

Besides, it covers assembly language as it is used for what we all come here for ... GAMES!

Anyway, you can find it in the programming section if you are interested -- or I have direct links on my website.

The Art Of Assembly Language link that I-Shaolin posted is a good starting point for learning the intricacies of the language itself. However, it is based on DOS which, as we all know, is dead. But, if you really want to learn the "ins" and "outs" of assembly that book is a good read.

- Chris
http://www.fastsoftware.com


#10 BrianT   Members   -  Reputation: 122

Posted 21 January 2000 - 01:15 PM

Gandalf asked about learning assembler and recommended books.

Assembler is surprisingly easy to learn. In fact, I think it''s much simpler than people expect, as there are very few syntax rules, and a fixed set of instructions. The hard part about assembler is doing it *well*. Assember is just building blocks - putting them together in an effective way is the challenge (and the fun!)

Right now I''m about halfway through the book "Michael Abrash''s Graphics Programming Black Book" which covers optimizing assembly and C, 3D graphics, VGA programming, etc. Fantastic book - but you need a fairly good assemby understanding first. Included on the CD is the entire book "Zen of Assembly Language" which I think should be required reading for all game programmers and anyone else interested in assembler.

http://members.xoom.com/alexfru/elinks.html also has some great learning links for assembler.

One drawback to assembler - portability. What you write in assembler on a Intel machine will have to be rewritten for whatever else you want to port to (Mac, consoles, etc). I recommend frame programming in C, and writing only the speed-critical stuff in assembler.

Later,
Brian

#11 DarkMage139   Members   -  Reputation: 294

Posted 22 January 2000 - 07:46 AM

Oh yeah, Assembly is cool. But keep in mind that there a lot of Win32 programmers around here. Assembly for console, well I don''t know much of that. But wasn''t assembly really a DOS thing (5 percent of DOOM was written in Assembly, the rest in C)? They used it to "accelerate" their games. But in Win32, I don''t know anybody who still uses Assembly to optimize games. And since game programming is mostly data manipulation, there has to be some way to get the game to run fast enough.

#12 BrianT   Members   -  Reputation: 122

Posted 22 January 2000 - 08:54 AM

> Assembly for console, well I don''t know much of that. But
> wasn''t assembly really a DOS thing (5 percent of DOOM was
> written in Assembly, the rest in C)? They used it
> to "accelerate" their games.

What I meant by consoles is N64, Sega, etc. Doom is a good example, for if it was written entirely in assembler, we''d never see it anywhere except the PC. With C code, you just recompile (and tweak) for your target platform. With assembler, you have to rewrite. So if you envision someday having your game run on a N64 or whatever, write as little as possible in assembler.

> And since game programming is mostly data manipulation,
> there has to be some way to get the game to run fast
> enough.

Amen, brother. Using assembler to increase speed *should NOT be done first*. Focus on the design, and improve the speed from the design level. Then see if you can improve on the C code. Once you''re sure you''ve got it as fast as it will go in C, then drop to assembler if needed. Well written C will outperform poorly written assembler.

Brian




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS