1
Hello, World of Assembly Language

To store larger values, the x86 uses a sequence of consecutive memory locations. Figure 1-5 shows how the x86 stores bytes, words (2 bytes), and double words (4 bytes) in memory. The memory address of each object is the address of the first byte of each object (that is, the lowest address).

1.9 Declaring Memory Variables in MASM

Although it is possible to reference memory by using numeric addresses in assembly language, doing so is painful and error-prone. Rather than having your program state, “Give me the 32-bit value held in memory location 192 and the 16-bit value held in memory location 188,” it’s much nicer to state, “Give me the contents of elementCount and portNumber.” Using variable names, rather than memory addresses, makes your program much easier to write, read, and maintain.

To create (writable) data variables, you have to put them in a data section of the MASM source file, defined using the .data directive. This directive tells MASM that all following statements (up to the next .code or other section-defining directive) will define data declarations to be grouped into a read/write section of memory.

Within a .data section, MASM allows you to declare variable objects by using a set of data declaration directives. The basic form of a data declaration directive is

label  directive ?

where label is a legal MASM identifier and directive is one of the directives appearing in Table 1-2.

The question mark (?) operand tells MASM that the object will not have an explicit value when the program loads into memory (the default initialization is zero). If you would like to initialize the variable with an explicit value, replace the ? with the initial value; for example:

hasInitialValue  sdword   -1

Some of the data declaration directives in Table 1-2 have a signed version (the directives with the s prefix). For the most part, MASM ignores this prefix. It is the machine instructions you write that differentiate between signed and unsigned operations; MASM itself usually doesn’t care whether a variable holds a signed or an unsigned value. Indeed, MASM allows both of the following:

     .data
u8   byte    -1    ; Negative initializer is okay
i8   sbyte   250   ; even though +128 is maximum signed byte

All MASM cares about is whether the initial value will fit into a byte. The -1, even though it is not an unsigned value, will fit into a byte in memory. Even though 250 is too large to fit into a signed 8-bit integer (see “Signed and Unsigned Numbers” in Chapter 2), MASM will happily accept this because 250 will fit into a byte variable (as an unsigned number).

It is possible to reserve storage for multiple data values in a single data declaration directive. The string multi-valued data type is critical to this chapter (later chapters discuss other types, such as arrays in Chapter 4). You can create a null-terminated string of characters in memory by using the byte directive as follows:

; Zero-terminated C/C++ string.
strVarName  byte 'String of characters', 0

Notice the , 0 that appears after the string of characters. In any data declaration (not just byte declarations), you can place multiple data values in the operand field, separated by commas, and MASM will emit an object of the specified size and value for each operand. For string values (surrounded by apostrophes in this example), MASM emits a byte for each character in the string (plus a zero byte for the , 0 operand at the end of the string). MASM allows you to define strings by using either apostrophes or quotes; you must terminate the string of characters with the same delimiter that begins the string (quote or apostrophe).

1.9.1 Associating Memory Addresses with Variables

One of the nice things about using an assembler/compiler like MASM is that you don’t have to worry about numeric memory addresses. All you need to do is declare a variable in MASM, and MASM associates that variable with a unique set of memory addresses. For example, say you have the following declaration section:

     .data
i8   sbyte   ?
i16  sword   ?
i32  sdword  ?
i64  sqword  ?

MASM will find an unused 8-bit byte in memory and associate it with the i8 variable; it will find a pair of consecutive unused bytes and associate them with i16; it will find four consecutive locations and associate them with i32; finally, MASM will find 8 consecutive unused bytes and associate them with i64. You’ll always refer to these variables by their name. You generally don’t have to concern yourself with their numeric address. Still, you should be aware that MASM is doing this for you.

When MASM is processing declarations in a .data section, it assigns consecutive memory locations to each variable.⁵ Assuming i8 (in the previous declarations) as a memory address of 101, MASM will assign the addresses appearing in Table 1-3 to i8, i16, i32, and i64.

Whenever you have multiple operands in a data declaration statement, MASM will emit the values to sequential memory locations in the order they appear in the operand field. The label associated with the data declaration (if one is present) is associated with the address of the first (leftmost) operand’s value. See Chapter 4 for more details.

1.9.2 Associating Data Types with Variables

During assembly, MASM associates a data type with every label you define, including variables. This is rather advanced for an assembly language (most assemblers simply associate a value or an address with an identifier).

For the most part, MASM uses the variable’s size (in bytes) as its type (see Table 1-4).

Later sections and chapters fully describe the proc, label, constant, and text types.

1.10 Declaring (Named) Constants in MASM

MASM allows you to declare manifest constants by using the = directive. A manifest constant is a symbolic name (identifier) that MASM associates with a value. Everywhere the symbol appears in the program, MASM will directly substitute the value of that symbol for the symbol.

A manifest constant declaration takes the following form:

label = expression

Here, label is a legal MASM identifier, and expression is a constant arithmetic expression (typically, a single literal constant value). The following example defines the symbol dataSize to be equal to 256:

dataSize = 256

Most of the time, MASM’s equ directive is a synonym for the = directive. For the purposes of this chapter, the following statement is largely equivalent to the previous declaration:

dataSize equ 256

Constant declarations (equates in MASM terminology) may appear anywhere in your MASM source file, prior to their first use. They may appear in a .data section, a .code section, or even outside any sections.

1.11 Some Basic Machine Instructions

The x86-64 CPU family provides from just over a couple hundred to many thousands of machine instructions, depending on how you define a machine instruction. But most assembly language programs use around 30 to 50 machine instructions,⁶ and you can write several meaningful programs with only a few. This section provides a small handful of machine instructions so you can start writing simple MASM assembly language programs right away.

1.11.1 The mov Instruction

Without question, the mov instruction is the most oft-used assembly language statement. In a typical program, anywhere from 25 percent to 40 percent of the instructions are mov instructions. As its name suggests, this instruction moves data from one location to another.⁷ Here’s the generic MASM syntax for this instruction:

mov    destination_operand, source_operand

The source_operand may be a (general-purpose) register, a memory variable, or a constant. The destination_operand may be a register or a memory variable. The x86-64 instruction set does not allow both operands to be memory variables. In a high-level language like Pascal or C/C++, the mov instruction is roughly equivalent to the following assignment statement:

destination_operand = source_operand ;

The mov instruction’s operands must both be the same size. That is, you can move data between a pair of byte (8-bit) objects, word (16-bit) objects, double-word (32-bit), or quad-word (64-bit) objects; you may not, however, mix the sizes of the operands. Table 1-5 lists all the legal combinations for the mov instruction.

You should study this table carefully because most of the general-purpose x86-64 instructions use this syntax.

This table includes one important thing to note: the x86-64 allows you to move only a 32-bit constant value into a 64-bit memory location (it will sign-extend this value to 64 bits; see “Sign Extension and Zero Extension” in Chapter 2 for more information about sign extension). Moving a 64-bit constant into a 64-bit register is the only x86-64 instruction that allows a 64-bit constant operand. This inconsistency in the x86-64 instruction set is annoying. Welcome to the x86-64.

1.11.2 Type Checking on Instruction Operands

MASM enforces some type checking on instruction operands. In particular, the size of an instruction’s operands must agree. For example, MASM will generate an error for the following:

i8 byte ?
    .
    .
    .
mov ax, i8

The problem is that you are attempting to load an 8-bit variable (i8) into a 16-bit register (AX). As their sizes are not compatible, MASM assumes that this is a logic error in the program and reports an error.⁸

For the most part, MASM ignores the difference between signed and unsigned variables. MASM is perfectly happy with both of these mov instructions:

i8 sbyte ?
u8 byte  ?
    .
    .
    .
mov al, i8
mov bl, u8

All MASM cares about is that you’re moving a byte variable into a byte-sized register. Differentiating signed and unsigned values in those registers is up to the application program. MASM even allows something like this:

r4v real4 ?
r8v real8 ?
    .
    .
    .
mov eax, r4v
mov rbx, r8v

Again, all MASM really cares about is the size of the memory operands, not that you wouldn’t normally load a floating-point variable into a general-purpose register (which typically holds integer values).

In Table 1-4, you’ll notice that there are proc, label, and constant types. MASM will report an error if you attempt to use a proc or label reserved word in a mov instruction. The procedure and label types are associated with addresses of machine instructions, not variables, and it doesn’t make sense to “load a procedure” into a register.

However, you may specify a constant symbol as a source operand to an instruction; for example:

someConst = 5
    .
    .
    .
mov eax, someConst

As there is no size associated with constants, the only type checking MASM will do on a constant operand is to verify that the constant will fit in the destination operand. For example, MASM will reject the following:

wordConst = 1000
    .
    .
    .
mov al, wordConst

1.11.3 The add and sub Instructions

The x86-64 add and sub instructions add or subtract two operands, respectively. Their syntax is nearly identical to the mov instruction:

add destination_operand, source_operand
sub destination_operand, source_operand

However, constant operands are limited to a maximum of 32 bits. If your destination operand is 64 bits, the CPU allows only a 32-bit immediate source operand (it will sign-extend that operand to 64 bits; see “Sign Extension and Zero Extension” in Chapter 2 for more details on sign extension).

The add instruction does the following:

destination_operand = destination_operand + source_operand

The sub instruction does the calculation:

destination_operand = destination_operand - source_operand

With these three instructions, plus some MASM control structures, you can actually write sophisticated programs.

1.11.4 The lea Instruction

Sometimes you need to load the address of a variable into a register rather than the value of that variable. You can use the lea (load effective address) instruction for this purpose. The lea instruction takes the following form:

lea    reg64, memory_var

Here, reg64 is any general-purpose 64-bit register, and memory_var is a variable name. Note that memory_var’s type is irrelevant; it doesn’t have to be a qword variable (as is the case with mov, add, and sub instructions). Every variable has a memory address associated with it, and that address is always 64 bits. The following example loads the RCX register with the address of the first character in the strVar string:

strVar  byte "Some String", 0
    .
    .
    .
    lea rcx, strVar

The lea instruction is roughly equivalent to the C/C++ unary & (address-of) operator. The preceding assembly example is conceptually equivalent to the following C/C++ code:

char strVar[] = "Some String";
char *RCX;
    .
    .
    .
    RCX = &strVar[0];

1.11.5 The call and ret Instructions and MASM Procedures

To make function calls (as well as write your own simple functions), you need the call and ret instructions.

The ret instruction serves the same purpose in an assembly language program as the return statement in C/C++: it returns control from an assembly language procedure (assembly language functions are called procedures). For the time being, this book will use the variant of the ret instruction that does not have an operand:

ret

(The ret instruction does allow a single operand, but unlike in C/C++, the operand does not specify a function return value. You’ll see the purpose of the ret instruction operand in Chapter 5.)

As you might guess, you call a MASM procedure by using the call instruction. This instruction can take a couple of forms. The most common is

call proc_name

where proc_name is the name of the procedure you want to call.

As you’ve seen in a couple code examples already, a MASM procedure consists of the line

proc_name proc

followed by the body of the procedure (typically ending with a ret instruction). At the end of the procedure (typically immediately after the ret instruction), you end the procedure with the following statement:

proc_name endp

The label on the endp directive must be identical to the one you supply for the proc statement.

In the stand-alone assembly language program in Listing 1-4, the main program calls myProc, which will immediately return to the main program, which then immediately returns to Windows.

; Listing 1-4

; A simple demonstration of a user-defined procedure.

        .code

; A sample user-defined procedure that this program can call.

myProc  proc
        ret    ; Immediately return to the caller
myProc  endp

; Here is the "main" procedure.

main    PROC

; Call the user-defined procedure.

        call  myProc

        ret    ; Returns to caller
main    endp
        end

Listing 1-4: A sample user-defined procedure in an assembly language program

You can compile this program and try running it by using the following commands:

C:\>ml64 listing1-4.asm /link /subsystem:console /entry:main
Microsoft (R) Macro Assembler (x64) Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: listing1-4.asm
Microsoft (R) Incremental Linker Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/OUT:listing1-4.exe
listing1-4.obj
/subsystem:console
/entry:main

C:\>listing1-4

1.12 Calling C/C++ Procedures

While writing your own procedures and calling them are quite useful, the reason for introducing procedures at this point is not to allow you to write your own procedures, but rather to give you the ability to call procedures (functions) written in C/C++. Writing your own procedures to convert and output data to the console is a rather complex task (probably well beyond your capabilities at this point). Instead, you can call the C/C++ printf() function to produce program output and verify that your programs are actually doing something when you run them.

Unfortunately, if you call printf() in your assembly language code without providing a printf() procedure, MASM will complain that you’ve used an undefined symbol. To call a procedure outside your source file, you need to use the MASM externdef directive.⁹ This directive has the following syntax:

externdef  symbol:type

Here, symbol is the external symbol you want to define, and type is the type of that symbol (which will be proc for external procedure definitions). To define the printf() symbol in your assembly language file, use this statement:

externdef  printf:proc

When defining external procedure symbols, you should put the externdef directive in your .code section.

The externdef directive doesn’t let you specify parameters to pass to the printf() procedure, nor does the call instruction provide a mechanism for specifying parameters. Instead, you can pass up to four parameters to the printf() function in the x86-64 registers RCX, RDX, R8, and R9. The printf() function requires that the first parameter be the address of a format string. Therefore, you should load RCX with the address of a zero-terminated string prior to calling printf(). If the format string contains any format specifiers (for example, %d), you must pass appropriate parameter values in RDX, R8, and R9. Chapter 5 goes into great detail concerning procedure parameters, including how to pass floating-point values and more than four parameters.

1.13 Hello, World!

At this point (many pages into this chapter), you finally have enough information to write this chapter’s namesake application: the “Hello, world!” program, shown in Listing 1-5.

; Listing 1-5
 
; A "Hello, world!" program using the C/C++ printf() function to
; provide the output.

        option  casemap:none
        .data

; Note: "10" value is a line feed character, also known as the
; "C" newline character.
 
fmtStr  byte    'Hello, world!', 10, 0

        .code

; External declaration so MASM knows about the C/C++ printf()
; function.

        externdef  printf:proc
        
; Here is the "asmFunc" function.

        public  asmFunc
asmFunc proc

; "Magic" instruction offered without explanation at this point:

        sub     rsp, 56

; Here's where we'll call the C printf() function to print
; "Hello, world!" Pass the address of the format string
; to printf() in the RCX register. Use the LEA instruction
; to get the address of fmtStr.

        lea     rcx, fmtStr
        call    printf

; Another "magic" instruction that undoes the effect of the 
; previous one before this procedure returns to its caller.

        add    rsp, 56
        
        ret    ; Returns to caller
        
asmFunc endp
        end

Listing 1-5: Assembly language code for the “Hello, world!” program

The assembly language code contains two “magic” statements that this chapter includes without further explanation. Just accept the fact that subtracting from the RSP register at the beginning of the function and then adding this value back to RSP at the end of the function are needed to make the calls to C/C++ functions work properly. Chapter 5 more fully explains the purpose of these statements.

The C++ function in Listing 1-6 calls the assembly code and makes the printf() function available for use.

// Listing 1-6
 
// C++ driver program to demonstrate calling printf() from assembly 
// language.
 
// Need to include stdio.h so this program can call "printf()".

#include <stdio.h>

// extern "C" namespace prevents "name mangling" by the C++
// compiler.

extern "C"
{
    // Here's the external function, written in assembly
    // language, that this program will call:

    void asmFunc(void);
};

int main(void)
{
    // Need at least one call to printf() in the C program to allow 
    // calling it from assembly.

    printf("Calling asmFunc:\n");
    asmFunc();
    printf("Returned from asmFunc\n");
}

Listing 1-6: C++ code for the “Hello, world!” program

Here’s the sequence of steps needed to compile and run this code on my machine:

C:\>ml64 /c listing1-5.asm
Microsoft (R) Macro Assembler (x64) Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: listing1-5.asm

C:\>cl listing1-6.cpp listing1-5.obj
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26730 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

listing1-6.cpp
Microsoft (R) Incremental Linker Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:listing1-6.exe
listing1-6.obj
listing1-5.obj

C:\>listing1-6
Calling asmFunc:
Hello, World!
Returned from asmFunc

You can finally print “Hello, world!” on the console!

1.14 Returning Function Results in Assembly Language

In a previous section, you saw how to pass up to four parameters to a procedure written in assembly language. This section describes the opposite process: returning a value to code that has called one of your procedures.

In pure assembly language (where one assembly language procedure calls another), passing parameters and returning function results are strictly a convention that the caller and callee procedures share with one another. Either the callee (the procedure being called) or the caller (the procedure doing the calling) may choose where function results appear.

From the callee viewpoint, the procedure returning the value determines where the caller can find the function result, and whoever calls that function must respect that choice. If a procedure returns a function result in the XMM0 register (a common place to return floating-point results), whoever calls that procedure must expect to find the result in XMM0. A different procedure could return its function result in the RBX register.

From the caller’s viewpoint, the choice is reversed. Existing code expects a function to return its result in a particular location, and the function being called must respect that wish.

Unfortunately, without appropriate coordination, one section of code might demand that functions it calls return their function results in one location, while a set of existing library functions might insist on returning their function results in another location. Clearly, such functions would not be compatible with the calling code. While there are ways to handle this situation (typically by writing facade code that sits between the caller and callee and moves the return results around), the best solution is to ensure that everybody agrees on things like where function return results will be found prior to writing any code.

This agreement is known as an application binary interface (ABI). An ABI is a contract, of sorts, between different sections of code that describe calling conventions (where things are passed, where they are returned, and so on), data types, memory usage and alignment, and other attributes. CPU manufacturers, compiler writers, and operating system vendors all provide their own ABIs. For obvious reasons, this book uses the Microsoft Windows ABI.

// Listing 1-7

// c.cpp
 
// Generic C++ driver program to demonstrate returning function
// results from assembly language to C++. Also includes a
// "readLine" function that reads a string from the user and
// passes it on to the assembly language code.
 
// Need to include stdio.h so this program can call "printf()"
// and string.h so this program can call strlen.

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// extern "C" namespace prevents "name mangling" by the C++
// compiler.

extern "C"
{
    // asmMain is the assembly language code's "main program":

    void asmMain(void);

    // getTitle returns a pointer to a string of characters
    // from the assembly code that specifies the title of that
    // program (that makes this program generic and usable
    // with a large number of sample programs in "The Art of
    // 64-Bit Assembly").

    char *getTitle(void);

    // C++ function that the assembly
    // language program can call:

    int readLine(char *dest, int maxLen);

};

// readLine reads a line of text from the user (from the
// console device) and stores that string into the destination
// buffer the first argument specifies. Strings are limited in
// length to the value specified by the second argument
// (minus 1).
 
// This function returns the number of characters actually
// read, or -1 if there was an error.
 
// Note that if the user enters too many characters (maxlen or
// more), then this function returns only the first maxlen-1
// characters. This is not considered an error.

int readLine(char *dest, int maxLen)
{
    // Note: fgets returns NULL if there was an error, else
    // it returns a pointer to the string data read (which
    // will be the value of the dest pointer).

    char *result = fgets(dest, maxLen, stdin);
    if(result != NULL)
    {
        // Wipe out the newline character at the
        // end of the string:

        int len = strlen(result);
        if(len > 0)
        {
            dest[len - 1] = 0;
        }
        return len;
    } 
    return -1; // If there was an error
}

int main(void)
{
    // Get the assembly language program's title:

    try
    {
        char *title = getTitle();
            
        printf("Calling %s:\n", title);
        asmMain();
        printf("%s terminated\n", title);
    }
    catch(...)
    {
        printf
        ( 
            "Exception occurred during program execution\n"
            "Abnormal program termination.\n"
        );
    }
}

input byte maxLen dup (?)

; Listing 1-8
 
; An assembly language program that demonstrates returning
; a function result to a C++ program.

        option  casemap:none

nl      =       10  ; ASCII code for newline
maxLen  =       256 ; Maximum string size + 1

         .data  
titleStr byte    'Listing 1-8', 0
prompt   byte    'Enter a string: ', 0
fmtStr   byte    "User entered: '%s'", nl, 0

; "input" is a buffer having "maxLen" bytes. This program
; will read a user string into this buffer.
 
; The "maxLen dup (?)" operand tells MASM to make "maxLen"
; duplicate copies of a byte, each of which is uninitialized.

input    byte   maxLen dup (?)

        .code

        externdef   printf:proc
        externdef   readLine:proc

; The C++ function calling this assembly language module
; expects a function named "getTitle" that returns a pointer
; to a string as the function result. This is that function:

         public getTitle
getTitle proc

; Load address of "titleStr" into the RAX register (RAX holds
; the function return result) and return back to the caller:

         lea rax, titleStr
         ret
getTitle endp

; Here is the "asmMain" function.

        public  asmMain
asmMain proc
        sub     rsp, 56
                
; Call the readLine function (written in C++) to read a line
; of text from the console.
 
; int readLine(char *dest, int maxLen)
 
; Pass a pointer to the destination buffer in the RCX register.
; Pass the maximum buffer size (max chars + 1) in EDX.
; This function ignores the readLine return result.
; Prompt the user to enter a string:

        lea     rcx, prompt
        call    printf

; Ensure the input string is zero-terminated (in the event
; there is an error):

        mov     input, 0

; Read a line of text from the user:

        lea     rcx, input
        mov     rdx, maxLen
        call    readLine
        
; Print the string input by the user by calling printf():

        lea     rcx, fmtStr
        lea     rdx, input
        call    printf

        add     rsp, 56
        ret     ; Returns to caller
        
asmMain endp
        end

C:\>ml64 /c listing1-8.asm
Microsoft (R) Macro Assembler (x64) Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: listing1-8.asm

C:\>cl /EHa /Felisting1-8.exe c.cpp listing1-8.obj
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26730 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

c.cpp
Microsoft (R) Incremental Linker Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:listing1-8.exe
c.obj
listing1-8.obj

C:\> listing1-8
Calling Listing 1-8:
Enter a string: This is a test
User entered: 'This is a test'
Listing 1-8 terminated

ml64 /nologo /c /Zi /Cp listing1-8.asm
cl /nologo /O2 /Zi /utf-8 /EHa /Felisting1-8.exe c.cpp listing1-8.obj
listing1-8

echo off
ml64 /nologo /c /Zi /Cp %1.asm
cl /nologo /O2 /Zi /utf-8 /EHa /Fe%1.exe c.cpp %1.obj

build listing1-8

echo off
ml64 /nologo /c /Zi /Cp listing1-8.asm
cl /nologo /O2 /Zi /utf-8 /EHa /Felisting1-8.exe c.cpp listing1-8.obj

C:\>build listing1-8
C:\>listing1-8

// Listing 1-9
 
// A simple C++ program that demonstrates Microsoft C++ data
// type sizes:

#include <stdio.h>

int main(void)
{
        char                v1;
        unsigned char       v2;
        short               v3;
        short int           v4;
        short unsigned      v5;
        int                 v6;
        unsigned            v7;
        long                v8;
        long int            v9;
        long unsigned       v10;
        long long int       v11;
        long long unsigned  v12;
        __int64             v13;
        unsigned __int64    v14;
        float               v15;
        double              v16;
        void *              v17;

    printf
    (
        "Size of char:               %2zd\n"
        "Size of unsigned char:      %2zd\n"
        "Size of short:              %2zd\n"
        "Size of short int:          %2zd\n"
        "Size of short unsigned:     %2zd\n"
        "Size of int:                %2zd\n"
        "Size of unsigned:           %2zd\n"
        "Size of long:               %2zd\n"
        "Size of long int:           %2zd\n"
        "Size of long unsigned:      %2zd\n"
        "Size of long long int:      %2zd\n"
        "Size of long long unsigned: %2zd\n"
        "Size of __int64:            %2zd\n"
        "Size of unsigned __int64:   %2zd\n"
        "Size of float:              %2zd\n"
        "Size of double:             %2zd\n"
        "Size of pointer:            %2zd\n",
        sizeof v1,
        sizeof v2,
        sizeof v3,
        sizeof v4,
        sizeof v5,
        sizeof v6,
        sizeof v7,
        sizeof v8,
        sizeof v9,
        sizeof v10,
        sizeof v11,
        sizeof v12,
        sizeof v13,
        sizeof v14,
        sizeof v15,
        sizeof v16,
        sizeof v17
    );            
}

C:\>cl listing1-9.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26730 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

listing1-9.cpp
Microsoft (R) Incremental Linker Version 14.15.26730.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:listing1-9.exe
listing1-9.obj

C:\>listing1-9
Size of char:                1
Size of unsigned char:       1
Size of short:               2
Size of short int:           2
Size of short unsigned:      2
Size of int:                 4
Size of unsigned:            4
Size of long:                4
Size of long int:            4
Size of long unsigned:       4
Size of long long int:       8
Size of long long unsigned:  8
Size of __int64:             8
Size of unsigned __int64:    8
Size of float:               4
Size of double:              8
Size of pointer:             8