Originally Posted by Thor_2.0 (Post 4876198)

For me it was "From chips to systems" by Rodnay Zaks, extremely outdated by today's standards, but it thought me what computers are, what a BIOS is (I even programmed extentions to the thing once) how software ends up being executed...the works...

By the way, why stick to these? What are your goals, byt he way? Building a computer? Just understanding?

Thor

Originally Posted by jokar.mohsen (Post 4877798)

how a computer works really

Originally Posted by jokar.mohsen (Post 4876179)

In your opinion which one of below books is good

Originally Posted by Thor_2.0 (Post 4877844)

keep in mind that there is NO safety net in pure assembly, in fact, you can easyly write straight into the OS and cripple your session, be prepared to restart often

Originally Posted by myzoneajay (Post 4878330)

If you want to learn assembly lang then start with 8085 or may be 8086 microprocessors books.

Originally Posted by johnsfine (Post 4878445)

That is a deep hierarchy of topics, each very challenging. Consider the semi-conductor physics through which the junction in each semi-conductor component operates. A whole different set of physics is involved in the microscopic magnetic storage of data. You better know how to apply Maxwell's Equations to understand how the information flows among all those microscopic components without getting totally lost in cross talk, reflections and other capacitive and inductive effects. After all that you would have barely reached the bottom level of how computers really work.

Experts don't try to understand how something like a computer really works. An expert really understands a narrow sub topic within that, then has a general grasp of the surrounding sub topics and some vague idea about the challenges and results of the distant sub topics.



That is still more of a means than a goal.

How you learn assembly language depends a lot on why you want to learn it.

If you are (or intend to be) a software engineer, a very good reason to learn assembly language is to improve your abilities at designing and debugging software in high level languages. Even if you will never include any assembly source code in a final project, knowing how you could do that is very valuable for developing high level language code (especially C++).

If that is your purpose for leaning assembly language, then you should focus on learning a current CPU architecture (almost certainly X86-64) and on learning assembly programming in the form of functions called via a C interface.

Most books, tutorials, online advise, etc. on learning assembly focus on
1) Obsolete architectures, in theory because they are simpler, but really because they author's skills are obsolete.
2) Either whole programs in assembly or even stand-alone (from boot) code in assembly without benefit of an OS.
Many combine a little of (1) and (2) to focus on assembly programs in 16-bit x86 code to run under an MS-DOS emulator.

If you want to learn assembly in order to better understand current high level language software development, all the above is a massive waste.
For some other purposes for learning assembly, some of the above isn't as totally wasted, but it still isn't necessarily a good place to start.

For almost any reason for learning assembly, starting with a focus on assembly functions callable from C is a more gentle introduction without wasting time of useless side topics.



I haven't looked at any computer book in years, and when I did look at computer books I was never impressed.
You learn to program by programming, not by reading about it.

A good online tutorial would help, but I don't know of one. As I said above, most focus on a really stupid way of introducing assembly.



I'm not sure what that nonsense is supposed to mean. If you write a "pure" assembly program in Windows or Linux, that program can accidentally write to exactly the same things that a C or C++ program can accidentally write to, which does NOT include the OS.
When you (a beginner) write a program, be prepared to get the program wrong many times, including sometimes hanging it in a way that needs a task manager or kill command (etc.) to stop it. But that is just the program, not the session. MS-DOS is obsolete. A real OS protects the rest of your session from almost all programming accidents and protects itself from all of them (unless you abuse root privileges).



That is clearly a very popular idea among those giving advise for learning asm. It is still a very wrong idea. If you want to learn how to design heating systems, you don't begin by learning how to start a camp fire with a flint.

I tried to get my sons (while they were in Boy Scouts) to learn to start a camp fire with a flint. I also taught them quite a bit of computer programming and never any 16-bit x86 (much less 8085). Starting a camp fire with a flint is more worthwhile to learn today than 16-bit x86 asm.

Originally Posted by Thor_2.0 (Post 4878941)

ROFL! Ever addressed something out of the frame? Okay, granted, I'm from the era where you could "poke stuff" into the OS's memory space...
Anything above Assembler (C, C++, Java, whatever) is more or less governed by the OS, Assembly COULD bypass that... :)
Believe me, I've restarted enough to know ;)

Honesty demands that I confess that I've written my own Assembler in my time, nothing fancy as today's standards, a bare editor, that could load, edit and save (print as well) the source, and convert the code into bytes (yes, folks: BYTES, I'm that old) and pop 'em anywhere YOU wanted, including OS space...

Thor

Originally Posted by Thor_2.0 (Post 4878941)

Anything above Assembler (C, C++, Java, whatever) is more or less governed by the OS, Assembly COULD bypass that...

Originally Posted by jokar.mohsen (Post 4878805)

I want to Learn assembly langauge for Reverse engineering, Do you have any idea?

Originally Posted by johnsfine (Post 4879013)

I don't want to discourage learning asm. But reverse engineering methods that involve asm level work are an enormous amount of effort (even after you are an asm expert) for very little benefit, and even then much of the benefit would likely be illegal.

If you still want to learn asm for reverse engineering, then the choice of architecture is determined by what you want to reverse engineer. Also the choice of what approach you take to asm is influenced by what you want to reverse engineer.

If you want to reverse engineer any kind of ordinary programs, then you need to start with learning how to write asm functions callable from C (as I suggested earlier).

Some asm tutorials start from boot code, which is a very specialized topic and useless if you want to reverse engineer anything other than boot code.

Most other asm tutorials start with tiny whole programs, which also involves a lot of specialized, but otherwise useless, information. Before you understand those topics, you might imagine reverse engineering whole programs requires that knowledge. But it actually doesn't. The techniques used when the whole program must be asm don't appear anywhere in the compiled code when the main program is in a high level language. Something similar might appear in the compiled code of the basic system .so or .a files (.lib or .dll in Windows) the executable was linked against. But you don't need to reverse engineer those. You have their C source code.

Originally Posted by jokar.mohsen (Post 4879025)

I want to do Malware analysis, Do you have any suggestion?