I love Assembly but.......

[rea]

But Im sure that you write structured programming (in the concept of flow, selection of flow and repetition), dosent matter that you dont use the macros .if and the others, also be the thing that I say, you see that a struct of control is a technique, the typecasting and other things aplied inside of the evaluation of a expression depend on the lenguage that you are using.

Then I will stay continuing saying this: not mix or think that structured programming or OO depend on the language tha you are using, they are techniques (a friend called OO a mind state), first point, structured programming and OO bornd at diferent days than High levels langauges (one not depend on the other), if they depend, say me for what the structured programming can be replicated in diferents languages, dosent matter what langauge is (even in asm using only mnemonics and labels), even you can replicate a little OO in pure C, even you can replicate OO in asm, this techniques dont depend on the langauge, they can be inserted like a logic way to organization.

Robert collings:

Yes that look like hll, the point is that what is replicated here is the structured programming it look like hll but is not, because it not abstract you from the machine only hide some things for the sintaxis used, there are pherahs other way, where can be showed more mnemonics some like: eax ae 5 instead of if eax >= 5... anyway...., the thing that when they where replicated make a choice to use names like in C is another mather. And like I say before, this techniques can be replicated, the instrinsics of the evaluation of the expression depend on the language choised.

The structures provided in this case via macros, only provide you a more fast to type, insterad of make push eax, push ebx, push dword[eax] and in reverse order like is required by the calling convention :).



By the way, say me how dificult where in those times to find:

A uncorrect condition jump.
A uncorrect size movement. (moving a word when you should move a byte?)
Remember how many arguments have a function.
How dificult where to find in the list file the error.
The start of a function.
The end of the same function.
You have readed others people code?, they have passed you the source code or the list file?

Pheraphs later I will come with others question, for myself answer to them should be constructive ;).

[hutch--]

I basically disagree with the general drift of this conversation in that MASM easily handles many of the high level constructs without needing a high level language to do it for you. The type of distinction being argued here is that you only code mnemonics in assembler and do the rest in a HLL but while that is viable enough if you start from a HLL, you miss out on the architecture control from designing in assembler.

Assemblers prior to about 1990 were just mnemonic munchers with a minimal notation for laying out segement definitions and the like but with the advent of MACRO assemblers for the x86 market you ended up with considerably more capacity which still translated diectly to mnemonic coding. The resurection of assembler in the late 90s was not a follow on from the old mnemonic capacity but from all of the extra stuff they could do that made the code a lot faster and easier to write, debug and maintain.

With libaries, macros, pseudo HLL capacity and the like, you can do a lot of higher level style code as fast as anything else so where the capacity fits, it is a good tool for the job where often a compiler is too big, restricted and clunky to do the job well. The big difference between the bad old days and now is the massive API function set which made high level coding easy in assembler. Matching the API functions is structures, unions and automated "invoke" syntax with rudimentary type checking and the like.

[Manos]

Assembly is better and more clear than C.
If you know MASM,then C is unnecessary.

Manos.

[MANT]

Quite frankly I find the quality of my assembly code is usually better than my C code. I tend to reduce, reduce, reduce (a.k.a. factoring) in assembly, boiling my programs down to small procedures that each perform a well-defined task. In C, I often tend to just write code, blathering on until I notice: gee, I just wrote 200 lines of code! I get much more enjoyment out of writing in assembler, and I think that's the essence of those who inhabit this forum: we simply love assembly coding.

There is one case I'll make against assembly, and that's something Robert mentioned earlier: readability. Most code is okay, but code involving floating point calculations can get pretty hairy in assembler, and I find the code much harder to read six months later than equivalent C code. Code involving system functions, on the other hand, like the code in this thread, I find are actually more readable in assembler, and I find them easier to write. Actually, for me, attacking a complex technical problem involving the Win32 API is almost always easier to solve by thinking about it in terms of assembly code.

[Manos]

Writting assembly code with comments the problem solved.
In C,you can write so many complex code that this become unreadable.

Manos.

[algernon]

One can write incredibly obfuscated code in any language, I guess it depends on experience, style, patience etc.
In my opinion, C is ok as a language, we just have many compilers which implements it differently. I remember doing a little experiment, I wrote a simple C start lib in asm with a printf and support for argv and argc. The result: a "hello world" program a few kb in size (4 or 5 I remember)
About writing code for bucks, well, you mostly do what and how the boss says :)) About 3 years ago I had a project which I did with Delphi except for a couple of file-scanning routines which I wrote in asm. My boss saw me and he told me that the client had a P4 with 1gig of RAM and very likely he won't give a damn about my good intentions :)) so now i'm working as a computer technician and only write small utilities for me and my friends and i'm very happy with that :)
I guess it all boils down to "the right tool for the right job"

[Mark_Larson]

  I am a BIOS programmer so I program in assembly for a living.  So I don't have any problem convincing my boss to let me do things in assembler ;) ;) ;) heheee.  I wanted to comment on two things.  First we would get into a lot of trouble if we wrote "spaghetti code".  That's a big no-no in our group.  We have a style guide we have to follow.  We have a code review that checks for the things in the style guide, proper commenting, and bugs.  So if you write poorly commented code, or break style guide conventions you'll end up back in your cube fixing it.  So the code review doesn't just check for bugs.  They also look at your commenting and style.  We also have two levels of design we have to go through before we even write a line of code.  We do a High Level Design document, which also goes before a review board.  And we do a Low Level Design document, which also goes through a review board.  For the commenting, we have a standard template that goes at the top of every procedure that has to be filled out.  Some things that are part of that template are:  function name, what it does, input parameters, output parameters, registers trashed, registers used, etc.  If you don't do a good job of filling out it, the code review will ding you on it, and you will have to go fix it.

I think companies think that there is 'too much room for errors and esoteric programming' in assembly.

  As for errors.  I produce very few bugs in both C and assembler ( yes I do C programming).  I don't produce any more errors in assembler than in C.  It's about the same.  That's because I program in assembler for my job, so my skill level in assembler is very high.  I described above some processes we follow when using assembler that help handle the "esoteric" part of your comment.  Assembler done properly can be just like a high level language in it's easieness to maintain.


  And pardon me if I didn't make sense at any point.  I just rolled out of bed, and I haven't even had my first coke yet.  Does that make me a geek for checking this board first thing when I get out of bed? ;) heheee

[Ratch]

To Robert Collins:

You are not this guy, are you?  Ratch

http://www.ddj.com/documents/s=961/ddj9605n/9605n.htm

[MANT]

Does that make me a geek for checking this board first thing when I get out of bed? ;) heheee

Um, yes. Welcome to the club! ;) :U

[MANT]

Hey Mark, I have a question for you. I was reading your post about your comment template for procedures, and I was wondering, do you usually pass arguments via registers? I remember doing BIOS calls way back when I wore furs and hunted wooly mammoths, and I recall them using registers as arguments, which to my mind would require a lot of careful documentation. If you were managing an assembly project outside the scope of BIOS, where you can use the stack to pass arguments, do you think you'd relax some of the comment header requirements? Do you maintain that level of commenting for your personal code?

[Robert Collins]

Hey Mark, I have a question for you. I was reading your post about your comment template for procedures, and I was wondering, do you usually pass arguments via registers? I remember doing BIOS calls way back when I wore furs and hunted wooly mammoths, and I recall them using registers as arguments, which to my mind would require a lot of careful documentation. If you were managing an assembly project outside the scope of BIOS, where you can use the stack to pass arguments, do you think you'd relax some of the comment header requirements? Do you maintain that level of commenting for your personal code?

Even though your post was directed to Mark, I would like to say that where I work passing arguments via registers is strictly forbidden in C/C++. I am not sure what their policies are regarding this in assembly since assembly is fairly new at this company and it is possible that the management hasn't yet adopted any standards yet but if and when they do I am sure it will also be prohibited. I looked at source codes written many years ago when policies didn't dictate the strict standards that they do today and there are just hundreds of programs riddled with register usages in parameter passing and register usages as function pointers. Somewhere back in time the company had a big problem with these type of programs crashing all the time and they were very difficult to debug so I think they just got fed up this type of coding and laid down the law about using registers. There are a few exceptions but you better have a very good reason why you want to use registers or you are going to be put down. Even though I am doing some assembly coding they were very reluctant in the first place to even allow it. I think some of the Systems Programmers use Assembly but not the Applications programmers (I'm the only exception for now).

[Mark_Larson]

Hey Mark, I have a question for you. I was reading your post about your comment template for procedures, and I was wondering, do you usually pass arguments via registers? I remember doing BIOS calls way back when I wore furs and hunted wooly mammoths, and I recall them using registers as arguments, which to my mind would require a lot of careful documentation. If you were managing an assembly project outside the scope of BIOS, where you can use the stack to pass arguments, do you think you'd relax some of the comment header requirements? Do you maintain that level of commenting for your personal code?

Most of the BIOS uses registers to pass arguments for the routines that use them.  There are a few places that use the stack.  Most people use very obvious conventions for parameter passing.  Most routines take at most one parameter that is usually passed in EAX ( read cmos, read PCI configuration space, etc).  The majority of our procedures don't require passing parameters ( the memory init code, the memory testing code, the pci init code, etc).  So their are only a handful of routines that require passing a parameter.  Most people can remember them, and if not they can check the template for the procedure ( which is why it is there).  I write templates for my personal code.  I find if I go back to the code months from now, it helps refresh my mind exactly how it works.  Along with the comments in the routine.  Also well written comments can suggest changes you can make to your code to make it better ( such as optimizations or different algorithms).  The exception to that is if I am optimizing a routine, I do very poor commenting, because I am concentrating on getting it working fast.

[Maven]

I would advise any of you to gard against being so conservative in your choices of languages. Everyone has a language they like more then others but you should avoid "only" using that language. I think languages solve different problems and as a programmer, you should pick the best tool for the job.

In a nutshell, I think it's wise to look at a problem and pick out a language that creates the best solution.

[Mark_Larson]

I would advise any of you to gard against being so conservative in your choices of languages. Everyone has a language they like more then others but you should avoid "only" using that language. I think languages solve different problems and as a programmer, you should pick the best tool for the job.

In a nutshell, I think it's wise to look at a problem and pick out a language that creates the best solution.

  That's actually a good point.  I don't always program in assembler.  I write various tools in C, because I can whip them out faster, and I don't care how fast they are.  The main reason the BIOS is in assembler is size ( and not speed as probably most people think).  If we wrote the code in C we would have to use a bigger flash chip which would cost more money.  When you are shipping millions and millions of desktop systems and you have to pay 10 cents or more per board based on a bigger flash chip, that really adds up.

[Statix Star]

If you check High-Level Assembly by Randall Hyde;

Instead of,

#include<iostream>

cout>> "Hello World!"

ret

Well, I don't really remember when I coded in C that was like 3 months, but with HLA

program Hello_World;

#include( " stdlib.hhf" );

stdout.put( "Hello World!" );

end Hello_World;

You could optimize but I don't know how? Only Vortex could put it on. This syntax beats the C/C++ syntaxis. The bad thing is that
HLA is still in development, you could use the Visual C Preproccesor to optimize your codes, or use Masm32 instead. So it will be the
same in building your program in IDE optimize for assembly, without the need of the C/C++. If your boss accepts it. Am I right?