Slashdot Mirror
x86 Assembly on Mac OS X
Quicksilver31337 asks: "I am currently taking an Assembly course which requires that I be able to compile ASM for the intel x86; however, I am stubbornly a Mac user. Having no desire to switch from my Powerbook, what can I do to work with, compile, and run x86 ASM short of running VirtualPC?" While Mac OS X does use gcc and its associated tool-chain, an old Slashdot discussion seems to imply that cross-compiling is better under OpenDarwin than Mac OS X. Has anyone tried cross-compiling under both operating systems? If so, what suggestions on setting up a working tool-chain do you have?
Get NASM (Netwide Assembler) and DOSBox or Bochs (x86 emulators).
Why not use bochs? It's open, free, and if you're using assembly, you won't need to worry about speed issues.
Your only real option is to get access to real x86 hardware, either by purchasing a junker Pentium box for $50 on eBay, or by getting a shell on a non-Mac-loving friend's machine. You will probably do better off having your own box, however, as it will give you direct access to video and other such things.
Like these people:
http://www.testdrive.hp.com/
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
You're right. You are flamebait. Should've followed your instincts.
Your response:
* ignores the posters question.
* offers no insight
* offers no work-arounds or solutions
* doesn't explain anything at all
* serves only to put the poster beneath you.
Sounds like flamebait to me...
An emulator is perfectly fine for a class. He could also get a shell account (http://www.testdrive.hp.com/). He could pick up a cheap x86 box. Etc.
But you fail to mention any of these and prefer instead to insult the poor guy.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
What my esteemed colleague is trying to say is, ASM is a language in which you give the chip specific commands. You tell the registers what to hold, what to do with what they hold, etc. For every ASM line of code there is only one machine language command created, unlike the potential hundreds created for a line of C. Taking a program that is written at that level and then allowing some emulator to guess at what you mean and how that is done on a completely different architecture makes no sense. You create a series of commands for the computer to run and then give it to an application that changes the commands to something else, in effect running a completely different program. It is just wasted time.
Of course one option you have is to just use the school's computer lab.
This signiture copied from somewhere.
I took a required X86 ASM course, and I used Mac OS X to do it. I wouldn't, however, run XP while coding ASM... it's just too slow on my G4 powerbook. Try DOS instead. Running MASM (ASM linker/compiler) under DOS is pretty speedy. Since Microsoft bought Virtual PC, it's hard to find a copy of VPC that doesn't include Windows (for way more money than Connectix sold it for), but you can get it at academicsuperstore.com for $119 without an OS. It worked well for me, and I didn't have any inconsistencies between running it on my Mac and running it on native x86 hardware.
She loves me: 09F911029D74E35BD84156C5635688C0 She loves me not: 09F911029D74E35BD84156C5635688BF
Nope.
Wine - Wine Is Not an Emulator.
(it doesn't interpret the x86 instructions , i.e. it works on x86 only)
--
My stuff
First, install QEmu. (I prefer to install it through DarwinPorts)
Then download a x86 Linux Live CD ISO, for example Knoppix.
Then:
$ qemu -cdrom knoppix.iso -boot d
Simple as that. Networking will work out of the box.
You can also install Debian on a virtual harddrive using:
$ dd if=/dev/zero of=sarge.hdimage bs=1000000 count=2000
$ qemu -hda sarge.hdimage -cdrom debian-netinst.iso -boot d
When installed, start QEmu with:
$ qemu -hda sarge.hdimage
Even better, after installation, copy the kernel and the initrd to your Mac (using sftp) and start qemu with:
$ qemu -hda sarge.hdimage -kernel kernel-file -initrd initrd-file -append "root=/dev/hda1 console=ttyS0,38600" -nographics
Then you will get the console on a virtual serial port (which is your current terminal window) and it doesn't have to emulate any graphics at all.
My other account has a 3-digit UID.
...and performs a bit better than Bochs. Install a smallish distro like Crux. QEMU also is supposed to support Windows 95/98/ME/2K but Bochs will probably prove to be more compatible. Don't expect speed demon performance and you'll be OK.
AC
You can't cross-compile assembly because it is designed for the target platform from the start.
..
what? of course you can cross-compile assembly. assembly is just another language - you can teach any computer that language.
as86/bin86 can be compiled under OSX. write your code on your powerbook, compile, send it to a real PC for testing/running
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
qemu now compiles and runs under OS X and you can install MS operating systems (DOS, Windows) inside it. This is certainly cheaper than virtual PC, and the speed is not too bad. For small programs that you are writing, emulated slowdown should not pose a significant problem.
This is almost certainly an intro course. He's not writing device drivers, he's going to be writing an implementation of dijkstra's algorithm or binsort or matrix arithmetic or something. I doubt he's going to have to analyze pipeline and branch prediction behavior either. So just throw it into an emulator, it'll be fine.
Your prof sincerely will NOT CARE that you used virtualPC or whatever, as long as you did the assignment. He WILL care if you're some whiny fanboy who can't stop moaning about how kludgy and crocky the x86 architecture is and how you sing love songs to your powerpc mac every night and how you had to condescend to use an emulator only IF this dinosaur of a professor who stoops so low to use this architecture might deign to look up to your lofty height and permit you to use an emulator blah blah. Just use the damn emulator and hand in the assignment. Chances are he won't notice, and if he does, then go buy a cheap old PC and get on with life.
I am no longer wasting my time with slashdot
While Mac OS X does use gcc and its associated tool-chain, an old Slashdot discussion seems to imply that cross-compiling is better under OpenDarwin than Mac OS X.
And what does that have to do with the price of tea in china?
We're talking about Assembly here...you wouldn't use gcc.. you'd use GAS (which is awful).
NASM will compile on OSX, but it uses AT&T syntax, rather than intel syntax.
Odds are good that you're going to be learning Intel syntax.
AT&T syntax: movl %eax, %ebx
Intel syntax: mov ebx, eax
Exactly as easy as it is to crash an x86 with C. A real operating system (implied in "shell account", I think) prevents user programs from crashing the whole computer, regardless of the language the program was written in -- in fact, it doesn't care about languages, because all it sees is the resulting executables and libraries anyways, which might as well be assembler.
It's true enough that it's easy to write a program that crashes in assembler, but that's true of any other language, too.
If the OP is writing boot loaders, kernels, or any other "raw machine" code, then a shell account is certainly inappropriate and he should get real hardware to run his code on. If, as seems more likely, it's just "how to write some simple programs in assembler", a shell account with appropriate tools will work just fine.
... but my university has a collection of Linux machines that you can SSH into for various uses, including development tasks. Any "decent" university (no offense intended), I think, would have a similar configuration.
What do you mean, "how that architecture REALLY" responds?" The whole point of an "architecture" is that there can be more than one implementation of said architecture. AMD and Intel provide hardware implementations of the x86; VirtualPC, bochs, et al. provide software implementations of it. Differences amongst those different implementations come down to either unspecified parts of the architecture, or bugs, be those bugs in hardware or software.
Bochs is every bit as real an implementation of the x86 as a Pentium 4. In the outrageously unlikely event that bochs doesn't run this guy's assembly code correctly, he should report a bug, just as he would do in the even more outrageously unlikely event that an Intel processor runs his code wrong.
I would assume that if the emulator can load an entire operating system then simple, first-year ASM isn't going to a problem here. He's writing "Hello, world.", not a SMP VM system!
My other car is first.
As a Mac user who has contributed to a popular assembly language text book, I can say with some authority that VirtualPC will get you by pretty well. Some of the advanced terminal functions will fail if you're not it DOS, but they'll work better under VPC w/ DOS than a real PC and XP.
I do C/C++ cross compilation from Mac OS X to Win32 all the time, but haven't done it with assembly code.
I use both gcc and CodeWarrior, and generally haven't had any problems with either.
I have OS X binaries for Win32 gcc 3.3.2 compilation (using mingw32) available here as a torrent