Hey guys, I'm in the process of writing some guides on how to Convert C to Assembly. Really, I don't know what to call it. It's a very in-depth description of all the C keywords and functions, expressions and C++ objects and how it would be achieved in assembly. Two purposes are served here. 1) It will help you write assembly code akin to how it's done in C/C++. 2) it will help you integrate your asm better into C/C++ source. I'm only getting started. I have part I up for review. My version is much more complete than what is online. I presume this will take the better part of the next 2-6 weeks to complete the first 2 parts of the series. I have lots of reverse engineering to complete. However, you may get a sneak peak at http://visualassembler.freeservers.com/Research.html Comments are welcome, as are technical suggestions and corrections. I'm not looking for optimizations at this point, however, it doesn't hurt to suggest as it'll likely be strongly considered. _Shawn Udpate: Made active link This message was edited by _Shawn, on 3/30/2001 12:49:24 AM
Posted on 2001-03-29 21:25:00 by _Shawn
I was thinking of suggesting something like this. I no c/c++ expert or newbie for that matter. But then I thought someone would say, "Why dont you just look at the dissassembly". Compilers dont write it like us humans. I look forward to your guides. ps where can I see this first one you are talking about??
Posted on 2001-03-29 23:28:00 by asm_happy
asm_happy, This is part I of III. This is the first one. Like I said, it's a work in progress. It's not complete, that one you saw is about 8% complete. I just started it yesterday. Here's the breakdown I'm planning:

Part I:
  C Keywords
  C Functions
  C Expressions

Part II:

  C++ Objects/Classes
  Virtual Functions
  Poly Morphism

  Mixing C/C++/ASM Code Object Files
  Mixed Programming

Part III: (Subject to whether I can learn or not -- help anyone?)

  C Numeric Datatypes
  Signed/Unsigned Integer Math
  Floating Point Math
  Other Math Related Subjects

Part IV: (Possibly)

  Possible Various Optimizations Relating to Parts I-III

Part V: (Possibly)

  Reverse Engineering 3rd Party Applications
  Reverse Engineering Windows
  Ethics of Reverse Engineering
