| | |
Higher language Vs. Assembly language.
![]() |
•
•
Join Date: Aug 2008
Posts: 42
Reputation:
Solved Threads: 4
Assembly language programming is sometimes advantage because it's written keeping the processor in mind.. that is the limitations of processor are taken care and thus the code turns out optimized one.. also writing the code in assembly removes the necessity of cross compilation (carried out for many processors) and thus execution times are faster...
hope this helps a bit..
hope this helps a bit..
•
•
Join Date: Nov 2006
Posts: 134
Reputation:
Solved Threads: 3
•
•
•
•
Assembly language programming is sometimes advantage because it's written keeping the processor in mind.. that is the limitations of processor are taken care and thus the code turns out optimized one.. also writing the code in assembly removes the necessity of cross compilation (carried out for many processors) and thus execution times are faster...
hope this helps a bit..
I may be wrong, but I suspect abhisdm is confusing assembly language with .NET assemblies.
•
•
Join Date: Sep 2008
Posts: 5
Reputation:
Solved Threads: 0
I'm a relatively accomplished C and assembly programmer and use the OpenWatcom C/C++ development environment.
When I began programming in 1982 the compilers were pretty good but you could still get sizeable speed advantages by coding in assembly. With the advent of multi-stage pipelines and parallell execution units it has become increasingly difficult to get any "classical" speed advantage by hand-coding in assembly. One application I worked with a few years ago had an extremely tight loop (10 lines of C code) in a function that I thought I'd optimize. Several hours and versions of code later I had managed to best the C code by a few percent - definitely not worth the effort.
Since I still write fast applications I've turned to another advantage of assembly which is inlining, using OpenWatcom's "#pragma aux" construct:
Suppose you have a loop which scans though a buffer and depending on what it finds moves data from the buffer elsewhere. Ususally you would use memcpy which calls a small procedure containing a load-store-iterate loop. Using the Watcom construct the move operation(s) are inlined with the C-code which gives two performance advantages, namely that I reduce the number of parameter preparation/call/return/stack fixups and that I lessen the risk of an instruction cache miss (since I can ususally assume that my memcpy procedure won't be anywhere near - address-wise - the loop that calls it which will, in all probability cause, a miss). Because of the reduced overhead my entire loop (usually) becomes smaller which also increases the probability of staying in the cache.
This may sound like splitting hairs but you get a great speed advantage if you're able to keep to the L1 cache without having to stoop so low as to resort to L2, L3 or even RAM (God forbid!).
When I began programming in 1982 the compilers were pretty good but you could still get sizeable speed advantages by coding in assembly. With the advent of multi-stage pipelines and parallell execution units it has become increasingly difficult to get any "classical" speed advantage by hand-coding in assembly. One application I worked with a few years ago had an extremely tight loop (10 lines of C code) in a function that I thought I'd optimize. Several hours and versions of code later I had managed to best the C code by a few percent - definitely not worth the effort.
Since I still write fast applications I've turned to another advantage of assembly which is inlining, using OpenWatcom's "#pragma aux" construct:
Suppose you have a loop which scans though a buffer and depending on what it finds moves data from the buffer elsewhere. Ususally you would use memcpy which calls a small procedure containing a load-store-iterate loop. Using the Watcom construct the move operation(s) are inlined with the C-code which gives two performance advantages, namely that I reduce the number of parameter preparation/call/return/stack fixups and that I lessen the risk of an instruction cache miss (since I can ususally assume that my memcpy procedure won't be anywhere near - address-wise - the loop that calls it which will, in all probability cause, a miss). Because of the reduced overhead my entire loop (usually) becomes smaller which also increases the probability of staying in the cache.
This may sound like splitting hairs but you get a great speed advantage if you're able to keep to the L1 cache without having to stoop so low as to resort to L2, L3 or even RAM (God forbid!).
![]() |
Similar Threads
- Assembly or C++ for a Beginner? (IT Professionals' Lounge)
- I know Im dim (Assembly)
- Assembly is used for? (Assembly)
- Assembly, machine code and compilers (Assembly)
- Want to get started in Assembly (Assembly)
- Please AnyBody Can Help Me To Build Assembly Code Infix To Postfix It So Hard T_T (Assembly)
- Dumb Question (HTML and CSS)
- Java to C# Conversion (C#)
- Using x86 Assembly Language with Microsoft Visual C++ (C++)
Other Threads in the Assembly Forum
- Previous Thread: Conversion Assembly to High Level Languages
- Next Thread: Miniature Stoplight Project
| Thread Tools | Search this Thread |






