#### Archived

This topic is now archived and is closed to further replies.

# ASM Question

This topic is 5496 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, when I asked some people about learning ASM for optimizing games they told me it wasn't worth it since most compilers will optimize it alot better anyway, however they also said that it would be good to know to give a better understanding of how the CPU works. Now, i've decided to learn it but the problem is, there are different versions for each CPU isn't there? So how do you write ASM code which is portable? i.e. would work on both Intel and AMD processors. Also, which version of ASM is best to learn and why? [edited by - notme on November 22, 2002 3:25:38 AM]

##### Share on other sites
good compilers (vc++,cygwin etc) can do such good job, that it is not neccessary to optimise it with asm. on the other hand sometimes (at the "time-critical" parts of the program) asm routine would be very helpful.
and according to assembly language itself, it''s not so "confusable" as you thing. intel and amd CPUs (of a same platform, of course) are in fact [backward] compatible everything but some hi-end areas (like 3dNow! @ amd, not implementable on intel cpus or so). there are some norms and standards of how x86 architecture should look like i strongly hope ;]
but - first you need to learn the basics

quote:
Original post by notme
Hi, when I asked some people about learning ASM for optimizing games they told me it wasn''t worth it since most compilers will optimize it alot better anyway, however they also said that it would be good to know to give a better understanding of how the CPU works.

Now, i''ve decided to learn it but the problem is, there are different versions for each CPU isn''t there? So how do you write ASM code which is portable? i.e. would work on both Intel and AMD processors.

Also, which version of ASM is best to learn and why?

[edited by - notme on November 22, 2002 3:25:38 AM]

##### Share on other sites
For the most part, if you’re making games for windows, you''ll want to learn x86 assembly. These are the instructions that been around pretty much ever since Intel came about.

As for writing portable code, assembly is by its very nature very platform specific. However, if it''s just Intel/AMD compatibility your concerned about it''s not hard. AMD''s chips are Intel-compatible meaning that understand (almost) all of the Intel instruction set. Just avoid anything that both don''t support (mostly new extensions like MMX and 3Dnow); thankfully both Intel and AMD have very good documentation so it’s pretty easy to see how well a given instruction is.

There are more complex ways to make the code portable, but if your just starting out this works fine.

- Zhypoh!

##### Share on other sites
I''ve been asking these kinds of questions for the past week and I''ve got some pretty good answers from people on this forum and at experts exchange.

AMD and Intel processors both have the same 8086 instruction set, the FPU and MMX instruction set. They differ when it comes to the packed floating point extensions. So you don''t need to worry about portability if you are just working with the basic instruction set (that''s the instruction set as it was before the Pentium with MMX and the Pentium 2 came out)

According to a guy on experts-exchange, the use of these extensions is only a concern for driver and OS developers. And that if you want to use them in your games, you''re better off with C++ libraries.

I''ve been told the same thing a number of times now: Learning assembler is becoming rarer and rarer and you are better off getting your program performance by learning how to write better C++ and learning good program design.

But like you, I am being told that it is useful to understand assembler just for the bit of underlying theory. If that''s the case, they mean just get to the stage where you can write a simple assembly algorithm with the 8086 basic instruction set, just so you can appreciate how your program is executed.

The best assembly book I found was Kip R Irvine''s "Assembly for Intel based computers" and that really got me sorted with being able to write assembly programs in Windows. But after that I would recommend getting Intel''s Software Developer''s manuals from their website. Manual 1 gives you a lot of descriptions on the architecture of the Pentium 4 which should cover a lot of theory that you are being recommended to know.

##### Share on other sites
Just revised a few more things.

I''ve been told that since the majority of the 3D graphics workload is on the hardware nowadays, the need for efficient assembly is much less.

If you plan to go into AI, you should NOT be learning assembler because it is difficult enough as it is.

