CS 211: Assignment 3
Why you need this stuff

Introduction

Seldom does anybody code an entire program in assembly any more. While it’s still possible to do so, the majority of a program is typically written in a high-level language such as C, C++, or Java, and only the parts that require high speed or low code size are written in assembly language.

For this assignment, you’ll need to write a simple C program and a few simple assembly-language functions, then combine the two into a single executable file. This requires you to understand how functions are called, and requires you to have at least some vague understanding of the linking process.

You’ll need to work on Intel Linux/Cygwin machines to compile and run this, so if you don’t have a personal system with these features, you’ll need to use the iLab machines. The linked page has directions on how to set up an account, if you don’t already have one.

Specifics

The C portion of the program will need to demonstrate the difference between little- and big-endian encodings of numbers. To do this, it must take in one or more numbers at the command line; for each of these numbers, it must print out

• the hexadecimal form of the number
• the hexadecimal form of the number with its endianness swapped, and
• the decimal form of the endianness-swapped number.

You must create two assembly functions for this assignment:

• writeHexASCII writes a doubleword integer into a buffer as an 8-digit hexadecimal ASCIZ string. There are easy and hard ways to do this on Intel machines. Don’t forget the NUL at the end of the string.
  Prototype: void writeHexASCII(char *buffer,unsigned number);
• swapEnds reverses the bytes in a doubleword integer; that is, the number 0x12345678 should become 0x78563412 and vice versa. There are easy and hard ways to do this on Intel machines.
  Prototype: unsigned swapEnds(unsigned x);

Your C code must call writeHexASCII to generate the hexadecimal strings for its output, and it must call swapEnds to reverse endianness of each number. You may use printf to write the decimal form of the number, or to write the hexadecimal strings. Your C code must be valid ANSI C, as usual.

Your assembly code shouldn’t make calls to any outside functions, and it should be runnable on any 80486 or 80386 CPU in 32-bit protected mode. (I.e., precisely the environment we’ve used in class.)

You can write your assembly code in NASM or AT&T format; if it’s NASM, end your assembly file in .asm, and if it’s AT&T, end your file in .S (note the capital S).

Your output should have the following form:

By the by, don’t try to just compile some C code and hand it in. We can always tell. We can always tell.

Help

• To compile a NASM-format assembly source, you can run

  $ nasm -felf -o filename.o filename.asm

  The -felf tells NASM to use the ELF object file format, which you’ll need in order to link in your C code.
• To compile an AT&T-format assembly source, you can run

  $ gcc -c filename.S

  This will write an ELF object file for filename.s to filename.o, just like the invocation of NASM.
• To link together object files into an executable file, run

  $ gcc -o binary_filename object1.o object2.o ...

  You can also pass C or AT&T-format assembly files along with the object files on the command line, and GCC will automatically compile/assemble them for you before linking them.
• Your assembly file should start with the following prologue:

  ; ...for NASM format:

  section .text

  bits 32

  global writeHexASCII

  global swapEnds

  /* ...for AT&T format: */

  .text

  .code32

  .globl writeHexASCII

  .globl swapEnds

  These directives tell the assembler to put your assembly code in with the rest of the code (in the .text section), that you’re coding for a processor running in 32-bit mode, and that you want other modules to be able to see writeHexASCII and swapEnds.
• You shouldn’t need any header files in your C code, but you will need to prototype writeHexASCII and swapEnds if you want to call them.
• If you compile on Cygwin, you might need to prefix names in your assembly files with an underscore (i.e., _writeHexASCII instead of writeHexASCII) because of DOS traditions. Your C code will refer to the assembly label _writeHexASCII as just writeHexASCII. (If you’re not sure, make one of each label before the function and export both of the underscored ones as well.)

AT&T format

This is a horrible format for assembly language, but one that’s quite common, and it would behoove you to gain some familiarity with it. (It’s also useful if you want to integrate assembly code into C source code for GCC, or if you like sharing header files between C and assembly.)

There are a few big differences between AT&T and Intel/NASM formats:

