Assembly language programming vs Other programming languages

[phinds]

I assume that modern assemblers have the same optimization options that higher level language compilers have.

I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.

 

[IDNeon]

I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.

A wizard is never buggy. He writes precisely what he means to.

 

[.Scott]

As has been mentioned earlier, assembler is used very sparingly. Even in situations where there is "no choice", the assembler is often isolated. For example, most CPU's provide a selection of "atomic" operations such as "compare and exchange". But rather than code the assembly, there are functions that usually place the required assembly inline with your code. In the Microsoft development environment, this is the "InterlockedCompareExchange()" function:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683560(v=vs.85).aspx

Still, there are cases where a particular block of code needs to be executed as fast as possible - either because a very rapid response is needed or (more likely) that block of code is executed millions of times. In such cases, the first strategy is to devise an algorithm that is fast and allow certain optimizations, like placing functions inline to the main program and flatting loops. Many compilers will provide options for doing exactly this - and those optimizations can be applied specifically to the section of code that requires it.

But if all that is not enough, sometimes assembly code can be crafted that is substantially faster than compiler-generated assembly. The computer programmer can often device methods of arranging for the code to use different types of memory access cycles most efficiently and sometimes there are special functions provided by the CPU that can be used creatively to perform unexpected functions. In some cases, the result can be a 2 or 3 fold increase in speed. In a recent case, I was able to use machine instructions intended for digital signal processing to rapidly compute the median value for an integer array. But the situation was so specialized, it would make no sense to try to get a C++ compiler to mimic the technique.

 

[.Scott]

I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.

That is correct. Assemblers don't optimize.

 

[FactChecker]

I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.

Ok. I'll buy that.

 

[Khashishi]

Consider that in order to craft more optimized assembly than a compiler for a particular computer architecture, you need to be an expert at that particular architecture. And if you want it to run optimally on another computer, you'll have to find an expert to rewrite it for that computer. One of the best ways to improve the performance of a code is to run it on a faster system. If you hand craft it in assembly, you lose that option.

If you must get it to run as fast as possible, you should probably write it in FORTRAN or C.

 

[.Scott]

Consider that in order to craft more optimized assembly than a compiler for a particular computer architecture, you need to be an expert at that particular architecture. And if you want it to run optimally on another computer, you'll have to find an expert to rewrite it for that computer. One of the best ways to improve the performance of a code is to run it on a faster system. If you hand craft it in assembly, you lose that option.

If you must get it to run as fast as possible, you should probably write it in FORTRAN or C.

The case I cited above was an mass-produced embedded system with heat limitations. The issue isn't "as fast as possible" but simply "fast enough to keep up with a real time data stream". Moving to a faster processor would have caused too much heat and too much electric consumption - and the additional cost would have made the product much less competitive. As processors advance, we upgrade to the new technology, become experts in the new architecture, and create improved product. Sometimes that means assembly. But the total assembly is always way less than 1% of the code.

 

[rcgldr]

I would argue that assembly language is *not* faster in anything other than perhaps the smallest microcontrollers.

Take a look at post #21:

Assembly language programming vs Other programming languages

These are unusual cases, but they do exist.

The 500+ line CRC optimized for speed assembly code using pclmulqdq is something that a compiler isn't going to be able to duplicate, even with an intrinsic function for the pclmulqdq instruction. Intel created a document about this:

http://www.intel.com/content/dam/ww...ation-generic-polynomials-pclmulqdq-paper.pdf

The IBM mainframe assembly code is a combination of legacy code for file access methods (assembly macros). I'm not sure if the assembly modules using processor specific instructions for speed could be replaced by Cobol assuming it's optimizer takes advantage of those instructions, but who's going to replace fairly large libraries of working assembler code?

 

[Mark44]

Still, there are cases where a particular block of code needs to be executed as fast as possible - either because a very rapid response is needed or (more likely) that block of code is executed millions of times. In such cases, the first strategy is to devise an algorithm that is fast and allow certain optimizations, like placing functions inline to the main program and flatting loops. Many compilers will provide options for doing exactly this - and those optimizations can be applied specifically to the section of code that requires it.

But if all that is not enough, sometimes assembly code can be crafted that is substantially faster than compiler-generated assembly.

Indeed. I used to work in the MS Windows Division, and had access to the Windows code base. I remember seeing some video driver code with a few lines of inline assembly, possibly for lighting up pixels in display memory (that was about 10 or so years ago, so was somewhere in the XP or Vista timeframe).

A few years later I was working in the Office Division, and spotted some code for processing audio, that used some of the Intel SIMD instructions. I don't know if that code was actually shipped in any Office product, but I knew that someone had written it to take advantage of SIMD (single instruction, multiple data) technologies in the later Pentium and (I believe) AMD processors.

The point is that when you need to push a huge amount of data through at a high rate of speed, either for video display or speech recognition purposes, some well-crafted assembly can be very useful.

 

[jim mcnamara]

@phinds - we've had to clean up some bad posts and your answer is kind of dangling now. Sorry. Remember 'dangling participles' way back when?

 

[phinds]

@phinds - we've had to clean up some bad posts and your answer is kind of dangling now. Sorry. Remember 'dangling participles' way back when?

np. How could a grammar Nazi like me forget dangling participles?

 

[ChrisVer]

So far the inputs tend to dissing assembly over the usage of several cores for speeding up the process...? So ASM seems to be losing the privilege it's so proud of?
Also one thing that seems unclear to me, is the speeding happening in the compilation time or for the program's runtime? In terms for an IDE during Building or during Running your code?

 

[FactChecker]

Also one thing that seems unclear to me, is the speeding happening in the compilation time or for the program's runtime? In terms for an IDE during Building or during Running your code?

I think practically all the posts are talking about execution speed, not compilation speed. There may be an exception or two.

 

[Mark44]

I think practically all the posts are talking about execution speed, not compilation speed.

I agree. The time it takes to compile is of little concern--the goal usually is to get the program to run faster.

 

[TMT]

Hi guys,
I like to say that you can use either forks or spoons for eating.the question "which one is good for eating fork or spoon?" is an absurd question. fork is for some meal while spoon is good for some other. But keep in mind hand is also good for eating.
I mean, assembler is best for time and space mostly. But do you need this amount of speed or space?
The most crucial issue is algorithm. You can calculate time cost or space cost of algorithm. When you consider the bottleneck of your resources (CPU,memory,response time) you can reduce the cost with expense of others.
The memory used by program code is not too much important. Ok assembler will spend less memory for code (apparently) but consider the actual code running is not only program lines you wrote. You mostly utilise kernel (BIOS) codes (through interrupts or service calls)
When you use high level compilers same unseen things also happens. for example either DLL or ordinary library usage. How you manage them? how many routine packed together? There is no selective loading. Library modules load together at once. Then in linkage phase only requested codes wired with your code. Then, when you re organize the library modules you will observe great amount of shrinkage of module size. High level language try to provide a lot of stuff in their support libraries therefore resulting module sizes considerably greater than assembler.
if your resources is limited like as single chip processor with 1 kbyte ROM and 256 byte memory. every byte is important. Believe me you can challenge with this with wiser approach like explore logic and try to reuse code segments several times. But aware your code became real spaghetti. Maintenance of such a code become even impossible.
You can also speed up your code if you consider cache sizes and organize memory usage accordingly.
You can profile your high level programing codes to spot out bottleneck points. then write this portion with assembler. (but first check algorithm for that portion of code)

 

[.Scott]

So far the inputs tend to dissing assembly over the usage of several cores for speeding up the process...? So ASM seems to be losing the privilege it's so proud of?

First, no computer programmer is going to "dis" any potentially valuable tool. Assembly has huge disadvantages in the areas of maintainability and portability. In the example I gave, it was a multi-core processor, but even so the best product solution required assembly code.

When it comes to cores vs. assembly code, you shouldn't expect that increasing cores will necessarily buy you what you need no matter how many there are. If you are driving a serial process where every step requires the results from previous steps, extra cores will buy you nothing - the oft-stated situation of 9 women working on a pregnancy.
In cases where there is a trade-off, you need to weigh the advantages of portability and maintainability over the advantages of a smaller physical package, less power and heat, cheaper BOM, etc.

Assemblers "privilege", as with any tool, is in its utility and economics. Certainly, there was a day when tripling the execution time meant that you only had a one-room computer system with associated power, floor loading, and air conditioning instead of 3 - or you completed a data run in 1 week instead of 3. You can still have those trade-offs today, but they are far from typical.

More importantly, optimizing compilers and linkers are now really good. Not just any assembly will beet the compilers - only assembly that is very targeted and carefully written.

To give a sense of this, fourty-five years ago on average a line of assembly code was faster to write that a line of RPG, COBOL, or Fortran. That's totally untrue. Assembly coding is no longer that casual. In general, any assembly code written today will have a C/C++ version written beforehand or at the same time - and a timing comparison will be used in making the decision which one should be used. It's usually a big deal.

 

[TMT]

Hi again,
I like to continue post #75; Guys before comparing assm. with other language we have to make a good analysis. What would be answer for "why we are using assembler and not using machine code?" All your answers be "because written in machine code more difficult and error prone . using Assembler is more wiser." if you notice at very beginning we aware to use a computer program (assembler) to make life easier for us. If we stick with this motto , The high level languages is useful to reduce development time and help programmers. Long time ago when I'm dealing with assm. code, I explore the Macro facility of assembler. Then I create very rich macro library. Programing with this maclib became more easy and productive. if we consider high level programming languages like as my maclib. computer is first serving me in coding and with my code and computer is serving to others. if I'm not benefiting from computer and I offer others to benefit from computer. Something is wrong with me. First I must write some preprocess code to help me more comfortable production, beside faster and smaller codes.

We can enhance high level languages to help and serve first to programmers.

Thing about instruction pumping to speed up computation,

You have to careful about registers you are using the instructions before your line may alter its value. You may insert some NOP line to create delay before your code line. But if you miss then you can't catch this later. Your program produce bullshit. most probably you will not catch the case on debugging also. But in compiler program you handle this by inserting more smart logic in assm code generation part. Compiler program helps you.
As I said in post #75 we have to be smart. Think a program is performing "Login" logic at the very beginning of program and a huge number cracking calculation later. Which programming language you prefer to implement this program? Since there is huge number cracking calculation the interpreter type languages like java, ruby, rexx, etc. is not wiser. Even COBOL in high level language But "Login" logic will run for once and running in several minutes will not affect. The wiser approach is writing number cracking calculation in assembler as a Subroutine and call from higher level language which providing a framework for user interfaces. This approach will good for portability of code to different hardware architectures.

If you know what are you doing you select language accordingly.

 

[Mark44]

What would be answer for "why we are using assembler and not using machine code?"

I've been following this thread closely, and to the best of my knowledge, no one is comparing assembly language and machine code.
The question being asked is "why would one choose assembly language over a high-level language?"

 

[phinds]

I've been following this thread closely, and to the best of my knowledge, no one is comparing assembly language and machine code.

And even more, the analogy would be pretty pointless since assembly and machine are the SAME code whereas assembly vs higher level is a comparison of different languages. @TMT , I think you're off base on this one.

 

[.Scott]

I can say a few words about machine language vs. assembler. As is noted by phinds, its the same code so why go with cryptic machine language? I see four situations:
1) There is no assembler available. This doesn't happen anymore. Even with a completely new CPU, a cross assembler and cross compilers are developed and become available before the hardware is ready. But in the "old days", things were not so luxurious. There was the "programmers panel" and not only was it available for entering machine language directly into the computer and then step through the code, but that was the only way to get the computer to start doing anything.
2) For instruction: it's not a bad educational exercise.
3) Pure hacking. For example, if you're looking to exploit a zero-day bug in your favorite app, you may need to really get down into the bits - like making the right set of numbers add up the instruction code you are looking for.
4) In the early DOS days, I knew some of the handy "Int 3" codes. And I had a handful of 2 to 10 byte programs that were handy tools, especially when mixed with batch files. In today's world, I would just keep them on a USB stick. But then there was nothing so handy. So, for example, if I needed my 3-byte REBOOT.COM, I would use the octal editor available in DOS to create it on the spot.

 

[TMT]

The question being asked is "why would one choose assembly language over a high-level language?"

I think both of you could not catch the idea by this example. I mean assembler may be count as high level languages if you consider a program (assembler) takes some line of instruction and create machine code. Same as high level language a program (compiler) takes lines of expression and (mostly) creates assembler (text code) than assembler creates machine code from it. Same pattern implemented. I'm telling that if a program (compiler) taken expression lines process and produce assembler text we can insert more intelligent logic producing assembler text. This logic will help us more.

ntless since assembly and machine are the SAME code whereas assembly vs higher level is a comparison of different languages. @TMT , I think you're off base on this one

no my friend they are not same. One is text (ascii) while other is binaries expressed in numbers. Assembler is providing labels make life easier for addressing. you have to calculate address in machine code. I'm not offering to use machine code. I try to emphasis the design pattern on assembler and high level both aim to help programmer

I'm telling first we clearly understand what we like to do. A faster, (maintainable) development or small size and ?? faster code
Faster is closely related with logic you prefered. Say that we like to write a program sorting 1M name (17 character) if you select bubble sort algorithm will take hours. The language you prefer (assembler or high-level) is irrelevant. But if you create hash code for names first and run same bubble sort algorithm you will found shorter execution time. Because character comparison done byte by byte while hah code is number and simple subtraction gives comparison result.
if you change bubble sort algorithm with some other algorithms like quicksort, radix sort, or some other algorithms with time cost is logarithmic (not linear as bubble sort) speed became as flash. The time gained by writing program in assembler instead of high-level ignorable. But I'm not telling writing in assembler with proper algorithm is not ultimate target. But always be practical. if you run this program once a year and no time constraint, don't bother yourself to choose language take anyone you mostşy used.
If you writing a program for signal processing I advise think on assembler.
Also think on library usage. wrote some subroutine in assembler and create library. Use high level language and make call to this subroutine written in assembler.
In those days we are mostly developing a package not single program. This bring more other considerations like bug free and maintainable code. which address high level languages.

 

[phinds]

I think both of you could not catch the idea by this example. I mean assembler may be count as high level languages if you consider a program (assembler) takes some line of instruction and create machine code.

That is NOT a reasonable use of the term "high level language". Assembly is specifically NOT a higher level language. For one thing, assembly is machine code which means there is no possibility of it being independant of the CPU it was written for. Higher level languages are not written for specific CPU's, they are written for humans.

no my friend they are not same.

You are completely missing the point. They are the same in that a line of assembly creates a line of machine code. A line of a higher level language can create THOUSANDS of lines of machine code.

Assembly is not a higher level language. If you choose to call it so, you are defying standard terminology and people will disagree with you.

 

[Mark44]

I think both of you could not catch the idea by this example. I mean assembler may be count as high level languages if you consider a program (assembler) takes some line of instruction and create machine code.

Assembly code might have been considered a "high-level" language back in the 1950s, before the advent of true high-level languages such as COBOL and Fortran, but no one today would consider any assembly language as "high level."

That is NOT a reasonable use of the term "high level language". Assembly is specifically NOT a higher level language. For one thing, assembly is machine code

I'm going to disagree with you here, Paul, and side with TMT.
Here is an example of x86 assembly

sub esp,8

Here the stack pointer, ESP, is being decremented by 8.
And here is the emitted machine code for the instruction above:

83 EC 08

Clearly they are different, but as you say, one assembly instruction corresponds to one chunk of machine code.

which means there is no possibility of it being independant of the CPU it was written for. Higher level languages are not written for specific CPU's, they are written for humans.

 

[TMT]

assembly is machine code

NO NOT assembler is

written for humans.

you can't run assembly program before assembling and linkage editing staff.

You are completely missing the point. They are the same in that a line of assembly creates a line of machine code. A line of a higher level language can create THOUSANDS of lines of machine code.

this is not true also simple branch is almost same with assembler code generation while using a macro line in assembler will produce several lines.
I'm not to intend to defying standard terminology I try to say that be aware what is the reality. We developed assembler to help us to create machine code. Think high level in this helping approach. They are helping us. If you properly set the problem like as faster run smaller size etc. You have to follow different path. Making choosing assembler or high level is not the only answer

 

[phinds]

Clearly they are different, but as you say, one assembly instruction corresponds to one chunk of machine code.

Which is exactly the point. They are not identical character by character obviously but they are identical in meaning. There is no such relationship between machine code and higher level languages. I know you understand this but it is not just semantics, it's an important distinction. In the early days there was what was widely known as "the principle of one to one correspondance" which stated that a line of assembly is exactly a line of machine code. The advent of macro assemblers began to blur that slightly but it was still close enough for government work.

 

[phinds]

@TMT I see no point in arguing the point further. We clearly disagree with each other.

 

[SlowThinker]

@TMT I see no point in arguing the point further. We clearly disagree with each other.

I'd try to give a few arguments to support TMT:

1. One line of assembly does not correspond to one line of machine code:

;i'm a comment translate to nothing
imalabel: ;translates to nothing
  jmp imalabel ;there's some logic needed to translate this to machine code
  db 1
  db 2
  db 3 ; translates to 1 chunk of machine code

After all, there's nothing like a chunk of machine code. If you dare, you can jump into a middle of an instruction.

2. If you turn off optimizations and look at disassembly, a line of C code translates to several lines of assembler code in a manner very similar to one line of assembly translating to several bytes of machine code.

Anyway, assembler seems to draw the short straw in this thread.
I'd like to point out that unlike any other language, it will never go out of fashion. It's niche is small, mostly hardware drivers, operating system core, and compiler backend, but it will never stop being used.

 

[ChrisVer]

Wait, I am confused- why is jmp an example for not 1-to-1 correspondance between assembly and machine code?

 

[phinds]

Wait, I am confused- why is jmp an example for not 1-to-1 correspondance between assembly and machine code?

It is. He was just making the fairly pointless point that the binary of the ASCII chars of assembly instructions are different than the binary characters of the resulting machine code.

 

[ChrisVer]

well but as an operator this will have a certain meaning for the machine: it is instructed to jump to the memory position that was held by the labeled part of the code...? I don't know how this would be translated to machine language, but it doesn't sound more complicated or logical than setting numbers to registers.