What is the difference between Machine,Assembly and High level programming language

I need to know the briefly explaination between these things. I try to search their difference,but I wasn't lucky to get clear information about these things to understand perfectly.

 

While this reeks of somebody's classwork, I'm bored so what the hell; Let's go down the list.

Machine language

The native language of a processor or processor family. A series of bits (on/off 0/1 data) in a specific "width" (typically but not always multiples of 8) that would look like gibberish to a normal person, and only the most hardcore of programmers would ever deal with. If you've ever heard compiled or assembled programs referred to as "binaries" -- that's what they mean. It's a binary file of native machine language that can be run directly on the processor.

EVERY major processor family has it's own native machine language. This means that for example, intel x86 32 bit machine language can't run on PowerPC or ARM, ARM machine language won't run on x86, AMDx64/Intel EM64T/Whatever they're calling it this week can't even run on a AMD/Intel x86 32 bit processor (though all the "x64" processor are backwards compatible to 32 bit x86)

It's not uncommon for processors from the same COMPANY to have different machine languages. A classic example of this is Intels 64 bit Itanium processors (aka ia64) , which are completely incompatible with the 386/486/pentium/newer line of processors, and even the newer EM64T core/i series. Fun fact, there are in fact AMDx64 and ia64 versions of Windows XP, both are basically reskinned copies of Server 2k3. A LOT of people got that confused grabbing the wrong version!

In the old days almost every processor was incompatible at the binary level with others. Motorola 6502 was radically different from the 8080 and Z80 for example. The 6502 and 6809 despite both being from Motorola were incompatible with each-other, etc, etc...

Assembly Language

This uses words or short "mnemonics" (abbreviations) instead of the binary numbers for the machine language operations. This allows mere mortals to program assembly directly. Assembly can either be hand assembled (by the true die-hard nutters or on lesser platforms), or you use a program called an assembler to turn it into a binary for you.

Just as not all machine languages are the same, not all assembly languages are the same. A great example of this is simply loading a value into a register.

