Assembly language programming vs Other programming languages

[lesaid]

I have never seen nor heard of an actual app ever being ported

I have been out of the industry for a while, but early in my career I was coding commercial data processing applications in 100% IBM assembler! Seems surreal to think of it these days. This software was 'ported' every time there was an upgrade to a new processor version even if nominally the same kind of machine.

I imagine the same would be true of assembler components in more recent systems, unless all such are hardware-specific drivers and such. So not 'porting' as in moving from one manufacturer to another maybe - but porting from one hardware version to another more recent one with different behaviour? Seems likely?

 

[CMalcheski]

"Porting" to upgraded hardware ... absolutely. I just never thought of it as "porting," in the commonly-accepted sense of the word, but really that's exactly what it is.

Ultimately everybody finds their niche and does the work they are most drawn to doing. Some like me are wretched outcasts, condescendingly viewed as idiots who just don't get it, but I'm happy with what I write and that's what matters most to me.

 

[Khashishi]

Assembly language was useful in the past to squeeze every last bit of performance out of a single processor, strictly sequential system. Nowadays, it isn't as relevant since performance programming has moved on to multicore systems with parallel computing and perhaps GPU computing. Assembly language is basically a list of sequential instructions for a CPU, but in modern systems, instruction handling isn't sequential or necessarily synchronous.

 

[swordsman]

Assemble language could have been by far the best, but then C-code came along, which is a higher level language that was soon adopted. Unfortunately, it is (in my opinion) not the best since it is not as efficient as it should be due to the way it is designed. Assembly code directly addresses all computer machine processes, of which there are many combinations. Many years ago, I designed an assembly code "typewriter" for a newly introduced microcomputer that had keys labeled with the all of the assemble code values. The intent was to make coding highly efficient. This would probably not be feasible for C-code. Unfortunately, the microcomputer company discontinued their microcomputer production line.

 

[FactChecker]

I have never seen nor heard of an actual app ever being ported. I'm sure it happens; I just don't see where. And I view the entire process as the ultimate in shoddy shortcuts and laziness. Just my personal opinion; we all have one.

Code reuse is desirable. I wouldn't consider it shoddy or lazy.

 

[TheOldFart]

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

I've got 30+ years behind the keyboard, man and boy. I've written large to very large chunks of software in assembly a dozen different CPUs 68xx, 68000, 68020, 68360, 68HC11, tms34020, 8086, 286, 386, 486,, 8052 etc.

I spent a decade programming from schematics, today I work on highly scalable and fault tolerant Java server side stuff.

The first fact of modern life is that counting cycles doesn't work with modern processors since they have pipelines. The compiler has a better view of instruction scheduling than you do, and no one can pretend that they can juggle that viewpoint on any non-trivial assembly language app. So unless you're writing for some simple-minded microcontroller, you can't claim it's faster until you run them side by side - in which case why write the assembler version in the first place? Profilers will tell you if it's needed.

The second fact of modern life is that scalability matters more than throwing raw CPU at it. So what if your Java code runs 1/4 as fast as assembly code? You write some readable code using an understandable pattern, throw some more cores at it and then you go make progress on the *purpose* you wrote the code for. Sitting around admiring all the shiny bits is not solving problems, it's a sort of engineering masturbation practiced by engineers who haven't grown up. (and I say that as a software engineer who can gold plate requirements and be more anal about code than most so I'm definitely including myself in that group)

The code is not the goal. Solving problems is the goal. The readability, scalability, maintainability of the code all matter far more than the performance, for a lot of reasons.

Biggest reason is this: You know where your code spends most of its time? No you don't. If you don't have profiler output from your application running in a production environment then all you're doing is guessing and I'd guesstimate a 95% chance that you're wrong. I've done it on many projects, even when were absolutely confident where the problem would be, we were wrong until at least the third pass through the profiling process.

Second biggest reason is that if your code is modular, based on standard patterns, and readable then you can identify the tiny percentage of your code that actually *might* be a performance bottleneck using readily available high level tools. You can't go the other direction, there aren't any tools to reverse engineer a buttload of spaghetti code hacked out in the name of "efficiency" and turn it into something readable/valuable. Also if the code is readable and based on standard patterns then you can at least understand it and consider whether you can solve the problem simply using scalability rather than resorting to the brute force/blunt axe of assembly language to cover up your design mistake or incorrect choice of algorithms.

In Agile you have the concept of "last responsible moment" You put off defining or doing work until as late as you can because the later in the process you are, the less likely you are to be affected by changes. To start out a project writing assembly code is the ultimate in "first irresponsible moment" because you've made the decision to invest maximum effort at a time when you've also got maximum uncertainty. If you get down to the last possible straw and assembly language is the only way to solve the problem then you've done your due diligence and it really has to be that way. Otherwise you're just fondling your pocket protector.

The only valid reason I know of for writing assembly code from the start is a manufacturing cost one. If you're going to make a million devices and you can save $1 on each one if you can use a cheaper microcontroller or CPU, you _might_ have an argument...though I'd still argue that the company's reputation for producing reliable products is a big implicit cost that often gets left out of that discussion.

 

[Hellmut1956]

What was written in this thread about assembler code versus compiled code to my believe does not touch an equally critical argument for compiled programming. Modern processor architectures have multiple caches, do preprocess instructions, does pre-execute code based on assumption of the most probable branching of the code etcetera. To write assembler code that takes those issues into consideration is realistically seen very close to impossible for someone writing code in assembler. Compilers have so called "switches" that tell the compiler if the code it is going to generate is optimized for speed, for code density or a balance between those priorities. It then generates code that looks very different depending on the setting of such switches.

I did write the whole firmware for an NEC 7220 graphic controller to be used in a terminal and did write the assembler code for the MC6809. I guess none of you readers have ever heard about the NEC 7220 graphic controller that was very popular in the early 80's! Today, as it has been correctly stated in this thread neither memory nor CPU performance are really limiting factors and so today I use the language Python very much. This is an interpreted language which tends to be much slower than compiled code. tends to be is the term is used to express that languages are made of instructions and those are provided to a high extend as elements in libraries. The Python language, a scripting language can still be very efficient as the library elements can have been coded using C or C++, so that they are already present in machine language that can be executed directly from the processor or compiler. So a scripting language like Python can be just the tool to concatenate precompiled code of its library elements!

 

[phinds]

There's faster compiling languages than "C", we're talking about large factors faster.

https://brenocon.com/blog/2009/09/d...t-and-most-elegant-big-data-munging-language/

MAWK is one of the fastest languages out there and that makes a HUGE difference in transforming massive amounts of data where parallel computing becomes important.

As I understand it, that is NOT a general purpose language. It is "extremely specialized for processing delimited text files in a single pass"

 

[FactChecker]

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

 

[IDNeon]

As I understand it, that is NOT a general purpose language. It is "extremely specialized for processing delimited text files in a single pass"

Well it does quite a bit more though, and is good for number crunching. Which is why I thought it interesting to mention here.

 

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

 

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