It will be useful to learn an assembly language to be able to use the assembly languages of the new graphics cards (I don''t know if these are the same as the shader languages). You will be able to learn them quicker if you are already familiar with general assembly language, but again, that should mean that once you can get a basic algorithm written in assembler, you probably know enough. And learning these shader languages is something you only want to look into once you''re proficient with DX or OpenGL.

Probably best not to take anything you hear as gospel, because I''ve been getting a huge mix of opinions on this subject.

And I thought I knew just about all I needed of C++ and programming till I started reading posts on this board and looking at other people''s code. Now I''ve got a better idea of how far I''ve got to go and so that is my focus at the moment. Learning everything there is to know of assembler is only something I would be prepared to start if I''m being told it is very important to do so.

##### Share on other sites
Hi ... I'm an Assembler programmer ...

Very interesting subject ... this is the first time I've been to this community and this is the first thread I've ever read!

I'm a member of a community of Assembler programmers much like this community ...
http://board.win32asmcommunity.net/
if any of you are interested to see ... ask any questions ... they will help you !!!

I'm not here to "convert the heathens" as some Assembler programmers would say ... but I'd like to give you some constructive advice/information and a few good links if you are interested to see what assembler is all about!

I would like to start of by clearing some misconceptions about 32bit Assembler programming for Windows OS:
1) We can do ANYTHING a C/C++ programmer can do. Including creating an EXE or DLL, COM, ODBC, DirectX, WinSock, in fact ANY API call in Windows etc.
2) I have NEVER written Assembler code that runs slower than a C compiler ever since I started with Assembler ... to me ... the notion that a C compiler can produce faster code is a lie! For example, I have converted a few C string manipulation functions to assembler and gained an average of 15% speed increase ... and those are supposed to be "optimized" and I had only known Assembler for 1 month!
3) "Assembler is dead" is a lie Micro$oft and others want most programmers to believe! The truth is that Assembler will never die ... it cannot! To justify my statement, did you know if you have Visual C 6/.NET etc. ... you also have Assembler (Not only inline assembler but full Assembler). VC now has more support and documentation than ever on inline Assembler in MSDN. The "full" Assembler files are ML.EXE and LINK.EXE. The assembler that ships with .NET is the latest version of Assembler for 95->XP. 4) Amazing that the most powerful compiler (VB/VC etc.) from Micro$oft is available for free ... immagine that! You can download Assembler for free from Micro$oft! 5) If you can read Assembler, you can disassemble other people's EXE's and DLL's to find out how they did something or do what I do ... dissassemble my C programs to see how the compiler assembled it ... then change my C source code and recompile For the ultimate speed results from a C compiler !!! 6) You will find ways of doing things unthought of to C programmers ... when you start thinking Assember ... you will start think binary Some awesome optimizations can be made when working like this ... 7) If you understand Assembler ... C and all other languages will be a piece of cake ... and you will start understanding what's happening "behind the scenes" !!! You can do so much more in Assembler ! Now with that out the way ... I would like to give you some links to the Assembler community! A MUST read HTML tutorial on Assembler basics ... http://www.madwizard.org/view.php?page=tutorials.contents This is a MUST have for every Assembler programmer! Download and install ... plenty of examples, ML.EXE and LINK.EXE, DisAssembler and a few good tutorials! Run QEdit (Basic Editor) to Disassemble EXE's and DLL's http://www.masm32.com/ The best ASM RAD environment for you to program in with color coded ASM syntax, relies on the above package ... http://radasm.sonshinesoftware.com/ Loads of excellect tutorials and example code! http://win32asm.cjb.net/ DirectX tutors and examples http://www.scrontsoft.com/win32asmdefault.asp If you wanna see what a 100% Assembler game is made of ! http://hostileencounter.com/ I wish you all the best of luck and hope this helps if you want to get started on Assembler ... remember ... it's never too late In the assembler community we talk of HOP (Hardware orientated programming) ... the best programs will be written by those who understand the hardware ... and contratry to popular belief ... it ISN'T hard !!! Do not fear or judge what you do not understand ... Let me end of with this, you may have thought from my post that I've been working in Assembler all my life ... ain't so ... only 6 months ... and you too could be doing things a C programmer can only dream of ... ask a professional C & VB programmer like me ! We hide in the shadows ... [edited by - SubEvil on November 22, 2002 6:30:46 AM] #### Share this post ##### Link to post ##### Share on other sites Freak ... sorry ... just wanted to add something ... My friend just bought a P4 1.7Ghz with a GeForce4 and 256MB RAM. He also just bought the new Unreal Tournament ... and his PC jerks ??? What the heck is that all about ??? What's going to happen when Doom3 comes out ??? And now you guys want to rely on the C compilers to do your job ... a C compiler will never replace Assembler ... even inline Assembler is better people ... you have the best of both world here ... you can have inline Assembler which is exactly the same syntax and everything as we have ... in Assembler we don't get inline C ... Do yourselve's a favour ... spend a month or 2 fiddling around with Assembler ... you won't regret it and you can only make the world a better place ! Oh ... and I just want to remind you ... my recomendation is to learn Assembler with C ... for spead of writing source code ... use C ... for speed of source code execution ... use Assembler ! We hide in the shadows ... [edited by - SubEvil on November 22, 2002 6:34:41 AM] #### Share this post ##### Link to post ##### Share on other sites quote: I''ve been told the same thing a number of times now: Learning assembler is becoming rarer and rarer and you are better off getting your program performance by learning how to write better C++ and learning good program design. That''s hard to do without a good grasp of how the underlying hardware works. Reading some blurbs on computer architecture and "optimization tips" isn''t going to help much. To really learn what''s going on, you have to learn assembly language and know it well. --- Bart #### Share this post ##### Link to post ##### Share on other sites I''ve neither got a good grasp of programming design or assembler. But I''m trying to direct my studying towards what''s being recommended, and I''m being told that that is C++. They''re saying that efficiency is best gotten at the high levels. I might be interpreting that completely the wrong way. Maybe they are just saying that a crap overall program design is going to cause far more of a performance loss than not using assembler. But at the moment my program design is pretty piss poor and so I think that needs to be my main focus. Question is then, how feasible is it to be a proficient C++ programmer, a proficient assembly language programmer, a proficient DirectX programmer and keep up with all the latest theory on your chosen specialisation all at once? People are posting lots of stuff and not backing it up very well, I guess because it isn''t very easy to explain these things in a single post. And I get the feeling that a lot of posts are coming from people who aren''t, as yet, game''s developers (if I''m wrong, sorry). But, to back up your point, can you give us an example of a situation where, to produce the best C code, you need to know the assembler that it is going to be compiled to? Cheers #### Share this post ##### Link to post ##### Share on other sites quote: Original post by SubEvil I would like to start of by clearing some misconceptions about 32bit Assembler programming for Windows OS: 1) We can do ANYTHING a C/C++ programmer can do. Including creating an EXE or DLL, COM, ODBC, DirectX, WinSock, in fact ANY API call in Windows etc. I'm not aware of such a misconception. Everyone knows that asm allows you to achieve the same ends as other languages, albeit via a different set of syntactic constructs. For instance, all you have to do to call an API function is stuff the function arguments onto the stack (or into registers, or some combination thereof) according to the exported linkage protocol, and invoke the function. Amazingly, the APIs you're talking about are mostly written using C. quote: 2) I have NEVER written Assembler code that runs slower than a C compiler ever since I started with Assembler ... to me ... the notion that a C compiler can produce faster code is a lie! Can produce faster code than what? quote: For example, I have converted a few C string manipulation functions to assembler and gained an average of 15% speed increase ... and those are supposed to be "optimized" and I had only known Assembler for 1 month! The benefit of using tools is not apparent for trivialities. It's a bit like OO design heuristics. When you sit in your bedroom writing programs of 1,000 lines, design technique has little impact. However, when you have to develop s/w that ends up being a million lines of code, it makes a difference. The claim that you have never written an assembly program that runs slower than a C equivalent doesn't imply what you think it does. quote: 3) "Assembler is dead" is a lie Micro$oft and others want most programmers to believe! The truth is that Assembler will never die ... it cannot!