Registers are a spot inside the CPU that's kind of like memory, and it's typically the fastest place to handle information, and for some operations it's the ONLY place you can manipulate it... But let's say you wanted to load the value "1F" hexadecimal (that's 31 decimal) into a 8 bit register.

Motorola classic:
LDA 1Fh

Motorola/AT&T style for 16 bit or wider 68K/Power processors
(doesn't actually HAVE 8 bit registers, will fill remaining register width with zeros)
LD 0x1F, %R0

Intel/Zilog 8 bit
MOV A, 0x1F

Even the assembler you are using can change the syntax of Assembly language!

Motorola/AT&T style on 32 bit Intel using GNU Assembler
MOV 0x1F, %AL

Intel 16 bit/higher using Microsoft Macro Assembler (MASM)
MOV AL, 1Fh

Intel 16 bit/higher using Netwide Assembler (NASM)
MOV AL, 0x1F

... and assembled only the last three would generate the same order of machine language bytecode.

Assembler isn't exactly hard, but it's brute force and you end up doing the same thing a lot. No, A LOT! It's just a LOT of work, and quite often for diminishing returns. There are only two things that make Assembly/Machine language worth resorting to -- Speed and Code size, and those AREN'T always compatible goals. You can actually write REALLY fast machine language by unrolling loops and using certain tricks like translation tables that sucks on the memory like candy. Conversely you can write really tight small code that is many times smaller, but equally that much slower.

Anyone who says a high level language can match properly written assembly/machine language has no honking clue what they are talking about!

In the old micro-computing days when 2mhz or slower was the norm, 6mhz was a blazingly fast processor, and you were lucky if you had 4k of RAM free, machine language was the only practical way to write "real programs" that were actually worth anything. Pretty much if you look at 8 bit and 16 bit games, any of them that were any good whatsoever used at least some assembly in them to speed up operations like writing to the display.

High Level Languages

This term is often misused and mis-attributed depending on one's perspective. To anyone who is serious about writing assembly/machine language, anything that isn't assembler or machine language is a "high level language" -- people who don't usually deal in assembler will often call languages like C a "low level language" and languages like BASIC "High Level"... I personally consider this a meaningless distinction, but I get where that notion comes from. They base this on how "close to the hardware" you are. The closer to machine language the result, the "lower level" it is, and the more of an abstraction for ease of use it is the "higher" they call it.

In fact the mouth-breathing halfwits who say C is close to assembly generally piss me off as they don't know what they are talking about; that was only ever true on ONE platform, and nobody gives a flying purple fish about DEC mainframes anymore!

The entire reason high level languages exist is to take the "grunt work" out of programming. It removes a lot of the control over speed vs. code size, typically resulting in slower/larger code; but the advantage is that code is easier to read, easier to maintain, and portable across different processor platforms.

If you have a "compiler" for the language you are trying to use, it will turn your high level language into machine language binaries -- though that resulting code is typically nowhere near as efficient as assembly simply for the fact high level languages generally are NOT EVEN CLOSE (even C) to how machine language works.

As with assembly though, once you've compiled a "binary" that binary will not run on other processors with a different machine language. You need the source and to recompile for that...

There are also "interpreted" languages. These contain instructions that tell a program called an "interpreter" what to do. The interpreter is typically written in a compiled language for each target and adds another layer of abstraction. The advantages of interpreted languages is that if the target already has an interpreter for the language you are trying to use -- like PERL, RUBY or PHP -- the "distribution" method for the program is the actual source code, and it's 100% portable between platforms.

The disadvantage is that interpreted means SLOW. The source code is "parsed" every single time the code is run.

One way to reduce the speed penalty is called bytecode interpretation. Instead of the source code being parsed every time you run it, it's compiled to an intermediary bytecode that can be processed faster and consume less memory than the full "words" of the language. Most of the early line numbered BASIC's were regular interpreted, but many more used bytecode interpretation. Bytecode being smaller can be read faster, can use translation tables to run faster, and so forth. Better if you don't want to distribute the source code you can send as a bytecode instead -- though classic bytecode methods like line numbered Microsoft BASIC can always be reverse parsed to their original source. (They saved to disk/tape as bytecode to save space, so you HAD to be able to reverse it to edit)

Back in the day RAM was also expensive, while ROM was fairly cheap. Putting an interpreted language like BASIC into a 4K to 12k ROM allowed commonly used routines to be included on the cheap letting far more advanced and complex programs to be put into a handful of bytes of RAM. Nowhere was this more evident than on really early home computers like the Sinclair ZX-80 or ZX-81, TRS-80 Model 1 or Colour Computer, the Apple II, Atari 400/800 and Commodore VIC=20. Many of these systems only had 1k (yes, 1024 BYTES) of RAM, while others had 4k as the base configuration... even in optimized assembler there's not a lot you can do in that much space, but you tack on a 4k to 16k ROM full of optimized code calls, you can write more complex programs in BASIC, or leverage those ROM routines from your Assembler/Machine language.

Likewise ROM could also contain generic routines for things like text, graphics, communications or disk handling. The classic PC "BIOS" (Basic Input/Output System) being one of the longest holdouts from that branch of development.

One of the biggest bytecode interpreters of the classic micro-computing era was Pascal. Professor Wirths original Pascal and the UCSD versions that followed actually had a "Virtual Processor instruction set" it compiled to, where the interpreter basically emulated that processor instead of functioning like a normal language interpreter. The "virtual processor" code was called P-Code. You may or may not have heard that term, but both .NET and Java also use their own flavors of P-CODE to distribute software. The term "Virtual Machine" is just a glorified version of what Dr. Nick was doing with Pascal in the '70's.

A laugh since by the mid 80's Pascal had several actual compilers and was no longer considered an interpreted language/VM... and now Free Pascal can target Java P-Code as one of its targets bringing things full circle.

Changing the game even further for interpreted langauges is "Just in Time" (JiT) compilation. The idea is that source or an intermediary byte-code is passed to a compiler at runtime for routines that would benefit from the speedup. This gives you the advantage of platform neutral source or bytecode, with speeds approaching that of a compiled language during execution -- all at a penalty in time it takes for the program to start. Both Java and .NET have this integrated into them, as do a number of other languages. Google's V8 engine for JavaScript has had this for some time which is why it basically pwns every other JS implementation out there for speed, and why writing native applications in JavaScript is practical through things like nw.js (formerly node-webkit) or electron (formerly atom shell).

--------------------------------------

I'm of the old school group that calls them all high-level, preferring to divide those high level languages into how they are being used: Compiled, Interpreted, byteCode Interpreted or Interpreted with JIT compilation. The only thing that qualifies as low-level is machine language, and by extension assembly.

Hope that helps, it's a pretty big topic and the above oversimplifies somewhat.

 

Its just different layers of coding, programming. Machine code is what processors understand directly. Humans would find it incredibly difficult to write programs in machine code so they need a more human friendly code for that - Assembly code. Assembly code is still primitive, but can be done by humans.......but even this is tough and tedious. Hence the higher level programming languages were developed, like PHP, C++, Perl etc.....all these are much easier for humans to code and understand - and all of these are converter to assembly code and machine code so processors can execute them.

 

Thanx a lot for such a useful information about languages.