Share your knowledge at the LQ Wiki.
 Home Forums HCL Reviews Tutorials Articles Register Search Today's Posts Mark Forums Read
 LinuxQuestions.org How to learn ASM
 Programming This forum is for all programming questions. The question does not have to be directly related to Linux and any language is fair game.

Notices

 04-06-2010, 12:42 PM #151 MTK358 LQ 5k Club   Registered: Sep 2009 Posts: 6,443 Blog Entries: 3 Original Poster Rep: How am I supposed to do 32-bit ASM when I am using a 64-bit CPU with a 64-bit OS on it?
04-06-2010, 12:47 PM   #152
Sergei Steshenko
Senior Member

Registered: May 2005
Posts: 4,481

Rep:
Quote:
 Originally Posted by MTK358 How am I supposed to do 32-bit ASM when I am using a 64-bit CPU with a 64-bit OS on it?
Your 64 bits CPU and 64 bits OS are still able to run 32 bits applications natively - not in emulation mode. And that was my point. x86_64 is an extension, not a replacement.

FWIW, for years only 32 bits Adobe FLASH existed, and it was used on 64 bit Linuxes which for that reason used 32 bits version of Firefox.

 04-06-2010, 12:53 PM #153 Sergei Steshenko Senior Member   Registered: May 2005 Posts: 4,481 Rep: To MTK358 - in addition to the above, you can, for example, use QEMU or probably VirtualBox and inside either of the VMs run a pure 32 bits Linux distro. And, by the way, it's a safer way - because in assembly it's much easier to screw up big. Just always have a spare copy of VM image around - whatever is the screwup, you just in the worst case discard the screwed up image an start anew - a matter of several minutes.
04-06-2010, 01:17 PM   #154
johnsfine
Guru

Registered: Dec 2007
Distribution: Centos
Posts: 5,180

Rep:
Quote:
 Originally Posted by Sergei Steshenko Your 64 bits CPU and 64 bits OS are still able to run 32 bits applications natively - not in emulation mode.
Correct. You can run 32 bit programs on almost any X86_64 Linux with no special action at run time. It just works.

The issue (see earlier in this thread) is that in blindly following a 32 bit asm tutorial you would incorrectly compile / assemble / link code as 64 bit that the tutorial assumes is 32 bit.

If you aren't working blindly, it is trivial to add the appropriate compile, assemble and maybe link option to tell each tool to work on 32 bit code.

04-06-2010, 01:24 PM   #155
Sergei Steshenko
Senior Member

Registered: May 2005
Posts: 4,481

Rep:
Quote:
 Originally Posted by johnsfine Correct. You can run 32 bit programs on almost any X86_64 Linux with no special action at run time. It just works. The issue (see earlier in this thread) is that in blindly following a 32 bit asm tutorial you would incorrectly compile / assemble / link code as 64 bit that the tutorial assumes is 32 bit. If you aren't working blindly, it is trivial to add the appropriate compile, assemble and maybe link option to tell each tool to work on 32 bit code.
And that's why I suggest to use a VM - on the beginning to "forget" about 64 bits and related issues altogether - WRT assembly.

04-06-2010, 02:42 PM   #156
johnsfine
Guru

Registered: Dec 2007
Distribution: Centos
Posts: 5,180

Rep:
Quote:
 Originally Posted by Sergei Steshenko And that's why I suggest to use a VM - on the beginning to "forget" about 64 bits and related issues altogether - WRT assembly.
I think that is overkill for a small problem.

There is the extra effort to set up a whole 32 bit Linux system inside a VM in your 64 bit Linux system. Then there is the ultimately larger amount of extra work to use it.

I think it would be much more convenient for your asm work to just be in ordinary files in ordinary directories of your real system. So you could edit or print or upload/download etc. all with the tools on your real system.

I'm thinking about things like copy/paste your asm text files and/or assembler error messages and/or execution results to/from some forum and/or tutorial accessed in your main browser session. I don't know enough about VM's to be sure, but I expect that is a lot easier with everything in one Linux system, rather than asm work in a VM while the main browser session is probably in the main system.

Quote:
 Originally Posted by Sergei Steshenko because in assembly it's much easier to screw up big.
That is the heart of the disagreement. If true, that might justify the VM.

But in fact, asm barely makes it easier to seriously screw up the process the asm is running in. It does not make it easier to screw up the Linux system that process is running under.

