I love Assembly. I actually started out in Assembly Language programs (long before I even knew about C++, VB, Delphi, Java, and other higher level languages) several years back on the IBM mainframe computers. Back then when you wrote an Assembly language program you really [/i] wrote programs at the assembly (machine-code is what we called it) level. If you were to examine an Assembly language source listing you saw about 95% pure machine-code instructions and about 5% of the other stuff (directives, a few macros, etc).
We didnt have 'debuggers' in the strict sense so when our programs crashed we has no choise but to look at hundreds of pages of core-dumps that the computer spilled out and try to resolve the problem(s) from there.
Today, I am no longer doing IBM mainframe Assembly programs because they are gone.
When I saw my first Assembly language source program for Win32 Assembly I was quite astounded. "Where in the hell are the machine-code instructions?" I asked myself. It seems to me as we get further and further into state-of-the-art technologies the programs are getting less and less looking like assembly language programs. Except for a couple of front-end stuff at the top of the source listing everything else in the assembly source had absolutely no resemblense to an assembly language program. As a matter of fact, I thought I was looking at some new breed of C/C++ or Visual Basic program. I almost decided not to get into Win32 Assembly because it appeared to me that this is just more Windows programming in the C/C++ style.
Oh, well, I going to do it anyway.
If you like a lower level assembler you might try GoAsm, it has a few high level functions regarding strings and a very rudimentary macro language but none of the IF/ELSEIF/ENDIF or REPEAT/UNTIL stuff, you actually have to code them with instructions. Take a look, it is close enough to MASM that you are not losing any of what you've learned but it is not for the faint of heart, it is real assemlby, none of the toys you find in most others.
Quote from: donkey on December 23, 2004, 01:03:33 AM
If you like a lower level assembler you might try GoAsm, it has a few high level functions regarding strings and a very rudimentary macro language but none of the IF/ELSEIF/ENDIF or REPEAT/UNTIL stuff, you actually have to code them with instructions. Take a look, it is close enough to MASM that you are not losing any of what you've learned but it is not for the faint of heart, it is real assemlby, none of the toys you find in most others.
On my own I would probably go in that direction just because of my 'love' for the real low-level coding but as it is I don't have the time to venture into that type of maticulus coding and the assembly that I am getting into is at the company's request and they decide what level I code at. Actually, I really do like the new high-level assembly coding. I was just making a comparison to now and then. I didn't like C and C++ when I first got into it but it grew on me and now I do like programming in it. I think when I made the transition from low-level to high-level it was just kind of dissapointing at first because I seem to have lost my inner friendship with the CPU and all those other neat things you get into down below.
Robert,
There is a predictable sequence for code style over time. People learning use the higher level stuff because its easier to start with. Over time they learn how to do it all the hard way and once they have learnt that they go back to using the higher level stuff because you code faster in it.
Where it is important to know the difference is when you have to code algorithms that must be fast. bare mnemonics have advantages here when they are coded right.
Even if you choose to use MASM, you aren't forced to use all the macros. You can make all the things you need yourself, if that's what you want.
Yea, I certainly don't use any of C like support in MASM.
Quote from: Mark_Larson on December 23, 2004, 03:09:38 AM
Yea, I certainly don't use any of C like support in MASM.
Using high level syntax in ASM completely defeats the purpose of doing things in asm.
I was just wondering about something. If you write a program in assembly and it is a Windows type program you wind up making the same API calls and then sprinkle here and there some assembly instructions. Then you build and link your .asm using MASM. Why would you not consider using MS VC, create a C project, make the same API calls to get your windows functions and then drop down to the asm level (which is supported in the VC IDE) and sprinkle your assembly code here and there instead of C code. Wouldn't that, in essense, be basically the same thing?
In essense, yes, it would be the same thing. Only for many of us it's more fun to do it in assembler. Some of us are interested in doing everything low-level; others are more interested in writing C and optimizing the bottlenecks as much as possible.
BTW, in your original post, which assembler's code were you looking at? When I first read it, I kind of figured you might be looking at HLA code, which is significantly different than all the other assemblers I can think of. Even when MASM code gets very high-level, you usually cannot mistake it for anything but assembler. HLA, on the other hand, can easily be mistaken for a high-level language like C or Pascal.
Quote from: Robert Collins on December 23, 2004, 03:56:42 AM
I was just wondering about something. If you write a program in assembly and it is a Windows type program you wind up making the same API calls and then sprinkle here and there some assembly instructions. Then you build and link your .asm using MASM. Why would you not consider using MS VC, create a C project, make the same API calls to get your windows functions and then drop down to the asm level (which is supported in the VC IDE) and sprinkle your assembly code here and there instead of C code. Wouldn't that, in essense, be basically the same thing?
I think the best bet is to do all your coding in a high level language and then do critical code in ASM.
Quote from: Maven on December 23, 2004, 04:23:12 AM
Quote from: Robert Collins on December 23, 2004, 03:56:42 AM
I was just wondering about something. If you write a program in assembly and it is a Windows type program you wind up making the same API calls and then sprinkle here and there some assembly instructions. Then you build and link your .asm using MASM. Why would you not consider using MS VC, create a C project, make the same API calls to get your windows functions and then drop down to the asm level (which is supported in the VC IDE) and sprinkle your assembly code here and there instead of C code. Wouldn't that, in essense, be basically the same thing?
I think the best bet is to do all your coding in a high level language and then do critical code in ASM.
I think it all depends on the individual. I used to do assembly for the 'fun' of it (and I still do up to a point). Then I did assembly right down to the barest of bones programming, not because it was efficent but because that is what I liked doing. I even got so interested in computers and what makes them tick I even did some mirco coding (firmware) and man, you just don't get any lower than at the micro level. But now, I program for a living and I am bound by the policies of the company as to what I can and can't do. Because I have to do what my boss says I am not always happy with what I have to write a program for. I am not always happy about which language or level of programming I have to use. Even given the choise of language I probably would not pick assembly to do my job because the high-level languages are so much more efficent and faster to develop in. I like to get the project done and get on with the next assignment.
I am now getting into Win32 Assembly programming not because I think it is the best language for me to program in but because 1) I like it, 2) it's fun, 3) it gets me back to 'bond' I used to have with the computer in the good o'days.
Also you can try nasm/yasm/fasm :)
QuoteUsing high level syntax in ASM completely defeats the purpose of doing things in asm.
I agree in the sintaxis, but not agree in the technique :).
High level lenguage is diferent than structured programming or object oriented programming, the 2 laters are techniques. High level lengauge mean mainly to abstract the machine opcodes and internal representation of the machine.
I agree because the sintaxis used for the structures of structured programming have a sintaxis like c/pascal, where I think they can be implemented for asm dont requiring to use a similar to such languages, but some that reflect more the mnemonics used.
Some one of you say: write in C and the dificult speed parts in asm, why not use an asm with a great suport for SS and OO, that provide a strong suport for them (yes including optimizers for this parts) and write the speed parts without the use of this techniques/tools provided with the assembler? there no exist such assembler :).
Quote from: MANT on December 23, 2004, 04:15:10 AM
In essense, yes, it would be the same thing. Only for many of us it's more fun to do it in assembler. Some of us are interested in doing everything low-level; others are more interested in writing C and optimizing the bottlenecks as much as possible.
BTW, in your original post, which assembler's code were you looking at? When I first read it, I kind of figured you might be looking at HLA code, which is significantly different than all the other assemblers I can think of. Even when MASM code gets very high-level, you usually cannot mistake it for anything but assembler. HLA, on the other hand, can easily be mistaken for a high-level language like C or Pascal.
I really don't recall which one it was since I was looking at so many. Also, I was mainly just briefly scanning over them to see what I could see without trying to figure anything out. Below is an example of one that fits into that category. It isn't that it doesn't contain any assembly instructions but the overall appearance of it kind of made me think I was looking at a new way to write 'C' style Windows programs.
386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include mhook.inc
includelib mhook.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
wsprintfA proto C :DWORD,:DWORD,:VARARG
wsprintf TEXTEQU <wsprintfA>
.const
IDD_MAINDLG equ 101
IDC_CLASSNAME equ 1000
IDC_HANDLE equ 1001
IDC_WNDPROC equ 1002
IDC_HOOK equ 1004
IDC_EXIT equ 1005
WM_MOUSEHOOK equ WM_USER+6
DlgFunc PROTO :DWORD,:DWORD,:DWORD,:DWORD
.data
HookFlag dd FALSE
HookText db "&Hook",0
UnhookText db "&Unhook",0
template db "%lx",0
.data?
hInstance dd ?
hHook dd ?
.code
start:
invoke GetModuleHandle,NULL
mov hInstance,eax
invoke DialogBoxParam,hInstance,IDD_MAINDLG,NULL,addr DlgFunc,NULL
invoke ExitProcess,NULL
DlgFunc proc hDlg:DWORD,uMsg:DWORD,wParam:DWORD,lParam:DWORD
LOCAL hLib:DWORD
LOCAL buffer[128]:byte
LOCAL buffer1[128]:byte
LOCAL rect:RECT
.if uMsg==WM_CLOSE
.if HookFlag==TRUE
invoke UninstallHook
.endif
invoke EndDialog,hDlg,NULL
.elseif uMsg==WM_INITDIALOG
invoke GetWindowRect,hDlg,addr rect
invoke SetWindowPos,hDlg,HWND_TOPMOST,rect.left,rect.top,rect.right,rect.bottom,SWP_SHOWWINDOW
.elseif uMsg==WM_MOUSEHOOK
invoke GetDlgItemText,hDlg,IDC_HANDLE,addr buffer1,128
invoke wsprintf,addr buffer,addr template,wParam
invoke lstrcmpi,addr buffer,addr buffer1
.if eax!=0
invoke SetDlgItemText,hDlg,IDC_HANDLE,addr buffer
.endif
invoke GetDlgItemText,hDlg,IDC_CLASSNAME,addr buffer1,128
invoke GetClassName,wParam,addr buffer,128
invoke lstrcmpi,addr buffer,addr buffer1
.if eax!=0
invoke SetDlgItemText,hDlg,IDC_CLASSNAME,addr buffer
.endif
invoke GetDlgItemText,hDlg,IDC_WNDPROC,addr buffer1,128
invoke GetClassLong,wParam,GCL_WNDPROC
invoke wsprintf,addr buffer,addr template,eax
invoke lstrcmpi,addr buffer,addr buffer1
.if eax!=0
invoke SetDlgItemText,hDlg,IDC_WNDPROC,addr buffer
.endif
.elseif uMsg==WM_COMMAND
.if lParam!=0
mov eax,wParam
mov edx,eax
shr edx,16
.if dx==BN_CLICKED
.if ax==IDC_EXIT
invoke SendMessage,hDlg,WM_CLOSE,0,0
.else
.if HookFlag==FALSE
invoke InstallHook,hDlg
.if eax!=NULL
mov HookFlag,TRUE
invoke SetDlgItemText,hDlg,IDC_HOOK,addr UnhookText
.endif
.else
invoke UninstallHook
invoke SetDlgItemText,hDlg,IDC_HOOK,addr HookText
mov HookFlag,FALSE
invoke SetDlgItemText,hDlg,IDC_CLASSNAME,NULL
invoke SetDlgItemText,hDlg,IDC_HANDLE,NULL
invoke SetDlgItemText,hDlg,IDC_WNDPROC,NULL
.endif
.endif
.endif
.endif
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
DlgFunc endp
end start
There is no language as elegant in it's simplicity as assembly. With only a few instructions you can build a working peice of code. Granted that many take the route of using it as C with a MOV instruction but that is nothing more than a personal choice. For others everything is a puzzle to be solved in the most optimal way. It is very difficult for a beginner or intermediate assembly language programmer to outpace a good optimizing C compiler, but that is not the only point of writing in assembler, it is also the understanding and control that it offers. Once you begin programming in assembly you will begin to truly understand how the x86 and Windows really work and also why in some cases they don't. I remember that I once posted a reply to a C++ board mentioning that the return value was in EAX, a few of the programmers there knew what EAX was, most had no idea. High level languages by nature must obscure the machine and provide a degree of separation, but though this may be fine for most people, there are a few that keep asking "why" and they inevitably end up finding the answers in assembly. Here you will find people like MANT, Raymond, Mark and Bogdan that will help to explain the answer and maybe even point out some new questions you never thought of. I came to assembler without any high level language and it is still the only language I use, HLL's tend to confuse and frustrate me as they keep imposing rules on my code, with assembler I am free to write what I want the way I want without artificial constraints placed on me by the compiler.
Quote from: donkey on December 23, 2004, 06:04:14 AM
There is no language as elegant in it's simplicity as assembly. With only a few instructions you can build a working peice of code. Granted that many take the route of using it as C with a MOV instruction but that is nothing more than a personal choice. For others everything is a puzzle to be solved in the most optimal way. It is very difficult for a beginner or intermediate assembly language programmer to outpace a good optimizing C compiler, but that is not the only point of writing in assembler, it is also the understanding and control that it offers. Once you begin programming in assembly you will begin to truly understand how the x86 and Windows really work and also why in some cases they don't. I remember that I once posted a reply to a C++ board mentioning that the return value was in EAX, a few of the programmers there knew what EAX was, most had no idea. High level languages by nature must obscure the machine and provide a degree of separation, but though this may be fine for most people, there are a few that keep asking "why" and they inevitably end up finding the answers in assembly. Here you will find people like MANT, Raymond, Mark and Bogdan that will help to explain the answer and maybe even point out some new questions you never thought of. I came to assembler without any high level language and it is still the only language I use, HLL's tend to confuse and frustrate me as they keep imposing rules on my code, with assembler I am free to write what I want the way I want without artificial constraints placed on me by the compiler.
I absolutely agree. And that is why I Love Assembly. The unfortunate thing is when you work for the man you are not always at the liberty of '...being free to write what you want and the way you want...'. In my world of programming I not only have to worry about me later understanding what I did but more importantly is that I must make sure that others who follow after me will be able to understand what I did so that is why companies impose such standards that one must follow. It doesn't matter what language I use the company has their programming policies and that is that. I as an employee cannot just venture out on my own and create any program I want to or the way I want to. There is nothing I dislike more than to have to go get a program written by some other employee who didn't follow the standards of the programming department and wrote a total disaster program. We call it 'spaghetti code'. I think companies think that there is 'too much room for errors and esoteric programming' in assembly. High Level compiliers force you to use certain standard and conventions while assembly has alot of slack and that is what makes it an undesirable language in the eyes of the company. Personnaly, if I had my way I would do everything in Assembly but I also see the other side of the coin.
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 ;).
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.
Assembly is better and more clear than C.
If you know MASM,then C is unnecessary.
Manos.
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 (http://www.masmforum.com/simple/index.php?topic=103.0), 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.
Writting assembly code with comments the problem solved.
In C,you can write so many complex code that this become unreadable.
Manos.
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"
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.
Quote
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
To Robert Collins:
You are not this guy, are you? Ratch
http://www.ddj.com/documents/s=961/ddj9605n/9605n.htm
Quote from: Mark_Larson on December 23, 2004, 02:39:07 PM
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
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?
Quote from: MANT on December 23, 2004, 05:07:10 PM
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).
Quote from: MANT on December 23, 2004, 05:07:10 PM
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.
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.
Quote from: Maven on December 23, 2004, 08:27:47 PM
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.
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?
Hi Statix:
I'm not sure what point you're making in your latest post, but there are a lot of good reasons to use C (I mean ANSI C, not C++), and not very many reasons to use HLA (though I'm sure Randy would beg to differ). One of the main reasons C is so useful is that there's so damn much code out there already. If you want to write a program that figures out when sunrise & sunset on Mars will be, chances are someone's written code that will help you, and the odds are decent that it's in C. If not that, it'll be either C++ or Java, both of which translate fairly easily to C. There are tons of tools for C, including editors that recognize C syntax, and tools that can help you organize and analyze your code. Plus, C is such a well-known language, compilers are quite good at optimizing it.
IMHO, for "professional" programming (stuff you do that's on any kind of a deadline, or that you might sell), your best bet is to use C or C++. Let it optimize all your code the best it can, and then run a profiler on it to see where the bottlenecks are. Optimize the biggest bottleneck, but try to do it in your HLL. Often, the best optimizations come at the higher, conceptual level. Finally, if nothing helps, rewrite the function in assembly. Use any assembler you want, though most compilers support inline assembly. For small stuff, inline is perfectly fine. Redo one function at a time, then re-profile and see how it affects things.
As I said, for professional programming, I think that's about the only sane way to do it. You can probably substitute other HLL's instead of C or C++, but the idea is to stay away from assembler as much as you can. For personal programming, assembly is a lot of fun, and I've enjoyed writing several programs in 100% assembler. For me, using HLA defeats the purpose of using assembly in the first place: when I'm doing assembly, I don't want to do high-level coding! :) For personal programming, it's all a matter of taste, and there really is no wrong opinion -- whatever you enjoy, you enjoy. For professional programming, I have a very hard time imagining being able to justify using HLA.
BTW, the syntax you described is only for C++. The C version would be printf("Hello World!\n");.
I agree with MANT here. I have much less time to dedicate to programming than I used to and find myself a bit frustrated at times that I have to manually code every last little detail in assembler. Every time I need to do even the simplest thing it requires that I do the research, code the function, test it, build it into yet another lib then finally I can move onto the next line of the program. I now have a collection of about 400 library functions, many of which I have uploaded to my website. But the more I add them the less I am coding in assembler and the more in some lib driven behemoth of my own making. This is how I also see HLA, as a set of extensions for assembler that at some point got out of control and now bares little in common with assembly language. That is ofcourse a personal opinion, I am a great fan of the low level stuff and even find MASM a bit high level for my liking. I find the elegance and simplicity of low level assembly is what attracts me to it the most, by obscuring this to make it more high level seems to take away it's greatest advantage for me.
But I am not a professional programmer so if it takes me 2 months to finish what someone might do in a weekend in C, well that's OK and you can bet that I will come out understanding it alot more. Professional programmers however are under a deadline, either real or imposed by economics. Every day that a programmer takes to write a program is another day that he must be paid and the product is not ready to generate revenue and that is where his pay is coming from. As with Mark, there are exceptions to every rule but in the vast scheme of things, C is the better choice from a professional standpoint.
As with any language, the more you have available, the faster you get at producing it. I am a library man in that I HATE writing the same code over and over again. Start off with a bare assembler and you work for a long time to get anything up but have years of libraries and other code available and it gets LOTS faster. For fast coding languages, I find it hard to go past the PB I use for so many things, my C is off the pace as I write MASM instead but it is usually the case that you crank out code faster in a high level language.
Where you close the gap with assembler is in having as much of the same facilities as a high level language, enough libraries, API calls and the like and you are not giving away much in development speed terms.
I agree with the C stuff. As a matter of fact, if I were able to build up a compiler for the High-Level Language, I would use instead
of the print, stdout.put. The marketing is what annoys me, is it easy to be contract it by Intel or M$?