Re: Assembly code nowadays
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.
Re: Assembly code nowadays
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:
Code:
text1 db ,10,13,'text2$' ; (1)
text3 db 12 dup(?) ; (2)
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.
Re: Assembly code nowadays
Hand Crafted MSIL is not all that uncommon in .NET, and an understanding of it is necessary to truely be an effective professional developer.
Re: Assembly code nowadays
I don't think you can mix assembly with .NET languages, may be in unmanaged C++ but not in other languages.
Re: Assembly code nowadays
In (1), the 10 and the 13 are carriage return (0x0A) and line feed (0x0D) characters, respectively.
Mike
Re: Assembly code nowadays
Thanks guys for your input.
Quote:
Originally Posted by MikeAThon
In (1), the 10 and the 13 are carriage return (0x0A) and line feed (0x0D) characters, respectively.
Mike
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.
Re: Assembly code nowadays
Quote:
Originally Posted by danutz_plusplus
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.
It doesn't do anything, it's merely initialized data which may later be used in the code.
Quote:
text3 db 12 dup(?) ; (2)
As for this one, it reserves 12 empty bytes for an uninitialized string variable.
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:
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
I quote from the MSDN library:
Quote:
HMODULE GetModuleHandle(
LPCTSTR lpModuleName
);
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.
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
Re: Assembly code nowadays
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.
Re: Assembly code nowadays
Quote:
Originally Posted by danutz_plusplus
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.
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.
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:
Quote:
Sorry if it's a dumb question.
No such thing exists. :-)
Re: Assembly code nowadays
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?
Re: Assembly code nowadays
Quote:
Originally Posted by danutz_plusplus
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.
You hit the nail on the head as for it's main use professionally anyway.
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.
Quote:
Originally Posted by danutz_plusplus
It's because of the time it would take to develop a full fledged application, right?
Yes.
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:
Code:
Actual code:
mov edx, [edi]
mov [esi], edx
Had to be:
mov edx, [esi]
mov [edi], edx
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.
Unfortunately with ASM, that source code... is ASM.
Re: Assembly code nowadays
Quote:
Originally Posted by danutz_plusplus
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?
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.
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
Re: Assembly code nowadays
Quote:
Originally Posted by kahlinor
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?
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. ;)
Re: Assembly code nowadays
Quote:
Originally Posted by Lars(NL)
And Borland Turbo Assembler?
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.
Another good one for Win32/64 is GoAsm.
Re: Assembly code nowadays
Quote:
Originally Posted by Lars(NL)
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.
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.
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. :D
Re: Assembly code nowadays
Quote:
Originally Posted by JohnW@Wessex
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. :D
Forgive me for saying but that really is bs.
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.
Re: Assembly code nowadays
You're saying that type safety and high level constructs etc. can give the programmer no advantages over assembler when creating an application!!!
Quote:
Originally Posted by Lars(NL)
It is not C++, not C# and not VB where you can treat everything as a byte, word or dword.
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!
It's a shame to think that the last few decades of high level language developement have been such a waste of time!
Re: Assembly code nowadays
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.