Linux has enough protection for keeping a screwed up process from screwing up the system.

I'm sure you could write a resource hog that messes up the system. I'm sure you could write a program that deletes everything it has rights to. Such programs are possible in asm. But they are easier to do by accident in C++ than in asm and even easier to do by accident in bash than in C++.

So experimenting with asm is not any extra reason to go to absurd lengths to defend your system from your programming errors.

I also disagree with the 32 vs. 64 bit choice. It's unfortunate you can't find a decent X86_64 tutorial. But I think blindly following a 32 bit tutorial is a waste of time. You want to make sure you understand as you go. Making reasonable changes (even as big as consistently switching X86 to X86_64) as you follow the tutorial may force you to understand each step rather than just follow it.

I think in this thread I already gave enough info to tell you how to write working X86_64 code from any simple X86 example.

But even if you really prefer to stay closer to an X86 tutorial, a few consistent command line switches at build time are a lot simpler than using a VM.

Last edited by johnsfine; 04-06-2010 at 02:47 PM.

1 members found this post helpful.
04-06-2010, 02:53 PM   #157
Sergei Steshenko
Senior Member

Registered: May 2005
Posts: 4,481

Rep:
Quote:
 Originally Posted by johnsfine ... So experimenting with asm is not any extra reason to go to absurd lengths to defend your system from your programming errors. ...
In the end it's interesting to do really dangerous things in assembly - like direct access to devices, real <-> protected modes switching, boot loader modifications, etc.

So, metaphorically speaking, in the final end programming in assembly is like touching completely skinned, but still living, CPU body.

04-06-2010, 03:04 PM   #158
johnsfine
Guru

Registered: Dec 2007
Distribution: Centos
Posts: 5,180

Rep:
Quote:
 Originally Posted by Sergei Steshenko In the end it's interesting to do really dangerous things in assembly - like direct access to devices, real <-> protected modes switching, boot loader modifications, etc. So, metaphorically speaking, in the final end programming in assembly is like touching completely skinned, but still living, CPU body.
I expect you know that you can't do most of those dangerous things from a user mode process in Linux, even in asm.

But I think you said the above in a way confusing to anyone who doesn't know that, especially in apparent response to a debate about the need for a VM when trying user mode Linux 32 bit asm tutorials (plus hopefully new code building from there).

 04-06-2010, 03:26 PM #159 Sergei Steshenko Senior Member   Registered: May 2005 Posts: 4,481 Rep: Here's a command line I use to run 'qemu': Code: /mnt/sdb8/sergei/AFSWD_debug/install/qemu-0.10.6/binsh/qemu -m 256 -hda os_image.vmdk -cdrom /dev/cdrom -kernel-kqemu -tftp pwd -usb -usbdevice tablet -localtime & - can be truncated for a beginner to Code: /mnt/sdb8/sergei/AFSWD_debug/install/qemu-0.10.6/binsh/qemu -m 256 -hda os_image.vmdk -cdrom /dev/cdrom . Not a big deal. '-m 256' means memory allocated for the VM in megabytes, the rest is pretty obvious.
 04-06-2010, 03:29 PM #160 Sergei Steshenko Senior Member   Registered: May 2005 Posts: 4,481 Rep: Those who are interested in doing dangerous things in assembly and other languages may look up kernel mode linux .
 04-06-2010, 03:32 PM #161 smeezekitty Senior Member   Registered: Sep 2009 Location: Washington U.S. Distribution: M\$ Windows / Debian / Ubuntu / DSL / many others Posts: 2,303 Rep: I agree with johnsfine. You cannot f**k your system any worse in ASM then in C. Basically worst case is you have to reboot.
04-06-2010, 03:38 PM   #162
Sergei Steshenko
Senior Member

Registered: May 2005
Posts: 4,481

Rep:
Quote:
 Originally Posted by smeezekitty I agree with johnsfine. You cannot f**k your system any worse in ASM then in C. Basically worst case is you have to reboot.
The amount of possible damage is reversely proportional to experience.

So, it's not a matter of assembly vs "C" specifically, it's a matter of (lack of) experience.

A beginner can just use a different user ID for assembly experiments, then (if that user ID is not 'root') no real damage can be done.

04-06-2010, 04:19 PM   #163
MTK358
LQ 5k Club

Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Original Poster
Rep:
Quote:
 Originally Posted by johnsfine Correct. You can run 32 bit programs on almost any X86_64 Linux with no special action at run time. It just works. The issue (see earlier in this thread) is that in blindly following a 32 bit asm tutorial you would incorrectly compile / assemble / link code as 64 bit that the tutorial assumes is 32 bit. If you aren't working blindly, it is trivial to add the appropriate compile, assemble and maybe link option to tell each tool to work on 32 bit code.
Will I need lots of lib32 packages?

Quote:
 Originally Posted by johnsfine I think that is overkill for a small problem. There is the extra effort to set up a whole 32 bit Linux system inside a VM in your 64 bit Linux system. Then there is the ultimately larger amount of extra work to use it.
I agree.

Quote:
 Originally Posted by johnsfine Linux has enough protection for keeping a screwed up process from screwing up the system.
+1

The only time I EVER saw a Linux system crash is when I accidentally deleted the contents of the /boot directory!

Quote:
 Originally Posted by Sergei Steshenko touching completely skinned, but still living, CPU body
That's quite an unpleasant metaphor...

Quote:
 Originally Posted by johnsfine I expect you know that you can't do most of those dangerous things from a user mode process in Linux, even in asm. But I think you said the above in a way confusing to anyone who doesn't know that, especially in apparent response to a debate about the need for a VM when trying user mode Linux 32 bit asm tutorials (plus hopefully new code building from there).
I don't care for doing those kinds of things yet.

In fact just being able to call a function that does nothing would be amazing!

Quote:
 Originally Posted by Sergei Steshenko A beginner can just use a different user ID for assembly experiments, then (if that user ID is not 'root') no real damage can be done.
Why can't I use my own user account?

Anyway, I'm still noticing a lot of philosophical disagreements between me and Sergei Steshenko. Maybe I should just go to another forum for my programming questions before anyone's feelings get hurt or a flame war starts, just in case. OTOH, the members of other forums will brobably be Windows programmers supporting µSoft tools who know nothing about Linux...

Last edited by MTK358; 04-06-2010 at 04:22 PM.

04-06-2010, 05:07 PM   #164
johnsfine
Guru

Registered: Dec 2007
Distribution: Centos
Posts: 5,180

Rep:
Quote:
 Originally Posted by MTK358 Will I need lots of lib32 packages?
If you follow my advice and call ordinary library functions from your asm code to do I/O (rather than direct Linux system calls) but you don't follow my advice on the 32 vs. 64 bit choice, then you would need some lib32 packages for your 32 bit asm code to link against.

If you do direct Linux calls, I don't think you need any lib32 packages. The assembler and linker would still be X86_64 programs themselves, so they have no need of any lib32 features, you are just taking advantage of the fact that the X86_64 assembler and
linker for a typical distribution were built with the ability to build X86 programs.

Quote:
 Why can't I use my own user account?
That was based on the theory that you are more likely to write some kind of recursive directory walk plus "rm *" program in a language you don't know than in one you do.

My estimate is that it is too unlikely to worry about.

Such programs are real hard to write in asm, including hard to write by accident.

Quote:
 I'm still noticing a lot of philosophical disagreements ... Maybe I should just go to another forum for my programming questions
It is easy to ignore someone if you really want to. I think the forum software can help you really ignore someone so they don't even distract you from reading what others write in the thread.

I understand that is an unsatisfying solution because others will still read the posts you are ignoring and even respond to them. I really do understand your desire to be able to share your choice to ignore someone. I sometimes find myself wanting the same. But hopefully you also understand that it would be wrong. (Anyway Jeremy made clear he isn't going to give us any "ban user X from my threads" feature). Also, hearing from someone with a different point of view isn't a bad thing. Even if it is unconvincing (or outright wrong) it still may help you think less narrowly.

Anyway, I think LQ is the best forum for your questions despite any distractions. So if you take drastic action, such as going to a forum with less helpful members, you are only punishing yourself.

Last edited by johnsfine; 04-06-2010 at 05:10 PM.

04-06-2010, 05:21 PM   #165
Sergei Steshenko
Senior Member

Registered: May 2005
Posts: 4,481

Rep:
Quote:
 Originally Posted by MTK358 ... Why can't I use my own user account? ...
You can.

Now imagine that by mistake your program in whatever language executes

Code:
\rm -rf /
and analyze the consequences. Don't try the command !

Never assume you won't make a mistake !