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?

Comments

DOSBox + NASM

[Anonymous Coward]

Get NASM (Netwide Assembler) and DOSBox or Bochs (x86 emulators).

Re:DOSBox + NASM

[fm6]

The Mac version of DOSBox is available here. Also handy for running old DOS games under 32-bit Windows, Linux, and of course Mac.

Re:DOSBox + NASM

[Anonymous Coward]

Are you kidding? Check out Qemu at http://www.freeoszoo.org/download.php. It's like 700% faster than Bochs. I successfully installed WinXP on my mac with qemu--something I'm not sure is possible with Bochs. I also find qemu easier to configure and use.

Emulation or new hardware...

[Paladin128]

Your two choices are emulation (like VirtualPC) or new hardware.

My advice is go to a computer show, buy an old, fully-functional 386, 486, or Pentium based machine, and install either DOS or Linux or *BSD. You could probably get one for less than $50.

Re:Emulation or new hardware...

[tverbeek]

For the love of Turing, get yourself an IA32 box.

Going to school is supposed to broaden your horizons (or in more mercenary terms: build up your resume), and that's not going to happen if you cling to your PowerBook like a life preserver. In my college years in the neolithic period I got exposed to TRS-80s (Z80 assembly), IBM PCs, DEC VAXen, a *nix box of some kind, and the C64 in my dorm room, and that diversity of experience made me a better geek... the kind who today is comfortable with OS X, MacOS, Windows, Linux, BSD, BeOS, EPOC, PalmOS, and just about anything else I might find in front of me.

Look, eventually your architecture of choice is going to die off or fade into irrelevancy. (And I'm not saying that because it's an Apple; they'll probably be around in 20 years, but they won't still be using OS X on PPC). You'll have to adapt. So you might as well start making yourself cross-platform now, before you end up as just a one-trick pony.

Well...

[and by]

Why not use bochs? It's open, free, and if you're using assembly, you won't need to worry about speed issues.

Re:Well...

[marmoset]

I've actually had better luck with QEMU than with Bochs. It seems a little easier to set up, at least.

Choice...

[Sparr0]

#3: get a shell account on an x86 machine.

Re:Choice...

[Atzanteol]

Like these people:

http://www.testdrive.hp.com/

Don't

[kalidasa]

I would think that if you want to take an assembly class for a particular architecture, you'd want to know how that architecture REALLY responds: no kind of emulation is going to guarantee you that knowledge. You're being too stubborn; get (or borrow) a cheap beige box to do the assembly work on and just rdc or vnc into it. Then turn around and sell it when you no longer need to do assembly.

Re:Don't

[ratboy666]

Oh boy,

"Half of learning assembly is testing it out on a *live* machine. You're not learning assembly if you're just using cross-assembling, and you're not *really* learning it if you're emulating."

In a word: wrong. In many ways.

First, emulation is *more* useful because more data can be (potentially) gathered during runs.

Second, being forced to cycle a power switch is "educational"?

Third, the student will *not* be required to know the COMPLETE ins-and-outs of the hardware (eg, register level access to an NVidia card) -- indeed, most programmers /even at the assembler level/ don't have this information.

Fourth, the information gained in an assembly class is /mostly/ of interest to people debugging. It is useful (while learning) to be able to access the "meta level" available in a good simulator.

Unless you can debug on a cycle level on your "AMD sempron" without adding an external ICE. If you /do/ use the hardware to learn machine level programming, I recommend the (more expensive than the machine) aquisition of a product known a "WinICE" (currently produced by CA... along with Windows -- and, no, a product like this does /not/ exist on Linspire).

Nope, this person would be best served by BOCHS with the built-in debug facility enabled. QEMU is a close second (except it isn't as "inspectable", but is faster). VMWARE pulls in around last, about the same as getting a "beige box PC".

Even /on/ the hardware itself, programmers were deploying simulators to illustrate machine level programming.

And, if you do run QEMU or BOCHS, you can run the tool-chain for x86 there as well (QEMU would be preferred, because the tools will simply integrate into the command-line and `make' correctly).

Ratboy

bochs

[Erik Greenwald]

I've had good luck usings bochs http://bochs.sourceforge.net/ for x86 on my powerbook. It's a little work getting the bochsrc set up just right, and installing an os on the disk image if you need one to support the code... (I've been dorking with os-less stuff...)

-Erik

Your only option

[wolf31o2]

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.

It Isn't Worth It

[American AC in Paris]

Use the appropriate tool for the task at hand. Either suffer through the course on lab computers or get your hands on an old x86 box for cheep/free/loansies. I'd bet my left shoe that trying to code ASM via emulated x86 on OS X will be ten times more painful than the ignominy of biting the bullet and working on something other than your architecture of choice.

I hate using anything other than my PowerBook these days, but I honestly can't see any good arguments for not just sucking it up and working with the most appropriate hardware for the task.

Some sound advice has already been given..

[ciroknight]

You've got the option of either Emulation or new hardware, as quoted by everyone on here. But there is probably a better way than both. Ask your teacher at your school if there's a box available in the IT department that's the correct archetecture. Like, for example, I am also a vehement mac user, and I had a project that required me to use assembly (mainly SSE-related things). Since I didn't know assembly for the PPC yet, I asked my professor and he said to get an account with the school's super computer. So I did, I wrote the software, and got an A on the project. Simple as that. VNC is your friend.

Re:You don't understand the problem

[WyerByter]

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.

QEMU

[Nagus]

Get the experimental OS X installer for QEMU. This will emulate an x86 processor plenty fast enough to do some assembly coding. Then you can install some GNU/Linux distribution with the tools you need. Or if you want to keep this lightweight, install FreeDOS and the NASM assembler.

Qemu.

[drdink]

First, a note to Cliff. Assembly has nothing to do with cross-compiling. When you write assembly for the PowerPC 970, it stays on the PowerPC 970. You can't cross-compile assembly because it is designed for the target platform from the start.

Now, what I would suggest you do is get a copy of QEMU. I assume you are familiar enough with Terminal and the shell prompt to get it working since you're stepping into the world of assembly, but if all else fails you can get QemuX or some other QEMU GUI off of VersionTracker.

Depending on what mode you're writing your assembly in, you'll need to install some sort of OS into QEMU. Some candidates are FreeDOS, MS-DOS, or even Linux. Use whatever your class is using. Emulators are very handy for writing assembly because you can debug the program at the "CPU" level, so when your program pukes you can get a better glimpse at what is going on. This is why many developers design inside of VMWare.

I hope this helps!

Re:Qemu.

[torpor]

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

Use Virtual PC

[douthat]

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.

Re:Try this

[noselasd]

Nope.
Wine - Wine Is Not an Emulator.
(it doesn't interpret the x86 instructions , i.e. it works on x86 only)

--
My stuff

You want QEMU!

[Per Wigren]

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.

Emulation and ASM

[Lycestra]

Back in my day, we had to learn MIPS assembly, and this was long after the era of MIPS processors being available on campus. Instead, we had to use the SPIM emulator to test our MAL code. It seemed to fit the professors needs, but I think the professor may have had a hand in writing it. (wisc.edu)

I'd say ask the professor what he/she thinks of using Bochs first. If they aren't totally against it, it should be fine. Freshman year, it felt like I was the only one in my CS course with linux at home, but my professor had no problem with it as long as my stuff worked on the sanctioned C compiler (in a *nix) we used in the labs. As long as it tested good on the machine it was tested on, it was fine. Heck, what if the professor is just going to use Bochs anyway?

Re:Emulation and ASM

[sakusha]

Jeez, back in my day, we had to learn IBM 360 Assembler, CPU time was so scarce, and punching cards was so tedious, we wrote it all on paper and stepped through all the code manually, writing down the contents of each register as it changed each time an instruction was executed. This is known as a "paper computer" and is not really so difficult, although it requires you to really KNOW the structure of the registers, and have detailed knowledge of what each operation does. And isn't that the POINT of studying assembler?

Here's my advice, you may hear lots similar

[biglig2]

Sweet Baby Jesus and the Orphans, if you don't want to use anything except a Mac, then go on a PowerPC assembler course!

Dear Auntie Slashdot,

I'm going on a course to learn how to stab people. But I don't like knives, nasty sharp things, I much prefer my sock full of spagetti. Can you suggest a way I can stab people with a sock full of pasta?

Also, I don't want to ride a bicycle, any way I can learn how to ride one while on a train?

etc. etc.

ummm yeah ..

[torpor]

coz assembly on a shell account, for a student, is going to be stable as hell.

not the best suggestion so far, i think. you know how easy it is to crash x86 with assembly?

what i do: use VirtualPC. like the article submitter, i am 100% devoted to my powerbook .. but there are definitely times when i need to run PC software. i have a WinXP image i regularly boot into to do compiles, and it works fine .. it may not be the fastest system around, but it sure gets the job done, and leaves me to my powerbook in peace .. in fact, i've never been such a happy windows user as i am, now able to freeze a machine and restore it to its 'last known working state' .. running winXP in a VM seems to be the only way to maintain sanity, anyway ...

Re:ummm yeah ..

[boneshintai]

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.

qemu

[caseih]

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.

virtualPC, bochs, qemu, all fine

[snorklewacker]

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.

Maybe I'm being too simple ...

[chris462]

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

Re:You don't understand the problem

[confused one]

That's funny... we test ALL of our low level code on an emulator BEFORE we try to run it on real hardware. The development platform is Win2k on x86. The emulation is run on the SAME platform. The target is Z80, AVR, PIC, 68040 or PowerPC, depending upon the product in question.

I'm a professional developers working for a manufacturer of precision instrumentation. I don't see any problems with what he's trying to do. Although, he'd be wise to test it on real hardware before giving it to the prof...

Do what Mac Zealots have always done...

[Lead Butthead]

Code the assignment in PPC assembly and hand that in. And insist PPC is a superior architecture to code for...

Re:Do what Mac Zealots have always done...

[Rich_Morin]

Or, more usefully, code each assignment up both ways and hand in both versions. You'll learn more about both architectures than you would from doing either one alone. And, if the professor is even a bit open-minded, you'll get extra credit for the work.

Re: "I am stubbornly a Mac user"

[Anonymous Coward]

You'll always be a user, and never an engineer, if you marry a platform.

I know quite a few engineers who used to work at Apple, and decided OS X wasn't a "Macintosh." Apple had other ideas. They're now writing Windows code.

I think the native platform for x86 is the best choice for x86 development. If you can't figure out how to use it, you have no reason to be studying software.

Horse nuggets.

[kma]

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.

Re:You don't understand the problem

[jrockway]

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!

Re:I'm not sure I understand the question

[hey!]

Oh, I see, thanks.

I feel sorry for the guy, even if he is a Mac bigot. I got to do my assembly programming class on a Vax, which is practically as easy as writing in C.

VPC is fine

[Monx]

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.

Reminds me of a letter I once read...

[NewOrleansNed]

Deer Mason's Guild,

I need to build a brick fireplace but I am a fervent hammer user. I realize that a hammer might not be the right tool to lay down the mortar, but I believe very strongly in the hammer and believe that ultimately, the trowel is an inferior tool designed only for trogladytes and people who actually know the definition of "trogladytes." What is the best way to use my hammer to accomplish my goal?

Signed,

Go Hammer, Go Hammer Go

Have gcc 3.3.2 win32 cross compiler

[ezavada]

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

My assembly course

[generationxyu]

...was in MIPS. I don't own a MIPS box, nor would it be easy for me to find one. It wasn't expected that we had one. We were expected to use spim/xspim/PCSpim. I ran xspim on my Mac and it was fine. The programs probably ran like a snail crawling through molasses in January in comparison to a real box, but I never noticed -- none of my programs took long enough to execute anyway.