That's true. The bit will never die, either. By the way, why do you spell "Microsoft" with a dollar sign? Do you also refer to Bill Gates as "Mister Big Poopy Pants"? It's incredibly childish.
quote:

To justify my statement, did you know if you have Visual C 6/.NET etc. ... you also have Assembler (Not only inline assembler but full Assembler).

Yup. You get a lot of bits for free with it too.
quote:

If you can read Assembler, you can disassemble other people's EXE's and DLL's to find out how they did something

No you can't. Compilation is a lossy transformation. You can see the end result, but won't have a clue how they achieved it. It's a bit like listening to Beethoven. Sure, Symphony 7 sounds great, but you'll never know *how* he wrote it.
quote:

6) You will find ways of doing things unthought of to C programmers ... when you start thinking Assember ... you will start think binary

Why stop there? I think about sub-atomic physics when I write my programs.
quote:

If you understand Assembler ... C and all other languages will be a piece of cake ...

That's either a lie or an amazing piece of ignorance.
quote:

Let me end of with this, you may have thought from my post that I've been working in Assembler all my life ... ain't so ... only 6 months ... and you too could be doing things a C programmer can only dream of ...

Like hanging around the office all weekend to get your string manipulation functions working?

[edited by - SabreMan on November 22, 2002 4:45:32 PM]

