I agree with that, even though I don't really know how to code that way, at the moment. I'm too ingrained with my function based programming, that I'll probably have to set quite a bit of time aside to let myself learn and get use to that, but I need to get more used to ASM before I do that.
Posted on 2006-06-29 19:36:29 by Bobbias
Synfire,

If you really believed that, then why use INVOKE, or macros at all.


    Because I see value in INVOKE, MACROs, .IF, .END, etc.  I don't see much value in PROCs.  I already explained why I believe PROCs don't add anything useful to source code.  Besides they get between the programmer and the problem.  Therefore I consider them a nuisance.  Ratch

Bobbias,

I agree with that..


    Since you have not designated whom you are addressing, I don't know what or whom you are agreeing with, or why.  Ratch


Posted on 2006-06-29 21:03:54 by Ratch
lol, sorry, I agree that coding without using invoke, .IF and all those other things are more or less an asset, than a necessity, but they do help speed things up. understanding an unencapsulated proc/invoke-less program written in "pure ASM" using the call keyword, and otherwise without any objects written as complete procedural code is much harder to understand, and to work with (say, as an API in attempting to do something, eg. writing a library of torrent functions to be included in a torrent tracker, ro somesuch application written in ASM). In a case like that, OOP concepts, invokes, .IFs, macros, and all those "non-pure" ASM elements greatly increase someone's understanding, and ability to figure out, and work with quickly, as opposed to requiring aan in-deapth analasys of what the code is doing.

Higher level programming languages in this case, evolved into using routines, proc's, and all that sort of thing more because it's easier to unserstand than seeing a piece of code lbaelled dog_bark: in the middle of your program,. for instance.

Much of these higher level assembly things come from people who've worked in high level languages, and aren't used to ASM, ro are unable to fully write in a procedural mannear, as assembly was originally intended, which means that though unnecessary, and possibly a nuisance, this code brings some of the benefits of high level langauges into assembly, speeding the programming process up a little.

Sorry if i seem like I'm rambling at all, but this is what I think about these sorts, of things, and I do believe that I should learn to write in "pure assembly" eventually, but right now, I'm still in OOP mode.
Posted on 2006-06-30 00:17:59 by Bobbias
Bobbias,

lol, sorry, I agree that coding without using invoke, .IF and all those other things are more or less an asset, than a necessity, but they do help speed things up.


    Hm.  Things are a little off track here.  Looking back at this thread, I or no one else advocated NOT using INVOKE, HLL, or MACROs.  Only I advocated NOT using PROCs.  Let's go down the line.  INVOKE is good because it allows one to write several parameters on one line along with the subroutine.  And it also makes sure that the number of parameters is correct.  That is better than PUSH, PUSH, PUSH,...,CALL .  HLL is nice because its implicit labels don't clutter up the source code.  MACROs are great for useful functions and generating consistent in-line code.  I like 'em all except for PROCS.  If you don't like 'em, then it would be interesting to know why.

Higher level programming languages in this case, evolved into using routines, proc's, and all that sort of thing more because it's easier to understand than seeing a piece of code lbaelled dog_bark: in the middle of your program,. for instance.


    They did?  It is?

Much of these higher level assembly things come from people who've worked in high level languages, and aren't used to ASM, ro are unable to fully write in a procedural mannear, as assembly was originally intended, which means that though unnecessary, and possibly a nuisance, this code brings some of the benefits of high level langauges into assembly, speeding the programming process up a little.


    I did not know that the authors of the HLL features of MASM also worked previously in high level languages.


Sorry if i seem like I'm rambling at all, but this is what I think about these sorts, of things, and I do believe that I should learn to write in "pure assembly" eventually, but right now, I'm still in OOP mode.


    You can't help but write "pure assembly" if you use MASM.  It will error if you try to combine it with another language like C, for instance.  Some languages allow you to insert in-line asm, but MASM does not allow any other language within its source code.  Ratch