Okay, that's my agenda. Obviously, it won't be completed tomarrow. I'm willing to allow contributions -- specially for that math since I'm not that good... who's to say I will be. If I start on IV-V and not start III, then III may become IV or V instead. Thanks for your feedback, _Shawn
Posted on 2001-03-29 23:44:00 by _Shawn
Hmmmm, ================================== Two purposes are served here. 1) It will help you write assembly code akin to how it's done in C/C++. 2) it will help you integrate your asm better into C/C++ source. ================================== I wonder at the virtue of either of these points, writing assembler like C/C++ is like pulling the horse along with the cart, assembler has in the past been crippled by the assumptions of other languages I don't see the point of writing asssembler that badly. There are 2 ways of writing assembler in C/C++, either write the inline assembler or write modules in MASM, build a library from them and link them into your C/C++ code. The second is a beter choice in performance terms.
Posted on 2001-03-30 01:47:00 by hutch--
I see your point, hutch. Honestly, I really do. I'm not trying to always oppose you... so please, forgive me... However, I'm not advocating writing C++ and calling it assembler. I'm merely showing how it equates to assembly. At some point, more so for the newbie (and myself, in my quest to better understand how to write a full application in Assembly), you have to know how to do things in Assembly. This means you have to "think" in assembly. Seeing how assembly achieves the same effect, greatly improves my chances of "thinking" in assembly much _sooner_ than raw experience without the documentation and much trial and error. These guides aim to act as a starting point, not the final answer to all problems. Yes, the assumptions of some languages do defeat the purpose. However, if the requirements of a project mandate objects be created and used, what's the difference if I do it in C++ or in ASM? Is C++ going to achieve it better than hand coded ASM? Probly not, but, it'll make the cycle complete much quicker. But if I choose to do it in asm, then it'll get the same results. Ernie makes heavy use of OO techniques in Assembly for his COM tutorials. Understanding how to achieve OO effects in Assembly is in order, or he can't achieve the effect in the first place. Is it wrong he do it in asm? I think not. It's all a matter of point-of-view and what the requirements of the project define is acceptable. I respect your opinions greatly. I seem to always oppose, but the truth is, were it not for you, I would not have been inpired to write win32 asm in the first place. I stumbled on your site by accident during MASM32 v4 and was immediately inspired. The guides serve merely as a starting point. If I want to program C I'll program C. If I want to program Assembly, I'll do Assembly. However, it's hard to do assembly if I'm not familiar with how to achieve do-while, while-wend, and for loops in assembly. Or if-else-then and switch-cases. Those are the basic foundations upon which all apps are created. Showing how to achieve it in assembly from a C point of view does not make it C. It is still assembly, just correlating it to somethign most new programmers will likely understand easier. OOP is no different. I'm fascinated with the idea of OOP techniques in asm. Why? Because I am. Others are, too... specially if thier more of a new programmer. Someone reading that tutorial may one day get inspired because of it to write a compiler. Well, that's another case where you must know how to do it in asm what you do in C++. That doesn't make it any less assembler than it is without, considering it's still using the same mnuemonics that we recognize from the Intel Architecture manuals. Also, if it must be optimized, it's difficult to optimize when you don't understand how it's produced. It's a bit more difficult to debug if you can't recognize what a switch-case or repeat-until clause may look like in assembly. Same thing for classes, if you're debugging C++, it helps to know how the object code may be generated or you'll get lost in a heart beat. There are more purposes than one with these guides, and I aim to exploit as many of them as I can -- because I'm _Shawn like that :D I don't mean to step on your toes, please forgive me. Just have to write my book about what the intent fo these guides are. Read them if you will, or don't read them if you please. You're opinions are always welcome (and insight is also welcome). However, realize, that all of us see things differently. We all promote Assembly in different ways, but what's important, is that we're advocating it and we're sharing our differing knowledge to benefit all. I'll always look to you for solid advice and such. That's a given. But, I have greatly differeng views (however, somewhat similar) than you. I do not wish to polute it either, therefore, it must be approached carefully and I see to it that it be so. Thanks, _Shawn Thanks, _Shawn
Posted on 2001-03-30 03:05:00 by _Shawn
_Shawn. Don't hesitate - work, it's most important job you are doing. It'll be a BOMB when you've finished it and the discussion begins. Your job is needed for all serious asm programmes. You can't realize it yet 'cause you're not one yet. Don't warry - I'm with you. Do your job. And carefully learn JCC (it's the only thing you need to understand all those conditional programming including all kind of loops organizations in every language) Don't learn just basics of it, LEARN EVERY BIT OF INFO ABOUT IT! It's a core for any algo in HLL > ASM. Realization in C loops procs and conditions is a little subarray of all possible ways possible in assembly, but most of big procs are written in C, most of complex algos are written in C, Windows herself written in C, so your work will be vital bridge to asm programmers. I personally sick of dissassembling those huge and akward progs in C just to understand one more simple thing, but I have no choice - all good example of sistem and database programming are written in C. In DOS days they used to be less in size, and there still were a lot of asm programmers working proffetionaly on big projects and we can communicate. Now there are just few people you can discuss some pro task with in asm and all advanced examples in C. I know a lot of people who used to be exelent asm programmers and quited their coriers just because Windows had come. They hate C and any other HLL, (some of them didn't even use assembler - they write pure opcodes - I for example know macro langauge badly, but have no problems with understanding pure opcode) but they failed to understand it at once looking in disassmbled code. MS did everything to privent people to write pure asm code in Windows. So do your work,please. It is analiz of low level realization of C from easy topics to more complex. It'll help lots of programmers who just don't want to learn C how to understand the big complex code and figure out just what the prog is doing, after that we write the same in better way. _Svin.
Posted on 2001-03-30 09:05:00 by The Svin
_Shawn, I think it's a good idea. My philosphy in past years to my clients, my developers, and myself has and still is: "Basic Level Research first, above everything!!!". What does this mean? Start out simple, make it work well! Then, with this new foundation, built on that and improve! Do NOT reach for the stars at the beginning. That's it. To make a long story short, out of my experiences the bottom line is: It works! It works well. You can apply this philosophy to pretty much anyting including learning a new language. The helps especially when you start a new development project. So, go for it Shawn! Keep it simple, fine tune it later!
Posted on 2001-03-30 09:45:00 by rainbird
I think that anybody doing anything for the ASM community is a good thing. Keep up the good work _Shawn.
Posted on 2001-03-30 12:12:00 by tudisco
Thanks for the support everyone. More to come. To Hutch: Hutch, it was very late last night when I wrote that and I was quite tired. Reading my reply now, I think I missed something you said. I think your comments were geared towards the two points I tried to make which to you aren't real points. You did not challenge my motives or specify that what I was doing is a bad thing. Sorry if I offended or jumped to conclusions. Thanks, _Shawn
Posted on 2001-03-30 15:06:00 by _Shawn
Shawn, I am of the view that knowledge of high level language programming techniques are worth learning as it means learning architecture, algorithms, standard coding methods and similar. What I commented on was the notion that assembler should be written like C/C++ which I may have taken out of the context that you wrote it, I was trying to avoid the assumptions of other languages in constructing assembler code. The concern was to preserve the originality of code design that is still available with assembler. The worst possible case would be for assembler to be standardised into a pre-set collection of techniques where programmers stopped testing out new and sometimes dangerous ideas and just did everything in a standard way. The work that Ernie is doing in COM is a good example, he has not just followed the standard OOP techniques but has aimed the design at taking advantage of the inherent power of assembler. I personally write code with a very similar architecture to pre OOP C, not C++, because the operating system is structured that way. If the OS was written like BASIC, I would write code that way and if it was written like Pascal, I would go fishing instead. :) Just as an example, I have just mastered the design of a Boyer Moore binary search algorithm which involved avoiding the old ANSI C junk and coding it completely from scratch assembler style. When I have beaten it to death and it is tested across enough variation I will add it to the MASM32 library. This and many situations like it are the reason why I am very wary of just following C/C++ code design. I think the work you have in mind will be useful in terms of helping other programmers with the fundamental architecture necessary to write larger applications so by all means keep up the good work. Regards, hutch@pbq.com.au
Posted on 2001-03-30 17:36:00 by hutch--
Hutch, Thanks for the reply. I see where you're coming from. I agree that assembler should not be reduced to a standard way of doing things. There are so many contexts to which any piece of asm code could be written (equivelantly to any HLL) that the programmer should learn how to harness the power of assembler. Case in point: today I have been researching the mechanics of the for loop in C. I see that MS produces source one way (usually the same way no matter how I set the optimize switches), Borland produces almost the same way (again, with various optimizations) yet when I look at how Visual Basic produces it's for...next loop, it's the most highly optimized of them all. VB was the only one that used registers and similar techniques and had fewer byets (12 fewer bytes) than both MSVC and Borland C++Builder. In just a few examples, I came up with 4 different ways to do the loop. Each depending on a context. Therefore, my guides, while serving probly as a good beginners guide, will try to reflect the as many different ways it can be done and will in the mean time try to encourage experimentation. Perhaps I will have to write exercises at the end of particular sections or something... Hmm.. you bring up a good point. Thanks, _Shawn This message was edited by _Shawn, on 3/31/2001 4:55:39 PM
Posted on 2001-03-30 17:45:00 by _Shawn