##### Share on other sites
quote:
Original post by philscott
But, to back up your point, can you give us an example of a situation where, to produce the best C code, you need to know the assembler that it is going to be compiled to?

A quote from comp.lang.c seems appropriate:
quote:
by Kaz
The *avoidance* of delving beyond the scenes is what makes a superior programmer. A programmer should be able to read an interface specification, and then code to that specification without overly speculating about the behavior behind a given implementation of it. This skill comes into play not only in using an abstract programming language, but in constructing large software decomposed into cohesive, loosely-coupled blackboxes. If you write one module such that it is dependent on what is going on behind the scenes of another module, you have committed a programming mistake, no matter how clever your solution is or how many cycles it shaves off the execution.

[edited by - SabreMan on November 22, 2002 4:42:21 PM]

##### Share on other sites
You can always use cpuid to find out if its Intel or AMD...

  #define CPU_UNKNOWN#define CPU_INTEL#define CPU_AMDint GetCPUType(){BOOL bHasCPUID = FALSE;DWORD dwStdFeatures = 0;   // Standard IA featuresDWORD dwExFeatures = 0;char szMan[13];   szMan[12] = 0;   s_szManufacturer[0] = 0;   _asm   {      // First check for a CPUID instruction (at least a 486) //      pushfd         // push EFLAGS to stack      pop eax        // pop EFLAGS back to eax      mov edx, eax   // copy EFLAGS for later      xor eax, 1<<21 // Toggle bit 21 (ID)      push eax       // push changed value to stack      popfd          // put toggled value back into EFLAGS      pushfd         // push EFLAGS back to stack      pop eax        // get current EFLAGS back from stack      xor eax,edx    // see if bit 21 (ID) has changed      jz short done  // didn''t change, doesn''t have a CPUID instruction      mov [bHasCPUID], 1   // Supports CPUID      // Get Manufacturer //      mov eax, 0   // CPUID function 0 : Manufacturer + highest CPUID      cpuid      mov dword ptr szMan, ebx      mov dword ptr szMan+4, edx      mov dword ptr szMan+8, ecx   }   if(strcmp(szMan,"GenuineIntel") == 0)      return CPU_INTEL;   else if(strcmp(szMan,"AuthenticAMD") == 0)      return CPU_AMD;   else      return CPU_UNKNOWN;}