Posted on 2006-06-30 01:00:06 by Ratch
As a reminder, I am not a Win32 programmer and do not have much experience in using assemblers like FASM or MASM, but TASM. In my humble opinion, procedures are nothing but an offsets of the label used to declare their alias from the beginning of the segment in which they are declared. What might confuse the programmer are the instructions not the procedures. Procedures in 16 bit TASM do absolutely nothing but to hold an offset relative to the segment. Therefore, if one knows what an offset is, he or she would probably be able to understand what a procedure in ASM is. Nevertheless, what MASM does in a procedure, although weird, can be useful in too many cases.

Ratch…
Right now, I have no idea what you mean by “obfuscating??? the code to the beginners. I think we should first define “beginners??? then we might be able to discuss this issue. A beginner in my opinion should know about the basics of the assembly language before starting to write working programs. Learning the theory is great but experience is the best teacher. Therefore, if you know what jumps are and have a good understanding of what the stack and the other useful parts of the program are, chances are that you will make programs that work faster and are easier to maintain. I think everybody could write a code that only he or she would be able to understand, but that is not the point. If procedures allow you to be able to maintain your code faster then you should go for it. Believe me, almost one hundred percent of the ASM coders, precluding the absolute rookies, do already know what a procedure is and how it works. Therefore, what is “obfuscating??? the code to the beginners is what MASM is doing to the final generated code inside the procedure not the procedure itself.


If you are absolutely sure that the code you are writing is just meant to be read by you, then you can do any tricks when necessary to make the code work faster and more optimized. We all know about the pairing and how sometimes using “ADD REG, 1??? could pair with other instructions adjacent to it but not the “INC REG??? thus writing something like that could confuse a beginner user even more.

I am not contending with you over the style of coding, I just believe that you should know what and who you are coding for and apply the necessary changes to the code to make it fit the bill.
Posted on 2006-06-30 04:11:51 by XCHG
XCHG,

Right now, I have no idea what you mean by “obfuscating??? the code to the beginners. I think we should first define “beginners??? then we might be able to discuss this issue.


    By obfuscating, I mean that PROCs confuse or make opaque so as to be difficult to perceive or understand what is happening in the subroutine definition.  If you read the documentation about PROCs, there is a lot of bells and whistles that can be confusing to a beginner.  The definition of a beginner, in my opinion, is someone who does not know most of the important basics of how MASM operates. 

A beginner in my opinion should know about the basics of the assembly language before starting to write working programs.


    Yes, that is nice, but most don't.  The documentation does not explain it all that clearly sometimes, and part of the learning process involves writing programs to see what happpens.

Learning the theory is great but experience is the best teacher.


    Exactly, and getting experience involves writing programs even when one does not know very well what one is doing.

If procedures allow you to be able to maintain your code faster then you should go for it.


    Code maintenance is usually not a speed issue.

Believe me, almost one hundred percent of the ASM coders, precluding the absolute rookies, do already know what a procedure is and how it works. Therefore, what is “obfuscating??? the code to the beginners is what MASM is doing to the final generated code inside the procedure not the procedure itself.


    I don't think so.  If you look at the MASM coding problems posted on this board and others, a very high percentage are about PROCs; what they are doing and how to make them do what you want.  That makes me feel that PROCs are causing more consternation and confusion then they are worth for beginners.  Perhaps the support staff can comment on this point.

Therefore, what is “obfuscating??? the code to the beginners is what MASM is doing to the final generated code inside the procedure not the procedure itself.


    If a programmer does not know what MASM is doing inside a block of encapsulated black box Fort Knox generated code, sooner or later that will come back to bite him.

We all know about the pairing and how sometimes using “ADD REG, 1??? could pair with other instructions adjacent to it but not the “INC REG??? thus writing something like that could confuse a beginner user even more.


    Writing code a certain way in order to be more understanding to nubes is not the way to go.  The code should should be written to facilitate the program, not the other programmer.  Documentation is the way to explain what is going on.

