ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
...
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.
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).
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...
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.