(Thanks to Simon O''Connor [S1CA] for that wee snippet)

##### Share on other sites
Faster string manipulation routine using assembler? In all case? I really doubt it. Your routine will prolly be faster in one or two case depending on what you are doing but it sure won''t be the fastest in any situation. In fact, I really believe that C standard library string manipulation routine are the fastest GENERAL and PORTABLE string manipulation routine around. Just an example. Take a routine that search in a file for a word. Say the word ''hello''. First option, search for the whole string ''hello'', comparing the five letters each time. Innefficient. Second option, search for the first letter in the word ''h'' than verify subsequent letter. More efficient in this case but what if you search for a common letter like ''e'', ''y'', ''I''. It quickly become a pain. Third option, search for the less used letter, faster, usually take less time because there is less possibility to check. BUT, all these options become less relevant if the file is a binary file instead of a text file. In a binary file, there is no such thing as rare occurence, there is no such thing as ''word''. You than have to search in a pretty different way.

All this to tell you that even if Assembler seems attractive in term of speed, it is the way you use your knowledge of the situation that will determine the real speed of things. In fact, most program written WILL be slower than a good optimized C version. The only difference on that point between C and Assembler is that bad design in Assembler can be much worse than the same bad design in C.

Another exemple with file reading. One could say that reading a file in assembler could be faster than a C relative, but did you really think that there is a difference? Particularly in DOS, where Assembler and C rely on the same interrupt. The difference is in the way you use your code. One could read a file byte per byte while another would use large buffer. What difference these two methods have? Lots and lots of time. A file of 3 megabytes read one byte at a time is way slower than a file read with a buffer. Is there a direct connection with the language used? None at all.

For more information, there is a book written by Michael Abrash talking about optimization, I think it is named Zen of coding optimization but I really don''t have time to check it out.

Hoping it will help you understand where true priority is (hence not in ''what language you make that'' but ''how do you make that'')

Maxime Thibeault

##### Share on other sites
quote:
Original post by ZixThree

For more information, there is a book written by Michael Abrash talking about optimization, I think it is named Zen of coding optimization but I really don''t have time to check it out.

If I''m not wrong, the book is Graphics Programming Black Book.

##### Share on other sites
quote:
Original post by SubEvil
My friend just bought a P4 1.7Ghz with a GeForce4 and 256MB RAM.
He also just bought the new Unreal Tournament ... and his PC jerks ??? What the heck is that all about ??? What''s going to happen when Doom3 comes out ??? And now you guys want to rely on the C compilers to do your job ... a C compiler will never replace Assembler

yeah, why don''t you write ut2020 in pure assembly?

##### Share on other sites
quote:
Original post by SubEvil
My friend just bought a P4 1.7Ghz with a GeForce4 and 256MB RAM.
He also just bought the new Unreal Tournament ... and his PC jerks ??? What the heck is that all about ??? What''s going to happen when Doom3 comes out ??? And now you guys want to rely on the C compilers to do your job ... a C compiler will never replace Assembler ...

You are a twat.

##### Share on other sites
That was the best post I''ve ever read. Nice one sabre_man. I may have a bit of a simple sense of humour, but I am always impressed when someone just posts something like ''you are a twat''.

GEEZER!

PS: I am a bit wasted as of this writing

##### Share on other sites
I spoke to SubEvil on ICQ and a thing to take into consideration about his comments on compiler''s being shit is that he never turned on optimisation options.

I couldn''t get him to explain to me what a stack frame was either.

PS: You are a twat.''

I am still really impressed with that. This guy, sabre_man is usually so bloody technical and always responds with an argument which uses half the words in the dictionary and then he just comes out with ''you are a twat.'' That''s class. To the point, needs to be said.