I just believe that you should know what and who you are coding for and apply the necessary changes to the code to make it fit the bill.


    Again, I don't code for a person.  I code for program size and speed and to hell with anyone else.  Documentation solves the comprehension problem.  Ratch





Posted on 2006-06-30 09:40:50 by Ratch
Again, I don't code for a person.  I code for program size and speed and to hell with anyone else.  Documentation solves the comprehension problem.


Haha, my highschool programmign teacher would hate you. He always tought that code should be extremely readable, and all that other stuff, because he decided that since programming teams are common, we should code as though we were a part of one 24/7

I code that I myself know what's going on, and make EXTENISIVE use of comments in the program.
And I make sure that my program is as efficient as I can make it without seriously spending time optimizing.
Posted on 2006-06-30 17:41:12 by Bobbias
My personal oppinion is optimization comes before readability, unless you are writing a book/tutorial. Any code that is meant to be ran should be optimized, leave comments for readability where needed. I do believe in writing readable code, but not at the sacrafice of optimization. Readability is always an afterthought for me. The difference is, if development time is critical then PROC's and such are an asset which should be used.

If you look at the MASM coding problems posted on this board and others, a very high percentage are about PROCs; what they are doing and how to make them do what you want.  That makes me feel that PROCs are causing more consternation and confusion then they are worth for beginners.  Perhaps the support staff can comment on this point.


I agree with that. My view is not that PROC's are bad, but should only be used once you have a good understand of what they are adding to your application. For me, that goes for all HL constructs and macros.

Writing code a certain way in order to be more understanding to nubes is not the way to go.  The code should should be written to facilitate the program, not the other programmer.


But when working in groups what is apparent to one person is not always apparent to the other person. Fact is, I've handed code off to people which I would hardly condsider "nubes" and it's rare that they would understand fully what my application does unless I clean up the code. If you think your source code will ever be handed off to another human being, then you should make your source code readable. Honestly, I'm not sure how readability effects the current conversation as I feel the STRUCT method is very readable. I just think it's overkill, and adds a lot of unneeded typing, and I personally wouldn't use it. But then again I've also been known to use fastcall on smaller routines to keep from having to type PROC's.

I code that I myself know what's going on, and make EXTENISIVE use of comments in the program.


I've personally never seen any of your source code, but I do believe that there is a such thing as over commenting. Comments are good, but should only be used to point out what isn't apparent (an application isn't meant to be a tutorial so commenting a line like 'xor eax, eax' would just be a little much). ;)

And I make sure that my program is as efficient as I can make it without seriously spending time optimizing.


I find it better to create a working application as a draft; then spend the rest of the development time optimizing, fixing bugs, adding features, etc. That way you know that the goal is actually achievable, and you get to spend a greater amount of focus on optimization without having to worry about how to implement the next peice of the puzzle.

It seems this thread has turned into more of an argument of opinion. The problem with opinions is that nobody is ever right or wrong so the arugments simply continue on (sorta like "Lamb Chop's" Song that never ends). What started out as a bit of confusion has began to spiral out of control. I desist my arguments from here on out about this topic.

Regards,
Bryant Keller
Posted on 2006-06-30 20:02:24 by Synfire

It seems this thread has turned into more of an argument of opinion. The problem with opinions is that nobody is ever right or wrong so the arugments simply continue on (sorta like "Lamb Chop's" Song that never ends). What started out as a bit of confusion has began to spiral out of control. I desist my arguments from here on out about this topic.


Agreed. If the original question was answered, then please let this thread die peacefully. If it hasn't, please get back on subject.

Considering the content-value, any more open opinions (i.e. doesn't *factually* satisfy the original poster's inquiry) and I will have to move this thread to "The Crusades".
Posted on 2006-06-30 20:27:34 by SpooK