• In AT&T, you have to prefix registers with % (e.g., %eax, %bh) and immediate values with $ (e.g., $4 or $label). Memory-indirect values that would have been [label] or [5] in NASM are just label or 5 in AT&T, so be very careful about this!
• There’s an exception to the last rule for jumps. If you jump normally to a label, you can just say jmp label or jb label. By default these jumps will use IP-relative addressing. If you want to jump directly to a value, like 5, %ecx, or 4(%ebp), you need to prefix the operand with *, for jmp *5, call *%ecx, or jmp *4(%ebp). You shouldn’t need to do absolute jumps in this assignment.
• In NASM, you can say things like [eax+2*ebx+4] and it’ll know what you’re talking about. In AT&T, you have to know precisely how each component of an indirection works.

  NASM	AT&T
  [label]	label
  [eax]	(%eax)
  [eax+foo]	foo(%eax)
  [eax+ebx]	(%eax,%ebx)
  [eax+ebx+foo]	foo(%eax,%ebx)
  [eax+4*ebx]	(%eax,%ebx,4)
  [eax+4*ebx+foo]	foo(%eax,%ebx,4)

• Operand lists are reversed in AT&T from what they are in NASM. This means that instead of DEST,SRC, you have SRC,DEST ordering. This will screw you up badly if you aren’t careful! Also remember that, since the operands are reversed, CMP behaves differently. The following two sequences of code are equivalent:

  NASM	AT&T
  cmp a,b jbe x	cmp b,a jbe x

  Both of them perform the jump if a≤b.
• In NASM, you can create ambiguous instruction codings like MOV [dest],5 that you clear up by specifying an operation size explicitly (MOVE BYTE [dest],5 or something similar). In AT&T, you generally need to specify the operation size with a suffix on the instruction mnemonic (movb $5,dest). The suffixes are:

  b	Integer byte
  w	Integer word
  l	Integer doubleword (“longword”)
  d	A pair of words that make a doubleword (e.g., DX:AX), or a pair of doublewords that make a quadword (e.g., EDX:EAX)
  q	A single integer quadword value. Until the later x86en, this was only supported by the FPU.
  s	A single-precision real (float in C)
  l	A double-precision real (double in C)
  t	An 80-byte temporary real

• Because of these delightful suffixes, certain instructions change name:

  NASM/Intel	AT&T
  stosb, stosw, stosd	stosb, stosw, stosl
  movsb, movsw, movsd	movsb, movsw, movsl
  lodsb, lodsw, lodsd	lodsb, lodsw, lodsl
  cmpsb, cmpsw, cmpsd	cmpsb, cmpsw, cmpsl
  scasb, scasw, scasd	scasb, scasw, scasl
  movzx ax,al	movzbw %al,%ax
  movzx eax,ax	movzwl %ax,%eax
  movzx eax,al	movzbl %al,%eax
  movsx ax,al	movsbw %al,%ax
  movsx eax,ax	movswl %ax,%eax
  movsx eax,al	movsbl %al,%eax
  cbw, cwde, cwd, cdq	cbtw, cwtl, cwtd, cltd

  You shouldn’t need many of these instructions, if any, for this assignment.
• Most assemblers have some way of separating assembler directives from actual machine instructions, and this way is generally by placing a period before the directive name. Most of the directives also have different names between AT&T and NASM. Here’s a translation table:

  Intel	AT&T
  global foo	.globl foo
  section foo	.section foo
  section .text	.text
  section .data	.data
  bits 32	.code32
  db 1,2,3	.byte 1,2,3
  dw 1,2,3	.word 1,2,3
  dd 1,2,3	.long 1,2,3
  db "A string!",13,10	.ascii "A string!\r\n"
  db "A string!",13,10,0	.asciz "A string!\r\n"

If you don’t already have NASM...

...then you’ll need to download and build it. The NASM Sourceforge site is here; grab a source-code tarball (.tar.gz or .tar.bz2) and put it in your home directory somewhere. (Don’t grab binaries or RPMs or anything—you either can’t run them or can’t use them easily.)

Assuming you’ve gotten nasm-2.00.tar.*, extract the contents of the tarball by running

Useful resources

• NASM reference
• Intel 386 programmer’s manual (has an instruction reference; this manual should look familiar!)
• AT&T syntax versus Intel syntax
• Using as (as is the GNU assembler, which is what you’ll use to assemble AT&T-format assembly.)