##### Share on other sites
After submitting the above post ... I should have known I'd get flamed! In retrospect ... perhaps I should never have submitted it, but what's done is done and here is my reply! To be honest, I'm no Assembler champion, nor am I a good representative of the Assembler community at all, I'm still a baby Assembler programmer but do not underestimate the complexity of my current Assembler projects. I'm currently busy on a multi-threaded (thread syncronization is a minor pain in comparison to some of my other problems), Socket server to manage around 20000 simultaneous connections that talks to an SQL database using the ODBC API. It has multiple dynamic arrays, including ones for the send and receive buffers for each individual connection etc. The server must be stable and fast (on request from the clients, the server must do a lot of calculations, at maximum spead, that's why I use Assembler, besides the standard data retrieval), and if you think this a trivial project to code in 100% Assembler (except the necessary API calls), I'll worship you! I've learnt what I need to know for the task ... BUT I still consider myself a baby Assembler programmer!

To SabreMan:

This is the honest truth about my Assembler conversions of the C string function(s). I only ever converted 1 function, because I found out later that they had already been converted. In my first month of Assembler studies, I needed to represent a DWORD value as a character string for MessageBox so I could see the value for myself, I feel it's often faster than using Debug. I started the function but got quite stuck because I was still new, at the time I didn't know that the Assembler community had already done this! I wasn't even a member of any "community" as such! So I decided to disassemble the MSVCRT.DLL file and study the utoa() function, because that function does exactly what I wanted to do. I just wanted to be able to do it myself ... the truth of the matter is ... my Assembler function DID outperform the C funtions ... but the REAL reason it did, was because I removed additional checks that I wouldn't need! So I would honestly say I misled you guys ... my appologies ... the speed increase was not due to my use of Assembler ... but due mostly to the removal of additional code jumps and checks (IF statements)!

My statements about disassembling code refered specifically to Assembler! Meaning, of course I know you won't get the origional C source code, you won't even get assembler code you can use "off the shelf", it will often need minor to major modifications before it can be used in your own project! For example, when I studied the utoa() function, I copied all the relevant code to a text file, and studied the assembler "source" code which first needed to be reorganised.

As for the rest ... how much assembler do you know ? From your comments ... you don't seem to be much of an Assembler programmer or supporter! Please don't use me as an example of Assembler programmers either! I am just a student of it who simply wishes more poeple could enjoy some of the benefits of knowing something of Assembler and the CPU. And I hope you will see that using Assembler has benefits, for example: Ever gone to a retail store and bought an Accounting package? It will probably give you anywhere between 60% and 95% of the functionality and features you require, and around 10% to 70% features you will never need, depending on the product. Why? Because it was written for the masses, for as many company and accounting types as possible with as many features that fitted into the design concept as possible! Consider your own Accounting program. You will implement the design you need, and none of the features you don't need. Sure, you don't have the experience of a huge company, or know what other features there are around, and it took you a while to write but you LEARNT a great deal from it and in the end ... it's about what you achieved and the satisfaction and knowledge of how it works on the inside! That's why I re-coded the C string function utoa() ... it was written for the masses ... and I'll never look back on re-coding it because I learnt how it works from the inside! And I use the example of an Accounting program because that's only one of the thing's I am employed to do here, it is up and running and in use, our in-house Accounting product took me less than 5 months from design to implementation. I have precious little game developing skills as the only game I ever wrote was a chess game, my first Assembler program. I just never added an AI to it.

One last thing ... as for your childish little comments ... I think you're tasteless and worth less than the dust under my shoes for calling me a "twat". You don't even know me, I doubt you want to know me because I certainly wouldn't waste a clock cycle of my time getting to know an ignorant looser like you! You have no idea what I'm capable of, nor do I know nor care what you are capable of, so it'd be best for you to hold your tongue and keep your lame comments to yourself! By the way, I never called Bill Gates "Mister Big Poopy Pants", what kind of ignorant childish mind could conceive such a name, do you play with children all day or do you just have an undeveloped childs brain? And I sincerely hope I just made your blood boil!

To ZixThree:

