Printable View
Hi all. I have a question, or maybe more of a personal wondering. How often is assembly code used nowadays. Is it still used with the .NET platform, more specifically with C++ or C#? It would be great if you guys could share your opinions or experiences on this. Thanks in advance.
Depends. Not many people choose Assembly over high level languages such as C++ or Delphi. Rather they mix it. Assembly where you need to do low levelled programming, and the rest in a high level language. Lets say you need to alter something in memory, you could do it in C++ (well... depending on what it was), but the coding would be extremely awkward and hard to maintain. While in Assembly, it would be normal and easy to maintain. But for Assembly you must be willing to code alot of details that really do nothing.
I personally like Assembly. But I mix it with C++/Delphi for when I need it.
Ok. Thanks. I know it is still used with standard C++, but I was actually wondering whether it is used with the .NET C++, or C#. If you were referring to both standard C++ and .NET C++, when you said that, then sorry for misunderstanding.
I also have another small question: in this code:
what do the 10 and 13 mean in (1), and what does the (2) line do? I thought about creating a new thread for this, but the question is too basic to start a new thread. Thanks.Code:text1 db ,10,13,'text2$' ; (1)
text3 db 12 dup(?) ; (2)
Hand Crafted MSIL is not all that uncommon in .NET, and an understanding of it is necessary to truely be an effective professional developer.
I don't think you can mix assembly with .NET languages, may be in unmanaged C++ but not in other languages.
In (1), the 10 and the 13 are carriage return (0x0A) and line feed (0x0D) characters, respectively.
Mike
Thanks guys for your input.
Yeah, ok. But does it add those characters to the end of the string or what? Or why are the 10 and 13 there? If they wouldn't be there what would be the outcome of line (1). Thanks.Quote:
Originally Posted by MikeAThon
It doesn't do anything, it's merely initialized data which may later be used in the code.Quote:
Originally Posted by danutz_plusplus
As for this one, it reserves 12 empty bytes for an uninitialized string variable.Quote:
text3 db 12 dup(?) ; (2)
And lastly, regarding your question about the use of ASM:
I still do use C++ every now and then lately, but very rarely, I program almost exclusively in ASM these days.
True that it's a 2nd generation language rather than all the common HL languages being 4th generation, but the assumption that it's more difficult is a huge mistake.
There are two main reasons that I prefer ASM over any high level language.
1) The lack of any form of "safe programming" conventions or any other conventions for that matter.
In ASM you can create just what you want and the assembler does nothing but do what is possible to realize wish in which it is limited only by the Intel Architecture.
ASM doesn't care if you use a pointer to directly access a buffer used internally in ntdll.dll if you know it's there or read data from your PEB.
Admitted there are workarounds to do such things in HL languages, but that is exactly my point: some things are more work to do in ASM because ASM does nothing for you, it's low level programming where you have to do everything you want done yourself.
But, it is also true that at least the time you spend working on a project in ASM equals the time you're actually working on the content of your project, contrarily to high level languages where in addition to realizing the main goals of your project you're also developing workarounds for the limitations of the language in question in order to get there a lot of the time.
2) The freedom in use of datatypes.
There are tons of datatypes in C++ which are in essence identical, yet distinguished between merely for the sake of preserving conventional programming.
The only reason you use the datatype HMODULE is not because it's the only way a project can compile, no it's because the C++ compiler was designed to refuse to compile any datatype other than HMODULE where one is expected.
In ASM my assembler doesn't care in the least bit if I call it an HMODULE or something else, all it does is look at what it really is: a DWORD and assemble it as such.
The name of the datatype in C++ is simply going out the window.
An example:
I quote from the MSDN library:Code:.386
.model flat,stdcall
include windows.inc
include kernel32.inc
includelib kernel32.lib
.data
szKernel db "kernel32.dll",0
.code
SAMPLE:
WinMain Proc hInstance:DWORD, hPrevInstance:DWORD, lpCmdLine:DWORD, nCmdShow:DWORD
LOCAL szpKernel:LPTHREAD_START_ROUTINE
lea edx, szKernel
; Note: I could simply call GetModuleHandle straight away with EDX as the parameter
; but that would negate the whole point of this example.
mov szpKernel, edx
push szpKernel
call GetModuleHandle
ret
WinMain EndP
End SAMPLE
My point: the ASM assembler will assemble this happily, when it encounters LPTHREAD_START_ROUTINE it takes that label, which is really all it is, drops it in the toilet and flushes it, then continues to assemble the project.Quote:
HMODULE GetModuleHandle(
LPCTSTR lpModuleName
);
This does not give any error or even warning and it does not malfunction.
It's a bit weird, yeah, but using LPTHREAD_START_ROUTINE instead of LPCTSTR works perfectly fine.
The reason is simple, what is LPTHREAD_START_ROUTINE?
It's a DWORD; a 32-bit pointer to the offset in memory of a procedure at which a thread is to begin execution.
And LPCTSTR?
A DWORD; a 32-bit pointer to the offset of a, in this case ANSI, string specifying the name of the module of which we wish to retrieve the handle.
They are, in essence, identical.
Those are but two of the many, many reasons I will stick to assembler programming; there is truly nothing that can be done in a high level language that can't be done in ASM because let's not forget no matter if you compile your source to ASM as normal or you write managed code that compiles to MSIL and is assembled into ASM at run-time by the .NET Framework's JIT (.NET Framework's JIT? ...if I am not mistaken) in the end it's always ASM when executed because your CPU can't cope with MSIL or anything else similar.
Regards,
Lars
- A true assembler fan. :-P
But don't you have to write a lot more code in asm then what you would have to write in a highlevel language? I'm just curious: can you create a UI in asm? Sorry if it's a dumb question.
Anyway, I don't know why, but I don't like asm programming very much. I feel like I don't have a solid base of tools to work with. I have to create/simulate everything.
Depends on the situation, sometimes you have have to write a whole section of code for something that C++ can do for you automatically, other times you save lots of coding by just programming exactly what you want in a straightforward way in a situation where C++ would simply refuse to compile it at all or it would compile, but only after adding a page full of variable casting or whatever.Quote:
Originally Posted by danutz_plusplus
And yes, you can most definitely create a UI in ASM.
Window styles in all their possible appearances, 3D styles, drop shadows; hell, you could even brush up your 3D dynamic window structure with Pixel Shader 3.0 if you want to involve the DirectX APIs, and more importantly: if you're bored enough to do so. ;-)
Remember that your CPU has an instruction set it uses.
A limited collection of instructions built into your CPU are the only resources it has in order to perform any requested operations with; this is ASM.
C++ is used to design your application and then have a compiler built the code for you, the ASM code to be precise.
Only ASM can be executed, meaning that anything you can do in any language whatsoever (at least regarding Win32 programming) can also be done in ASM in theory.
The only limitations (if you want to write your code in mnemonics (eg. RET) instead of opcodes (eg. C3)) are defined by what your assembler, such as MASM or TASM, supports but in all honestly... I have yet to find a limitation in MASM that limits to the extend where anything at all becomes impossible what would be possible in any higher level Win32 programming language.
Like I said I still use C++ sometimes, but just for the fun of it really because I just like that too somehow.
When it comes to it, I would pick ASM any day.
Edit:
No such thing exists. :-)Quote:
Sorry if it's a dumb question.
Ok. I get it. You can do anything in asm that you could do in a hl language because in the end they're practically the same. But then why is asm avoided, and it's only used in some parts, where speed and efficiency is of the essence. It's because of the time it would take to develop a full fledged application, right?
You hit the nail on the head as for it's main use professionally anyway.Quote:
Originally Posted by danutz_plusplus
When it comes to large, professional projects ASM still is used in some cases but only in smaller important sections of code where it is of vital importance that the code is as efficient as possible.
This is logical, since ASM gives the programmer rather than the compiler control over the precise result.
Yes.Quote:
Originally Posted by danutz_plusplus
I can go and argue this just because I'm pro-ASM, but there would be no use because I know it's true. :-P
If you're dealing with large projects ASM is still sometimes used as mentioned as described above - although even that rarely - but writing such a project completely in ASM would raise some really big question marks as to if the potential increase in speed and efficiency is worth the enormous amount of extra time.
When a project is a very large one the code would be immense and despite the fact that with proper commenting and all it may still be rather understandable as long as it works it's a killer when it comes to one of ASM's biggest downsides: debugging.
To illustrate, last week I had an error in one of my projects which took me almost a full day to trace, the problem was this:
Now, many 4th generation languages which have debuggers capable of pointing out the error (with or without a debug-mode test run) in your high level source code.Code:Actual code:
mov edx, [edi]
mov [esi], edx
Had to be:
mov edx, [esi]
mov [edi], edx
Unfortunately with ASM, that source code... is ASM.
The only reason for this is due to the lack of commercial support for assembler. Assembly tends to be less portable (though an assembler such as gas is able to transcend across different processors) than the average HLL.Quote:
Originally Posted by danutz_plusplus
However, some modern high level and macro assemblers and assembly IDE projects have narrowed the gap, making development in assembly about as fast as development with HLL.
Some assemblers to consider:
MASM - Win32 only
FASM - portable Win32-64, 'nix32-64 and several others
NASM - portable Win32-64, 'nix32-64, and several others
HLA - portable Win32, 'nix32 (more to come)
ROSASM - Win32 only
And Borland Turbo Assembler?Quote:
Originally Posted by kahlinor
I don't know if TASM is a good choice really, but I know it's there and I'm generally not unhappy with their products.
My experience with their products is limited to Delphi 7 Enterprise and JBuilder 2005 Enterprise though.
Perhaps you know if TASM is any good?
I personally favor MASM and errr... I just hate HLA.
Though, that's ungrounded.
I'm just biased in that regard, I never used HLA actually but I do despise it. ;)
I tried several assemblers but settled on HLA myself. As for TASM, It's a fine assembler, but I wouldn't recommend it since it is discontinued by the developer. I see no future in it.Quote:
Originally Posted by Lars(NL)
Another good one for Win32/64 is GoAsm.
Interestingly it's for the same reasons that I was glad to start using a high level language after several years of writing in assembler. :DQuote:
Originally Posted by Lars(NL)
Forgive me for saying but that really is bs.Quote:
Originally Posted by JohnW@Wessex
There is no way you could swap those two reasons over, stating that they are precisely the advantages of a HL language over assembler.
It is not C++, not C# and not VB where you can treat everything as a byte, word or dword.
You're saying that type safety and high level constructs etc. can give the programmer no advantages over assembler when creating an application!!!
Exactly! I don't want to have to treat everything as a byte, word or dword, and I'm glad I don't have to anymore!Quote:
Originally Posted by Lars(NL)
It's a shame to think that the last few decades of high level language developement have been such a waste of time!
One of the attractions of HLA is that it allows for flexible data representation: types, records and classes. MASM also has built in support for structures.