LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
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

Reply
 
Search this Thread
Old 04-06-2010, 11:42 AM   #151
MTK358
LQ 5k Club
 
Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Original Poster
Rep: Reputation: 713Reputation: 713Reputation: 713Reputation: 713Reputation: 713Reputation: 713Reputation: 713

How am I supposed to do 32-bit ASM when I am using a 64-bit CPU with a 64-bit OS on it?
 
Old 04-06-2010, 11:47 AM   #152
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by MTK358 View Post
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.
 
Old 04-06-2010, 11:53 AM   #153
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
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.
 
Old 04-06-2010, 12:17 PM   #154
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,064

Rep: Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106
Quote:
Originally Posted by Sergei Steshenko View Post
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.
 
Old 04-06-2010, 12:24 PM   #155
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by johnsfine View Post
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.
 
Old 04-06-2010, 01:42 PM   #156
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,064

Rep: Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106
Quote:
Originally Posted by Sergei Steshenko View Post
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 View Post
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 01:47 PM.
 
1 members found this post helpful.
Old 04-06-2010, 01:53 PM   #157
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by johnsfine View Post
...
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.
 
Old 04-06-2010, 02:04 PM   #158
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,064

Rep: Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106
Quote:
Originally Posted by Sergei Steshenko View Post
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).
 
Old 04-06-2010, 02:26 PM   #159
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
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.
 
Old 04-06-2010, 02:29 PM   #160
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Those who are interested in doing dangerous things in assembly and other languages may look up

kernel mode linux
.
 
Old 04-06-2010, 02:32 PM   #161
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,227

Rep: Reputation: 170Reputation: 170
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.
 
Old 04-06-2010, 02:38 PM   #162
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by smeezekitty View Post
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.
 
Old 04-06-2010, 03:19 PM   #163
MTK358
LQ 5k Club
 
Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Original Poster
Rep: Reputation: 713Reputation: 713Reputation: 713Reputation: 713Reputation: 713Reputation: 713Reputation: 713
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 03:22 PM.
 
Old 04-06-2010, 04:07 PM   #164
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,064

Rep: Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106
Quote:
Originally Posted by MTK358 View Post
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 04:10 PM.
 
Old 04-06-2010, 04:21 PM   #165
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by MTK358 View Post
...
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 !
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASM or C++? Hb_Kai Programming 16 01-20-2010 09:12 AM
Is ASM dangerous? MrCode Programming 37 11-18-2009 08:29 AM
ASM x32 vs ASM x64 Tegramon Programming 3 02-27-2008 02:26 PM
I/O in ASM Mercurius Programming 10 11-16-2006 07:02 PM
ASM question zWaR Programming 2 06-26-2004 11:42 AM


All times are GMT -5. The time now is 08:15 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration