Machine code

is it possible to learn Machine code, Binary code, things like this. My tutor said its almost impossible....but surely since it exists someone some were down the line wrote it?

@TLapworth93:  The last compiler written in machine code was an old one for Pascal, by the great Anders Hejlsberg.  At least, that's what I heard.  Why you'd write anything else other than a compiler in machine code, I don't know.  Just for the challenge, eh?  I wondered if it was possible to teach a young child to read machine code fluently ... don't know how I would teach it though.  I think it's really an exercise worth trying but you'd probably give up after "Hello World!".  After you get that far, everything is just a simple matter of coding ... forever. 

Really the only people that need to deal with the real binary machine code are the people who design CPUs and people who create compiler backends. Even then they will likely use some level of abstraction (e.g. assembly) whenever possible.

You mean assembly. It's not impossible to learn but it would be stupid to learn since each processor architecture (x86, x86-64, ARM, PowerPC) has it's own instruction set.

I think you are refering to assembly language. Yes it is certainly possible to learn and knowing the fundamentals of CPUs and their instruction sets is very valuable, IMHO. On the other hand their is little practical use for assembly language in mainstream software development. Even developers of device drivers, which are pretty close to the metal, rarely dip into using assembly - doing so presents an obvious platform maintainability problem.

Assembly languages and machine code aren't the same. Assembly files are assembled into machine code. One can certainly learn machine code... but there's little use beyond the academics of it. In college I took a course where we created a very simple virtual machine (called Simple) with an Assembler that produced the byte codes used by this machine. Very useful academic exercise, but not all that useful in the real world. There's very little benefit in knowing the machine language of the architecture you're on, unless you're actually building said architecture. Knowing the Assembly language for your architecture is more than enough.

Can't agree with folks who think it's not useful to understand Assembly, though. It's important to understand how things work at that level, if for no other reason than to be able to diagnose some class of problems that you'll run into even when developing using high level languages.

2 hours ago, TLapworth93 wrote

is it possible to learn Machine code, Binary code, things like this. My tutor said its almost impossible....but surely since it exists someone some were down the line wrote it?

Your tutor is wrong. It's not hard to learn, but it only has very niche applications, such as developing custom hardware, key kernel components, compilers or some weird low-level security testing.

Yeah you can code in machine code (most CPU makers provide detailed manuals for their instruction set). But it's more common to program in an assembly language, which more human readable and typically maps 1:1 to machine code. But there is nothing stopping you from coding in machine code directly. I had a professor that claimed this wasn't uncommon in the 70s.

http://www.intel.com/content/www/us/en/search.html?keyword=instruction+set+manual

There are many assemblers for x86/AMD64, here is one example often used for learning (free/multiplatform) called FASM:

http://flatassembler.net/

You can even write your own if you want a challenge.

The most common assembler for handwriting x86 is NASM (the Netwide assembler). It uses Intel syntax, which is the same as WinDbg and Visual Studio's syntax. FASM, MASM and GAS tend to have peculiarities because they're either really old, or really intended as a compiler back-end.

But if you're just interested in playing with assembler, create a C project (in visual studio) and do this:

__declspec(naked) foo()
{
  __asm 
  {
    int 3
    mov eax, 0xaabbccdd
    ret
  }
}

void main()
{
  int result = foo();
  printf("%08x\r\n", result);
}

"int 3" gives you a manually inserted breakpoint so you can step through the function.

You can also right click the program at any breakpoint when you're running C or C++ code and click "view disassembly" to show the output of the compiler. You'll notice there that the code is much less understandable but also much shorter when running release builds.

Finally you can right click in the disassmbly window to "Show Code Bytes", which will show you the actual opcodes that are being sent to the processor.

And if you want to be really hardcore and just do machine code directly instead of assembly, try something a bit more like this.

BYTE[] data= { 0xcc, 0x33, 0xc0, 0x40, 0xc3 };

void main()
{
  FARPROC fp = (FARPROC)&data[0];
  DWORD _ignore;
  VirtualProtect(fp, sizeof(data), PAGE_EXECUTE_READWRITE, &_ignore);
  printf("%08x", fp());
}

damn, it all looks pretty complicated. im studying to someday go into PLC programming. industrial automation as i am being taught by a company that makes these machines. im learning C sharp but was just wondering about the machine code (or assembly language). i think i might give it a try in the near future. thanks

6 hours ago, TLapworth93 wrote

damn, it all looks pretty complicated. im studying to someday go into PLC programming. industrial automation as i am being taught by a company that makes these machines. im learning C sharp but was just wondering about the machine code (or assembly language). i think i might give it a try in the near future. thanks

most of the time you will read and write the assembly language code for a given cpu not the binary machine code, think of assembler as the "source Code" for the machine.

when you have to fix a bug in the code you will often use a tool that may be called a debugger or a monitor that can read a block of memory and display the assembly code that it in that block so that you can understand it more rapidly.  in time you will start to see how the two are related

most of them will show hex values on the left and then the assembly on the right so that you can learn them both.

but often you may also have a C compiler that has been optimized to generate code for a given cpu that let's you spend say 95 to 99% of the time working in C code.

C can often be translated by a good compiler to very clean tight machine code.

what you should do first is get really good at converting between number systems, decimal, octal, hexadecimal and binary as that skill will help you learn to read the memory dumps that have the machine code sections.

You can get a good feel for assembly without the complexity of the x86 instruction set by playing around with a RISC assembler. We did this in college and it was really neat to get down to that level. It makes you appreciate the higher level languages even more.