I agree that bad design in both Assembler and C will produce bad code! And I agree that badly designed Assembler code will probably produce a worse result than C code! However, make no mistake that well designed Assembler written by an experienced hand (which I am not!) will outperform the best code produced by a compiler with every optimization switch you have! After all, why are Kernel components of every major OS witten in Assembler and not in C with compiler optimizations?

Also: The language IS important under certain conditions! So, I
don't agree with your statement "Hoping it will help you understand where true priority is (hence not in 'what language you make that' but 'how do you make that')" ... when priority is Speed of execution ... Assembler is the champion ... when it comes to Speed of development ... I cannot deny that a HLL like C or VB is champion ... for the best balance between the two ... C rules Then ask yourself why Micro$oft (I think anyone with brains knows why I use a$ sign!) distributes Assembler with it's DDK! And why it's used in Database engines for optimal performance! Then tell me which language would you rather have them use when they developed drivers for your screen card! Speed of development vs. speed of execution?

To niyaw:

I never said anything like "Why didn't they make UT in Assembler" or whatever you were referring to! If they did, it probably WOULD have been released in 2020. What I wanted to say by using UT as an example was ... the question of using Assembler or C often comes down to a debate of Speed vs. Development time or Money in other words. Because to take longer to optimize something in Assembler costs money (obviously). The thing I'm worried most about is that C but especially C++ game developers depend too much on increased hardware performance! Anyway, I could go on about this but it's a boring topic for me!

To philscott:

You lying little F*C*I*G prick!
This was your ICQ question taken directly out of my chat history:

phil52scot 22/11/20 04:04 PM When you write a procedure and are using a stack frame. How do you reference the parameters and local variables?

You never asked me "what a stack frame was"!

To answer your question then (I was interrupted by work at the time): If you don't know what a stack frame is, go back to school! But that wasn't your origional question, the answer is yes, I do use a stack frame, only because they are created automatically at compile time by MASM for all functions/procedures! And I have used many methods to access data, including using [esp] offsets of code pushed onto the stack (within the stack frame) and local variable names, there are many methods to access data/variables, but as I told you before, I try to keep things simple and understandable in my ASM code! Hope that answers your pathetic little question!

Also: It is true that when I was doing some of my own code tests I didn't turn on any additional compiler optimizations, I only set the compiler to generate a Release version of compiled code which is good for most situations. But that doesn't count for the utoa() string manipulation tests! These I tested with the proper C functions vs. my custom witten functions. One point I would love to make here is ... you guys are flaming me for trying to outperform the C compilers ... well at least I'm trying! And maybe someday I will be able to produce better and faster code! What are YOU doing about that? In all honesty, many of my attempts to outperform C compiled code has been in vain! The compiler produces the same results as me or I can only beat it by reducing jumps or a few other minor things! Speed isn't a priotity though for most situations! Development speed is probably the primary consideration in a rough estimate of about 95% of all code ... no need for Assembler here I'd say

One more thing before I become more civilized, if you think calling someone a "twat" is "class", you're of the lowest levels of civilization yourself you arrogant two-faced little prick!

On a more civilized note, to you philscott, I would say you already have enough knowledge of Assembler to put it aside and continue studies and focus in C/C++. I believe you already know the basic Intel Opcodes and registers, therefore I believe you have a good foundational understanding of Assembler and I don't believe you need to know much more than that. Knowing the basic CPU instructions is all that I believe would be really beneficial or necessary in most programming situations, if you know the FPU and MMX instructions it's a bonus, but I believe going to SSE and SSE2 is a waste of time for most of us, unless you will be developing drivers, a database engine or something like that! Better to learn DirectX and other API's that use MMX etc. I don't think there is a great demand for Assembler programmers anymore, so if you want job security, go for C/C++.

My conclusion:

