Dear All,
would you please tell me in brief that
" What are the applications of Assembly Language where any high level language becomes insufficient".
Kind regard
Short practical summary: assembly is worth using when a high-level language cannot provide required hardware control, deterministic timing, or binary-size guarantees. Typical cases are: early boot and mode switches, OS kernel entry/exit and other privileged instructions (as noted), interrupt service routines and low-level device drivers that must manipulate registers or I/O ports, ultra‑tight real‑time loops with strict cycle budgets, small firmware/bootloaders where every byte counts, and some cryptographic primitives that require constant‑time implementations. Agreeing with , most application code is better left to an optimizing compiler; hand assembly is usually justified only for a few narrowly focused hotspots or hardware-bound code.
Practical workflow and cautions: always measure first. Attempt compiler optimizations, link‑time optimization, and profile-guided builds before rewriting in assembly. Prefer compiler intrinsics or builtins for SIMD and atomic operations to retain portability and correctness; inspect the compiler-generated assembly to see whether a hand rewrite is needed. When hand assembly is required, isolate it as a small module with a clear ABI, keep a well-tested C fallback, document the CPU/ABI assumptions, and add unit and regression tests — microarchitectural changes can make old tuning slower on new CPUs. s point about inlining and cache locality is important: removing call overhead and keeping hot code in L1 frequently yields bigger wins than hand-scheduling instructions.
Checklist (simple, repeatable):
1) Profile to find the real hotspot.
2) Try compiler flags, LTO, PGO.
3) Use intrinsics or tighten the C first.
4) Inspect compiler asm; only then write isolated hand-asm.
5) Provide a tested C fallback and document assumptions. Clarifying note: "assembly" (CPU mnemonics) is distinct from a .NET "assembly" — the terminology confusion mentioned by was already called out by .
Jump to Post— Salem 6,009An example would be certain aspects of the OS which deals with priviliged instructions.
There are others, do you have any to suggest?
Jump to Post— Alex Edwards 321I've just begun reading the AoA book, and the author points out that one of the benefits of Assembly is that it is faster than any HLL and can provide algorithms that HLL's cannot.
I hope that's helpful >_>
Jump to Post— mathematician 0Personally I would say that the only time you need assembly language in the modern world is if you are writing an operating system, anything else which is very low level, or with something which is very speed critical.
An example would be certain aspects of the OS which deals with priviliged instructions.
There are others, do you have any to suggest?
I've just begun reading the AoA book, and the author points out that one of the benefits of Assembly is that it is faster than any HLL and can provide algorithms that HLL's cannot.
I hope that's helpful >_>
Personally I would say that the only time you need assembly language in the modern world is if you are writing an operating system, anything else which is very low level, or with something which is very speed critical.
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..
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'm not sure I understand any of that. Ignoring macros for the moment, assembly language mnemonics are just a more readable version of machine code instructions; there is more or less a one to one correspondence between them. It is possible to turn out assembly code as poorly written as code in any other language. Further, since assembly code is just a disguised version of machine code, it is very processor specific.
I may be wrong, but I suspect abhisdm is confusing assembly language with .NET assemblies.
Sincere apologies to those who were confused by my reply .... All i wanted to say is that many a times its preferred that the codes are written in assembly wherever possible...
If m wrong.. please correct me....
regards
In my opinion, speed , "special tuning".
Although the portability suffers as ASM is done for one kind of processor only.
gsbr
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!).
Very sensible and it sums it all.
I stay with asm for fun only and because I am lousy in C++
I have attempted (and failed) at C++ many times!
While OO may have its advantages it is not always easy to know what tricks it is up to behind the scenes. A seemingly innocent method may hide enormous amounts of execution. The reusability argument is great. Still, how many organizations have put it to good use and saved money?
The WYSIWYG nature of C and assembly is what appeals most to me.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.