I want to generate x86 assembly for a compiler course I have this semester.
My problem is that my only experience was a long time ago with 8086 assembler and I remember nothing.
I am looking for resources that have examples that will work with gcc(as) in order to test them.
My favourite documentation links:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
http://ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
Please, take note of the Related links section at the lower-right of this very screen, as well
there is a nice 8088/86 emulator pcemu, I have a fork of it where I removed the bios and dos calls leaving a processor emulator for learning 8088/86. use nasm as an assembler and http://github.com/dwelch67/pcemu_samples or some other pcemu or similar simulator (where you can get good visibility into what is going on, printing each instruction in execution order for example).
If you didnt mean 8086 and meant the modern/current x86/IA processors, then pcemu wont work you need something like qemu (little to know visibility).
Related
I am developing an algorithm that uses ARM Neon instructions. I am writing the code using assembler file (.S and no inline asm).
My question is that what is the best way for debugging purpose i.e. viewing registers, memory, etc.
Currently, I am using Android NDK to compile and my Android phone to run the algorithm.
Poor man's debug solutions...
You can use gdb / gdbserver to remotely control execution of applications on an Android phone. I'm not giving full details here because they change all the time but for example you can start with this answer or make a quick search on Internet. Learning to use GDB might seem to have a high steep curve however material on web is exhaustive. You can easily find something to your taste.
Single-stepping an ARM core via software tools is hard that's why ARM ecosystem is full of expensive tools and extra HW equipment.
Trick I use is to insert BRK instructions manually in assembly code. BRK is Self-hosted debug breakpoint. When core sees this instruction it stops and informs OS about situation. OS then notifies debugger about the situation and passes control to it. When debugger gets control you can check contents of registers and probably even make changes to them. Last part of the operation is to make your process continue. Since PC is still at our break point instruction what you must do is to increase PC, set it to instruction after BRK.
Since you mentioned you use .S files instead of .s files you can utilize gcc to do preprocessing / macro work. This way enabling, disabling BRK might become less of an issue.
Big down side of this way of working is turnaround time. If there is a certain point that you want to investigate with gdb you must make sure there is a BRK instruction there and this will probably require another build/push/debug cycle.
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
I am a complete newbie to the ARM world. I need to be able to write C code, compile it, and then download into an ARM emulator, and execute. I need to use the GCC 4.1.2 compiler for the C code compilation.
Can anybody point me in the correct directions for the following issues?
What tool chain to use?
What emulator to use?
Are there tutorials or guides on setting up the tool chain?
building a gcc cross compiler yourself is pretty easy. the gcc library and the C library and other things not so much, an embedded library and such a little harder. Depends on how embedded you want to get. I have little use for gcclib or a c library so roll your own works great for me.
After many years of doing this, perhaps it is an age thing, I now just go get the code sourcery tools. the lite version works great. yagarto, devkitarm, winarm or something like that (the site with a zillion examples) all work fine. emdebian also has a good pre-built toolchain. a number of these places if not all have info on how they built their toolchains from gnu sources.
You asked about gcc, but bear in mind that llvm is a strong competitor, and as far as cross compiling goes, since it always cross compiles, it is a far easier cross compiler to download and build and get working than gcc. the recent version is now producing code (for arm) that competes with gcc for performance. gcc is in no way a leader in performance, other compilers I have used run circles around it, but it has been improving with each release (well the 3.x versions sometimes produce better code than the 4.x versions, but you need 4.x for the newer cores and thumb2). even if you go with gcc, try the stable release of llvm from time to time.
qemu is a good emulator, depending on what you are doing the gba emulator virtual gameboy advance is good. There are a couple of nds emulators too. GDB and other places have what appear to be ARMs own armulator. I found it hard to extract and use, so I wrote my own, but being lazy only implemented the thumb instruction set, I called mine the thumbulator. easy to use. Far easier than qemu and armulator to add peripherals to and watch and debug your code. ymmv.
Hmmm I posted a similar answer for someone recently. Google: arm verilog and at umich you will find a file isc.tgz in which is an arm10 behavioural (as in you cannot make a chip from it therefore you can find verilog on the net) model. Which for someone wanting to learn an instruction set, watching your code execute at the gate level is about as good as it gets. Be careful, like a drug, you can get addicted then have a hard time when you go back to silicon where you have relatively zero visibility into your code while it is executing. Somewhere in stackoverflow I posted the steps involved to get that arm10 model and another file or two to turn it into an arm emulator using icarus verilog. gtkwave is a good and free tool for examining the wave (vcd) files.
Above all else you will need the ARM ARM. (The ARM Architectural Reference Manual). Just google it and find it on ARM's web site. There is pseudo code for each instruction teaching you what they do. Use the thumbulator or armulator or others if you need to understand more (mame has an arm core in it too). I make no guarantees that the thumbulator is 100% debugged or accurate, I took some common programs and compared their output to silicon both arm and non-arm to debug the core.
Toolchain you can use Yagarto http://www.yagarto.de/
Emulator you can use Proteus ISIS http://www.labcenter.com/index.cfm
(There is a demo version)
and tutorials, well, google them =)
Good luck!
I'm writing a compiler that converts source code (written in a small imperative programming language) to Intel AT&T 32-bit assembler.
I tend to spend a lot of time debugging, because of nasty offset-mistakes etc. in the generated code, and I would like to know if anyone knows of a tool to "walk through" the generated assembler code step-by-step, visualizing what's on the stack etc.
I use Ubuntu Linux as my development platform, and I'm comfortable with the terminal -- a GUI-program would be nice though. Does it exist? Or is there a good reason it doesn't (maybe the problem isn't so straightforward..?)
If you have good ideas for approaching debugging tasks in assembly code, I'll be glad to hear from you!
I like EDB (Evan's Debugger) on Linux. It has a nice, easy-to-use, QT4-based GUI. Its developer's goal is to make it similar to OllyDbg. And it's being actively maintained:
EDB on FreshMeat
I'm pretty sure it's installable through Synaptic on Ubuntu as well. Enjoy!
Is the end result of the compile process something that you can actually execute, and therefore examine in a debugger? If so the Data Display Debugger (ddd) might be useful.
My experience with debuggers such as Olly and EDB is quite sparse, so I wasn't able to solve my problem with those. I ended up
scattering calls around to a Debug function in the source code, nailing down bad register values
letting the compiler output HTML-formatted code with useful metadata for different iterations in the liveness analysis etc.
Okay. I want to learn how to assemble programs on my Mac (Early 2009 MBP, Intel Core 2 Duo). So far, I understand only that Assembly languages are comprised of direct one-to-one mnemonics for CPU instructions. After some Googling, I've seen a lot of terms, mostly "x86" and "x86_64". I've also seen MASM, NASM, and GAS, among others.
Correct me if I'm wrong:
x86 and x86_64 are instruction sets. If I write something using these instruction sets (as raw machine code), I'm fine so long as my program stays on the processor it was designed for.
NASM, MASM, and GAS are all different assemblers.
There are different Assembly languages. There's the AT&T syntax and the Intel syntax, for example. Support for these syntaxes differ across assemblers.
Now, questions:
As a Mac user, which instruction sets should I be concerned about?
Xcode uses GCC. Does this mean it also uses GAS?
If it does use GAS, then should I be learning the AT&T syntax?
Is there a book I can get on this. Not a tutorial, not a reference manual on the web. Those things assume to much about me; for example, as far as I know, a register is just a little bit of memory on the CPU. That's how little I really know.
Thanks for your help.
If you want to learn assembly language, start with the x86 instruction set. That's the basic set.
A good book on the subject is Randall Hyde's the Art of Assembly Language, which is also available on his website. He uses a high-level assembler to make things easy to grasp and to get going, but deep down it uses GAS.
I don't believe that XCode comes with any assembler, but you can for example find GAS in MacPort's binutils package.
If you just want to make programs on your Mac and you're not that interested in the life of all the bits in the CPU, you're much better off with a more high-level language like Python or Ruby.
"I'm fine so long as my program stays on the processor it was designed for." Not really. In many cases, assembler programs will also make assumptions about the operating system they run on (e.g. when they call library functions or make system calls). Otherwise, your assumpptions are correct.
Onto questions:
Current Macs support both x86 and x86-64 (aka AMD64 aka EM64T aka Intel64). Both 32-bit and 64-bit binaries can be run on recent systems; Apple itself ships its libraries in "fat" (aka "universal") mode, i.e. machine code for multiple architectures.
Use "as -v" to find out what precise assembler you have; mine reports as "Apple Inc version cctools-698.1~1, GNU assembler version 1.38". So yes, it's GAS.
Yes.
https://stackoverflow.com/questions/4845/good-x86-assembly-book
I'll answer the first question:
Macs use Intel chips now, and modern processors are 64-bit.