I do not wish to flame C/C++ or C/C++ developers! I believe every language has it's pros and cons. For example, Assembler is not the tool to use if you need to design a big project quickly! I believe Assembler has it's place, and that's where "tightly written fast executing code with minimal overhead that'll impress friends" comes in. And finally, I would just like to say that I only wish for more C/C++ developers to know the basic Intel Opcodes and registers like I believe philscott does. Just to know these will give you a much clearer idea of CPU architecture and what programming at lower levels is all about! It's not necessary to go to binary we are not machines ... just their programmers ... to know more of the machine design by learning a little Assembler can only benefit you and others!

We hide in the shadows ...

[edited by - SubEvil on November 25, 2002 9:01:41 AM]

##### Share on other sites
I asked you the question three frigging times and you changed the subject every time before saying you had stuff to get on with at work. Alright, so I made an assumption, but it sounded like you hadn''t even come across stack frames.

But my point was that a compiler can make faultless use of the esp register to reference stack parameters whereas an assembler programmer doing that would probably end up having to work through his entire code every time he made a few minor changes to the stack frame. It would be even less practical to work with than assembler is anyway, but a compiler wouldn''t have to care about that. I was just trying to say that compilers can do stuff easily that would be a real bother for assembler programmers to do, well, that''s going off Kip R Irvine anyway.

And I don''t rely on MASM''s code generation for setting up the stack frame. For some reason, my benchmarks put the ''leave'' instruction as being slower than ''pop ebp, ret''.

The reason I thought ''you are a twat'' was class is because Sabre_man was the last person I expected to say it. His replies are usually a page long and contain a lot of technical stuff I''ve never come across, so a comment like ''you are a twat'' just seemed so out of the blue, I had to laugh (being drunk at the time as well)

But aside from the petty bollocks, the main thing I keep bringing up is that I''m a student trying to learn and prepare for a career in the games industry. I want advice from people *in* the games industry, not IT managers who do a bit of game programming in their spare time, or people who just spend ages seeing how much they can beat their compiler without producing anything which they''re actually going to sell. I don''t think you, or Jan Wassenberg are in a position to lecture people about what they should be learning and what they should know, and I think you''re going to end up giving people the wrong advice. I didn''t want to learn assembler because it sounds like fun, I wanted to learn assembler because I thought it would make me more employable. And I don''t want your opinion on whether it would, because you aren''t in the relevant industry.

##### Share on other sites

I would like to join in this religious war and say that I feel life is far too short to be writing in assembler when you can get adequate or better results from using a goddamed compiler. Think about it this way - w.t.f. does a 15% increase in your string function really mean when in 18 months time your goddamed processor will be running at twice the speed anyway? It means you wasted 15% of your life to improve your code by 15% when you could have been (1) in the pub with your mates, (2) shagging your girlfriend, (3) reading Tolstoy or Sartre, etc...

I think people who want to code all assembler are kind-of like those in the BDSM scene - they obviously get lots of pleasure from their pain - and I cannot understand it at all.

##### Share on other sites
FACT
modern compilers can be pretty efficient

FACT
the average assembly programmer can''t keep track of pairing/timing etc as well as a compiler

FACT
good human assembly is better than good compiler assembly

FACT
assembly lets you do a good ol'' fastioned stalinist coersion job on the processor, you can exploit assumptions about data and do all sorts of clever tricks eg self-modifying code

personally, i do all time critical functions and infastructure in assembly. you can always link .lib files from seperate source languages and get the best of all worlds

********

A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

##### Share on other sites
Self-modifying code isn''t very clever when you have an instruction pipeline and instruction cache though is it?
I thought C/C++ had casts in specifically for compile-time type-coersion.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

##### Share on other sites
This is the something I''m still curious about. Is self modifying code possible in the win32 environment? I''m sure I read somewhere that your program''s code gets set to read only.

##### Share on other sites
It is possible to do self modifying code, think of the edit and continue stuff the compiler does, and embedding soft breakpoints by using the 1-byte int3 instruction. You have to mess around with all the permissions of the memory, and flush the cache, just to save a teeny weeny amount of memory in the exe. An optimisation from the bad old days.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley