Assembly language programming vs Other programming languages

[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.

 

[SlowThinker]

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

My point was that the translated instruction is different depending on the address of the target of the jump. The assembler needs to figure out this address during compilation. So it's not really 1:1 correspondence between what you write and what results. Some CPUs have relative addressing of jumps, so

jmp imalabel

can result in different bytes every time it is used.
Compiling C, in my opinion, is more of the same, not something qualitatively different.

 

[TurtleMeister]

I think TMT has been misunderstood. Maybe English is not his first language? Anyway, I get the gist of the point he's trying to make. As SlowThinker pointed out, assembly does not always translate to the same string of machine code. The assembler is to assembly language what the compiler is to high level languages. It's just that modern high level languages have taken this idea to the extreme. In both cases the language was created to make programming easier and faster for humans.

 

[TurtleMeister]

Remember debug that came with DOS? I remember using only debug to write assembly code that could be called from BASIC. It was a powerful combination. I remember my coworkers being dazzled and saying "Wow, how did you do that"?

But my first introduction to assembly was with the TRS-80 back in the late 70's. I wanted to write a program to send Morse code (ham radio), but I quickly discovered that BASIC was too slow, especially with a CPU running at less that 2MHz. So I ordered the technical reference manual for the TRS-80 and the instruction set for the Z80 microprocessor. I was amazed at being able to have complete control of the machine and all it's hardware. I remember dreaming of one day writing my own operating system. And it was probably a doable thing for just one person back in those days.

Even though I haven't used it for many years, assembly remains my favorite programming language. Modern machines and compilers have become so good that it's just no longer practical in most cases (except for microcontollers). Who cares if it takes 16k to do Hello World? It's kind of funny that 16k was the maximum RAM size on my TRS-80.

 

[wle]

I think TMT has been misunderstood. Maybe English is not his first language? Anyway, I get the gist of the point he's trying to make.

I think the point is that programming languages are normally considered "high-level" or "low-level" depending on how much they abstract the details of the hardware you're programming on. So Assembly is "low-level" because you're expressing how a program should accomplish some task directly in terms of the set of instructions supported by the processor. C is higher-level than Assembly but still a relatively low-level language: it hides the specific processor instruction set, but its feature set still largely corresponds to that of a sort of hypothetical "generic" processor and addressable memory. (One of C's nicknames is "portable assembly".)

Higher-level languages offer more insulation from the hardware, e.g. with features like automatic memory management, built-in collection types like lists and associative arrays, arbitrary-size integers that don't overflow, an exception system, anonymous functions/closures, dynamic typing, code and/or object reflection/introspection capabilities, etc.

 

[TurtleMeister]

I think the point is that programming languages are normally considered "high-level" or "low-level" depending on how much they abstract the details of the hardware you're programming on. So Assembly is "low-level" because you're expressing how a program should accomplish some task directly in terms of the set of instructions supported by the processor. C is higher-level than Assembly but still a relatively low-level language: it hides the specific processor instruction set, but its feature set still largely corresponds to that of a sort of hypothetical "generic" processor and addressable memory. (One of C's nicknames is "portable assembly".)

Higher-level languages offer more insulation from the hardware, e.g. with features like automatic memory management, built-in collection types like lists and associative arrays, arbitrary-size integers that don't overflow, an exception system, anonymous functions/closures, dynamic typing, code and/or object reflection/introspection capabilities, etc.

I agree. If you must draw a line between low-level and high-level then it would be the degree of isolation from the hardware. However, I don't think that was the point of misunderstanding.

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.

That is NOT a reasonable use of the term "high level language". Assembly is specifically NOT a higher level language.

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.

I do not think TMT is claiming that assembly is a high-level language per se, but only pointing out the similarities between the assembler and the compiler. And I also agree with TMT that assembly is not the same thing as machine code. Machine code makes me think of the computers before keyboards and monitors where you entered code via toggle switches and push button. And depending on the editor you're using, assembly language could be considered "higher level" than machine code. You can, for example, use variables in assembly programming. This in effect isolates you more from the machine than if you were doing machine code only.

 

[phinds]

I do not think TMT is claiming that assembly is a high-level language

Well, I guess I was misled by his saying:

... assembler may be count as high level language

I tend to take words to mean what they say. I realize there were caveats on both of your statements but I don't think they negate the underlying statements. At any rate, we're arguing about how many angels can dance on the head of pin

 

[jack action]

Well, I guess I was misled by his saying:

... assembler may be count as high level languages

That is really unfair to @TMT . His full quote was followed by an 'if':

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.

Which clearly states that (following the OP's question) assembly language is to machine code, what other programming languages are to assembly language.

His opinion was that, with respect to machine code, assembly language is a higher level language which, I think, was demonstrated by @SlowThinker .

 

[.Scott]

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.

Let's not refer to assembly and macro-assembly as "high level languages". That phrase was coined specifically to exclude such languages.
What makes a language "high level" is more than whether there is a one-to-one match between "lines of code" and machine instructions. For example, high level languages are expected to be portable from one processor to another.

The "generation" of the programming language is a closely related term. See https://en.wikipedia.org/wiki/Programming_language_generations.

 

[jim mcnamara]

I'm going to stay out of this. But there are definition issues. Clear debate requires that every use the same terms with exactly the same meaning. Can we agree on meanings?

We also seem to have ESL issues, too. I've been part of discussions in languages that are not my native language. It is really hard to do well sometimes. FYI.
ESL=English as a Second Language.

So please try to work out definitions clearly, first. Thanks.

Thanks to @.Scott for trying.

This thread has some good content!

 

[TurtleMeister]

I'm going to stay out of this. But there are definition issues. Clear debate requires that every use the same terms with exactly the same meaning. Can we agree on meanings?

We also seem to have ESL issues, too. I've been part of discussions in languages that are not my native language. It is really hard to do well sometimes. FYI.
ESL=English as a Second Language.

So please try to work out definitions clearly, first. Thanks.

Thanks to @.Scott for trying.

This thread has some good content!

Well, I think that everyone here would agree that:
Machine code = low level
Assembly = low level
C and most everything else = high level

It seems to me that the argument is whether it's ok to say that assembly is a higher level language than machine code rather than saying that they are the same thing.

Anyway, I agree that the thread has some good content, but I must leave for a while. Will check back when I can.

 

[phinds]

I'm going to stay out of this. But there are definition issues. Clear debate requires that every use the same terms with exactly the same meaning. Can we agree on meanings?

Good idea. I've been too stuck on details, I think.

I understand what everyone is saying about the difference between machine code and assembly language, but let's do all stick to the standard terminology and agree that assembly is not a higher level language and in fact is disallowed from BEING a high level language by definition and common usage of the phrase.

The original question as about the speed difference between assembly language (~ machine code) vs high level languages. Are there still open questions about that?

 

[TMT]

The original question as about the speed difference between assembly language (~ machine code) vs high level languages. Are there still open questions about that?

Most people think assembly is speedy than high level languages. But I'm telling if high level language is configured more intelligently, it may be faster than assembler. Speed is majorly dependent on algorithms. if you implement an algorithm time cost as W(n) in assembly code (supposed as faster) a high level language (basic or any interpreted) implement algorithm time cost as W(log n) your assembly programs will breath the dust of the high level language implementation.
Also the intelligence embedded in high level language may generate speeder code. since embedded algorithm may create more optimized code than human can create.

 

[Mark44]

Most people think assembly is speedy than high level languages. But I'm telling if high level language is configured more intelligently, it may be faster than assembler. Speed is majorly dependent on algorithms.

Well, of course. No one in this thread is claiming that a slow algorithm coded in assembly will run faster than a faster algorithm coded in a higher-level language.

if you implement an algorithm time cost as W(n) in assembly code (supposed as faster) a high level language (basic or any interpreted) implement algorithm time cost as W(log n) your assembly programs will breath the dust of the high level language implementation.
Also the intelligence embedded in high level language may generate speeder code. since embedded algorithm may create more optimized code than human can create.

 

[phinds]

Most people think assembly is speedy than high level languages. But I'm telling if high level language is configured more intelligently, it may be faster than assembler. Speed is majorly dependent on algorithms.

As Mark pointed out, you have set up a dummy straw man argument and then shown that it's wrong. Your point is valid but really is irrelevant to this thread.

 

[TMT]

As Mark pointed out, you have set up a dummy straw man argument and then shown that it's wrong. Your point is valid but really is irrelevant to this thread.

Think on a case a machine having 16 register (as IBM), In program; you branch into a subroutine, you will going to save registers before starting subroutine and restore them before return back to caller Tel me how many programmer could count and mark which registers are altered in subroutine and write code to save and restore only those register. (register saving & restoring time cost is depend on # of register involved) But if your H_L compiler has an intelligence to consider this code will save & restore only altered registers process and optimize code accordingly. Please take this simple example as only to express my intention Since we can embed some logic in compiler we can let compiler will generate more optimal code than human can. (especially if you accept all programmer will not be smart as a versed one) in H_L compiler you even preprocess written code and localize some part as optimizable and apply specific process to optimize code generation. You can not train all your staff as versed assembler programmer. But you can use a high quality (optimization intelligence embedded) H_L language compiler to produce faster code.