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.

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.

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.

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.

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.

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

Here's a command line I use to run 'qemu':

- can be truncated for a beginner to

.

Not a big deal.

'-m 256' means memory allocated for the VM in megabytes, the rest is pretty obvious.

Those who are interested in doing dangerous things in assembly and other languages may look up

kernel mode linux
.

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.

Will I need lots of lib32 packages?

I agree.

+1

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

That's quite an unpleasant metaphor...

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!

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

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.

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.

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.

You can.

Now imagine that by mistake your program in whatever language executes

and analyze the consequences. Don't try the command !

Never assume you won't make a mistake !