Books

• Gunnar Fant - Acoustic Theory of Speech Production
• James L. Flanagan - Speech Analysis, Synthesis and Perception
• Kenneth N. Stevens - Acoustic Phonetics
• Paul Boersma - Functional Phonology
• J. M. Pickett - The Acoustics of Speech Communication
• D. G. Childers - Speech Processing and Synthesis Toolboxes
• A. Seikel, D. King and D. Drumright - Anatomy and Physiology for Speech, Language and Hearing. Lovely book.

Papers, Theses and Slides

• P. Mermelstein - Articulatory Model for the Study of Speech Production. Mermelstein's paper is a classic, and a mandatory read for anyone interested in the subject of articulatory synthesis and inversion. It describes the most used articulatory model to date. Albeit 3D articulatory models are the current trend, Mermelstein's model is still very useful for research. This version has some low-quality pages. I'll provide a better scanned version later.
• Michael Portnoff - A Quasi-one-dimensional Digital Simulation for the Time-varying Vocal Tract
• J. Dang and K. Honda - Construction and Control of a Physiological Articulatory Model
• I. Howard and M. Huckvale - Learning to control an articulatory synthesizer by imitating real speech
• Olov Engwall - Vocal tract modeling in 3D
• R. Sproat, M. Ostendorf and A. Hunt (Editors) - The Need for Increased Speech Synthesis Research
• W. Hess - Artikulatorische und akustische Phonetik (German) This concrete presentation of articulatory and acoustic phonetics by professor Wolfgang Hess is one of the best in the web.
• Qiguang Lin - Speech Production Theory and Articulatory Speech Synthesis.

A few of my own documents

My research is just a drop compared to the above oceans. Although some of the ideas and assumptions I followed are already old, someone may find them useful:

• J. Brito - Genetic Learning of Vocal Tract Area Functions for Articulatory Synthesis of Spanish Vowels.
• J. Brito and W. Rodríguez - Multipopulation genetic learning of midsagittal articulatory models for speech synthesis.
• J. Brito - Técnicas de Aprendizaje Artificial Aplicadas al Problem Inverso de la Síntesis Articulatoria de Voz por Computadora (Spanish) My doctoral dissertation. I'll upload it later... I don't remember where it is

Finally, please notice that the list is by no means complete or comprehensive. Some very important papers are missing, such as Flanagan and Ishizaka vocal fold modeling, Maeda's simulation of the vocal tract, Rubin's description of a synthesizer, Sorokin's model and others. I'll be adding more items in the future.

Cygwin

Cygwin allows to run a collection of Unix tools on Windows, including the GNU development toolchain. However, at its core, cygwin is a library which translates the POSIX system call API into the pertinent Win32 system calls (system calls are often abbreviated as syscalls). Therefore, cygwin is a software layer between applications using POSIX system calls and the Win32 operating systems, which allows porting some Unix applications to Windows. This way you can, for instance, have the Apache daemon working as a Windows service. Other very attractive feature of Cygwin is its interactive environment: you can run your shell quite nicely, and run your Autoconf scripts, for example. However, porting means recompiling. There is no binary compatibility, and your program cannot run in computers without Cygwin (without CYGWIN1.DLL, more precisely). Furthermore, albeit some progress has been made, Cygwin is relatively slow (it's a POSIX compatibility layer, after all.) If possible, I prefer to recompile my applications directly with MinGW. For me, this allows for a faster development cycle. Note, though, that Cygwin can compile MinGW-compatible executables. It's just that, as aforesaid, I prefer to work with MinGW directly. I only work on Windows if I have to develop applications for Windows. But Linux's development tools are the best, and we can access several of them by using MinGW. I think that Cygwin is best suited for general cross-development and for handling complicated software porting.

System Calls and int 0x80

A system call is a request by an active process for a service performed by the operating system kernel. Remember that a process is an executing (running) instance of a program, and the active process is the process currently using the CPU. The active process may perform a system call to request creation of other process, for instance. Or perhaps the process needs to communicate with a peripheral device. In Linux on x86, int 0x80 is the assembly language instruction that is used to invoke system calls. int 0x80 is a software interrupt, as it will be raised by a software process, not by hardware devices. Before invoking such interruption, our program have to store the system call number (which allows the operating system to know what service your program is specifically requesting ) in the proper register of the CPU. Every interrupt is a signal to the operating system, notifying it about the occurrence of an event that must be computationally handled.

Application Binary Interface

Generally speaking, an Application Binary Interface (ABI) is the interface between an application program and the operating system. Conceptually, it's related to the more well-known API concept. But ABIs are a low-level notion, while APIs are more leaned toward the application source code level. If your program uses an specific API, you will be able to compile it on any system which implements that API. Similarly, a program (or more generally, a compiled object code) which uses a specific ABI will run (without the need for recompilation) on any system offering that ABI. Specification of ABIs includes, but is not limited to, details such as:

1. How applications make system calls to the operating system.

2. System call numbers.

3. Calling conventions (how parameters are passed to functions, and how their return values are received).

4. The format of the object code (COFF/PE, ELF, etc.)

To consolidate ideas, notice that a relatively backward-compatible ABI is which has allowed several older applications to run on newer versions of Windows.

Now a few things should be quite clear. First, Cygwin is a software layer at the API level. Second, interrupts are a concept from the ABI level. And it's obvious that Linux syscalls are entirely different from Windows syscalls. Further, in Cygwin you don't make raw system calls... it's CYGWIN1.DLL which does the needed Windows system calls according to your program requirements. The ABI of software compiled with Cygwin is that of Windows systems. You cannot use a Linux ABI's thing, such as int 0x80, and expect that your program runs fine on Windows.

If you're programming in assembly, 0x80 only works in Linux. For DOS/Windows, you must use 0x21, 0x25, 0x26, etc. That's the rationale behind my decision for using a function of the C library, printf, in order to avoid this problem in the example code of this post.

The Truth Reflected in the Mirror

You cannot use a Linux ABI's thing, such as int 0x80, and expect that your program runs fine on Windows. That's not entirely true. Under Windows, you can install a vectored exception handler which traps the interruption request, and with some coding translate the trapped information into the Windows equivalent. But that amounts to writing an Linux kernel emulator.

If you are in a hurry, perhaps you'll prefer the wise path of virtualization. By using a virtualization engine like VMWare and Xen you can install and execute a guest operating system on a host system. Such virtual machines offer a full resources abstraction which allows you to use the guest operating system almost at its full. For some tasks, the coLinux's approach may be preferable. Cooperative Linux (coLinux) allows the Windows and Linux kernel to run simultaneously on the same machine, but unlike traditional virtual machines, coLinux shares resources that already exist in the host.

coLinux is a very elegant and exciting project. However, installing and configuring coLinux may be a hard task. After installing your Linux distro, it's not easy to configure the window manager, the networking facilities, and other things. The best resource I've found in the net for such chores is this post by Sofeng: Install coLinux (and Ubuntu Hardy) on Win XP using Slirp to internet and TAP to host behind a corporate firewall/proxy server. It's a very recommended reading.

Nevertheless, I have a couple of quick tips for those who want to start programming in assembly as soon as possible. Please, notice that software is constantly evolving and the following tips may be obsolete for the time you're reading them. Review the excellent coLinux documentation beforehand. During coLinux setup, select the Ubuntu distribution. After installation, go to the folder where you installed it, and decompress the file Ubuntu-7.10.ext3.2GB.7z. Also put UbuntuSlirp.bat and coLinux.conf into your colinux directory (these files may require some tweaking according to your system.) Run coLinux by executing UbuntuSlirp.bat. Linux should boot nicely. Use root as login and password. And that's it. You'll have Linux on Windows. But developers need the GNU development tools. Install them by executing apt-get install gcc

At this point, you should have the GNU assembler (as) installed. Now you can type your programs, and assemble/run them. And you can use 0x80 in your assembly program! For example, I typed the hello, world program of the tutorial by Miyagi, and it assembled and ran just fine.

As always, your feedback is welcome.

On the other hand, articulatory synthesis produces a complete synthetic output, typically based on mathematical models of the structures (lips, teeth, tongue, glottis, and velum, for instance) and processes (transit of airflow along the supraglottal cavities, for instance) of speech. Technically, articulatory speech synthesis transforms a vector p(t) of anatomic or physiologic parameters into a speech signal Sv with predefined acoustic properties. For example, p(t) may include hyoid and tongue body position, protrusion and opening of lips, area of the velopharyngeal port, and so on. This way, an articulatory synthesizer ArtS maps the articulatory domain (from which p(t) is drawn) into the acoustic domain (where frequency properties of Sv lie). Computing the acoustic properties of Sv is the task of a special function. Now, using these definitions, the speech inverse problem is stated as an optimization problem, in which we try to find the best p(t) to minimize the acoustic distance between Sv and the output of ArtS.

The solution to the inverse problem is interesting for the following applications:

1. Reduction of memory space and bandwidth requirements for storage and transmission of speech signals.
2. Low cost and noninvasive comprehension and recollection of data on phonatory processes.
   Speech recognition, by means of transition to the articulatory domain, where signals may be characterized by fewer parameters.
3. Retrieving the best parameters for synthesis of high-quality speech signals.

However, because mapping between articulatory and acoustic domains is nonlinear and many-to-one, definition and achievement of acceptable solutions to the inverse problem are not trivial issues. Globally, qualifying a candidate solution follows some type of relation on the acoustical domain. Furthermore, from the family of solutions to the problem, we are frequently interested only in those configurations consistent to descriptions of articulatory phonetics. Several groups have approached this problem. For example, Yehia and Itakura adopted an approach based on geometric representations of the articulatory space, including spatial constraints. Dusan and Deng used analytical methods to recover the vocal tract configurations. Sondhi and Schroeter relied on a codebook technique. Genetic algorithms have also been used, albeit the approach and type of signals studied differ to those used in this research. These later studies mainly investigate relations between articulation and perception on the basis of the tasks of the task dynamic description of inputs to a synthesizer. More recent research recur to control points experimentally measured to a group of speakers, and inversion minimizes the distance between the articulatory model and the referred points, by using quadratic approximations. On our side, we have previously investigated the application of computational intelligence techniques to the speech inverse problem. Concretely, fuzzy rules for modeling the tongue kinematics, neural networks to generate the glottal airflow and genetic algorithms to carry out the overall optimization process. Another novelty of our previous research was the use of the five spanish vowels as target phonemes for inversion.

Synthesis Models

In a broader level, ArtS integrates two models: the articulatory and the acoustic model. An articulatory model represents the essential components for speech production, and its main purpose is computation of the area function A(x, t), which reflects the variation in cross-sectional area of the acoustic tube whose boundaries are located at the glottis and the mouth, respectively. Here, transitions between phonemes are not researched, and thereby the time variable will be dropped from the area function and from the vector p. On its side, an acoustic model specify the transformations between A(x) and the acoustic domain. Naturally, such mapping also requires information about the energy source exciting the tract. According to the acoustic theory of speech production, the target phonemes are considered as the output of a filter characterized by A(x) and excited by a periodic glottal signal.

In this post, we'll restrict our presentation to the Articulatory Model:

Phonemes of interest can be characterized on the articulatory midsagittal plane. Models of this type consolidated with Mermelstein’s paper, whose metrics and observations have been reutilized by several researchers, mainly for its explicitness and complete explanations. Midsagittal models describe position and movement of articulators on the plane. As the parameters of this model have an anatomical meaning, they simplify visualization of articulatory configurations, and contribute with the inversion techniques in rejecting some groups of unnatural configurations. Equilibrium position of our model, depicted in the above figure, is partially based on Mermelstein’s measurements. As the result of muscular contractions linked to articulation, the model may leave its equilibrium configuration, and ideally take on some articulatory configuration correspondent to a specific phoneme; therein lies the goal of inversion. In this respect, our articulatory vector p will group several supraglottal muscles whose activity alters the state of the midsagittal outline. In numerical terms, there are no complete and definitive data on this muscular activity and its kinematic effects. We may consider the muscular activity as a real number bordered by 0.0 and 1.0, denoting null and maximum muscular activity, respectively. General effects of muscular contractions are taken from approximations in the literature. Certainly, in order to cover the articulatory space, I like to store the following 12 muscles into p:

1. Middle Pharynx Constrictor: This muscle influences horizontal displacement of the hyoid bone, and its surrounding zones, approximately by 0.5 cm.
2. Masseter(MA): Raises the jaw, following an angle up to 0.15 radians relative to temporomandibular joint.
3. Mylohyoid (MH): Descends the mandible, up to 0.20 radians respect to temporomandibular joint.
4. Styloglossus (SG): Retracts the tongue in direction of the styloid process.
5. Hyoglossus (HG): Descends and slightly retracts the tongue body.
6. Anterior Genioglossus (GGa): Descends the tongue tip.
7. Middle Genioglossus (GGm): Moves tongue body forward, and slightly downward.
8. Posterior Genioglossus (GGp): Raises and advances the tongue body.
9. Intrinsic tongue muscles (Up): Raise tongue tip.
10. Intrinsic tongue muscles (Down): Descend tongue tip.
11. Risorius: Spreads the lips, changing the width of the lip opening up to 4.5 cm.
12. Orbicularis oris: Acts for lip rounding, pulling the upper and lower lips together (with a respective maximum vertical change of 1 cm) and protruding them (up to 2.0 cm).

In upcoming posts, we'll continue our review of articulatory speech synthesis. And I have yet to provide the references.

Finally, it's time to switch to the fabulous GNU as. We'll forget about DEBUG for some time. Thanks DEBUG. GNU as, Gas, or the GNU Assembler, is obviously the assembler used by the GNU Project. It is part of the Binutils package, and acts as the default back-end of gcc. Gas is very powerful and can target several computer architectures. Quite a program, then. As most assemblers, Gas' input is comprised of directives (also referred to as Pseudo Ops), comments, and of course, instructions. Instructions are very dependent on the target computer architecture. Conversely, directives tend to be relatively homogeneous.

1 Syntax

Originally, this assembler only accepted the AT&T assembler syntax, even for the Intel x86 and x86-64 architectures. The AT&T syntax is different to the one included in most Intel references. There are several differences, the most memorable being that two-operand instructions have the source and destinations in the opposite order. For example, instruction mov ax, bx would be expressed in AT&T syntax as movw %bx, %ax, i.e., the rightmost operand is the destination, and the leftmost one is the source. Other distinction is that register names used as operands must be preceded by a percent (%) sign. However, since version 2.10, Gas supports Intel syntax by means of the .intel_syntax directive. But in the following we'll be using AT&T syntax.

2 Our Goals

What we'll be doing is to create a new instance of a hello, world! program. Let's recapitulate the articles we've studied so far. First, we presented some reminiscences and motivations for hello, world!. Next, we coded a hello, world! program by using the MS-DOS DEBUG program. Later, we encoded such program directly in hexadecimal (no need for DEBUG). And finally, we abused the MS-DOS ECHO command to create a binary, executable hello, world! program directly from the DOS command line (again no need for DEBUG.) A thing all these programs had in common was their use of the 09h function of INT 21h for printing the "hello, world!" string. But it's time to move forward. Now I plan to use the lovely C printf function. In C, our greeting program would be

int main()
{
    printf("hello, world!\n");
    return 0;
}

We've omitted inclusion of the stdio.h header. We could recur to only one sentence: return printf("hello, world!\n") - 14; but I think that by using two sentences we'll get a clearer code. We save our program in a file called "hello.c", and compile with

gcc -o hello.exe hello.c

I'll be working on Windows, with the MinGW port of the GNU Compiler Collection. I like MinGW a lot, specially its ability to provide native functionality via direct Windows API calls, which is good for performance of our applications. Working in Windows means that our executable files (object code and DLLs too) follow the PE/COFF format. The Portable Executable (PE) file format is a wrapper for all the information the Windows loader requires in order to run the code. PE is a modified version of the Unix COFF file format (hence the reference PE/COFF.) Other popular file format for executable code is ELF (Executable and Linkable Format), which is used by Linux, the Nintendo Wii and DS, and the PlayStation 3. For the time being, we only have to know that the behavior of GNU as varies according to the target file format (in our case, PE/COFF.)

gcc can also provide us with the x86 assembly file it used. I typed gcc -S hello.c and this was the output I got:

.file    "hello.c"
    .def    ___main;    .scl    2;    .type 32;    .endef
    .section .rdata,"dr"
LC0:
    .ascii "hello, world!\12\0"
.text
.globl _main
    .def    _main;    .scl    2;    .type    32;    .endef
_main:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $8, %esp
    andl    $-16, %esp
    movl    $0, %eax
    addl    $15, %eax
    addl    $15, %eax
    shrl    $4, %eax
    sall    $4, %eax
    movl    %eax, -4(%ebp)
    movl    -4(%ebp), %eax
    call    __alloca
    call    ___main
    movl    $LC0, (%esp)
    call    _printf
    movl    $0, %eax
    leave
    ret
    .def    _printf;    .scl    2;    .type    32;    .endef

3 Code Explanations

From a general view, we identify 3 elements in the above listing. First, we have directives, which are symbols beginning with a '.' (dot.) As aforesaid, directives are typically valid for any computer. If the symbol begins with a letter the statement is an assembly language instruction, i.e., it will assemble into a machine language instruction, and surely will differ between computer architectures. Finally, labels are those symbols immediately followed by a ':' (colon.) We may think of labels as "directions" for data or code. Now let's do a shallow review of a few germane directives, so bear with me.

.file string

This directive identifies the start of the logical file (and string should be the file name.) Actually, the directive is ignored and is only there for compatibility with old versions. We can remove it.

.def name ... .endef

This pair of directives enclose debugging information for the symbol name, and are only observed when Gas is configured for PE/COFF format output. But we don't need it for a simple hello, world! program.

.section name

This directive indicates that the following code has to be assembled into a section called name. For PE/COFF targets, the .section directive is used in one of the following ways:

.section name [, "flags"]
.section name [, subsegment]

The gcc's output we've got recurs to the form with flags, and specifically, two flags (single character) are used to indicate the attributes of the section: d (data section) and r (read-only section.) But again, we don't need to explicitly signal section attributes for our simple program.

.ascii "string"

Defines one or more string literals (separated by commas.) Each string is assembled into consecutive addresses (with no trailing zero character.)

.text subsection

Tells Gas to assemble the following statements onto the end of the text subsection numbered subsection. If subsection is omitted (as it's our case), subsection number zero is used. Clearly, this directive is mandatory, or Gas will not assemble the code to print our hello, world! message.

.global symbol (or .globl symbol)

.global makes symbol visible to the linker. In our case, we want to inform the linker about the _main function that it is expecting. For compatibility with other assemblers, both spellings (.global or .globl) are valid.

Now, directives are done. After label _main we only have assembly code up to the ret instruction. Some of this code should be clear if you have previous experience with assembly programming. Nevertheless, let's review these instructions too. Note that the 'l' on the end of each mnemonic tells Gas that we want to use the version of the instruction that works with "long" (32-bit) operands.

First 3 instructions are typical code for stack initialization:

pushl   %ebp
movl    %esp, %ebp
subl    $8, %esp

By subtracting 8 bytes from ESP we're reserving the space on the stack to hold local variables (the Intel stack "grows" from high memory locations to the lower ones.) Next we have the rarer

andl	$-16, %esp

Remember that in hexadecimal, -16 is expressed as 0xFFFFFFF0. Therefore, this and aligns the stack with the next lowest 16-byte address. The reasons for this alignment are not very clear to me. It may be a gcc choice in order to accelerate floating point accesses, or it may be for compatibility with a particular architecture. Any of these, we don't require such alignment for displaying hello, world!

The following code is mostly a very contrived way of storing a value in EAX:

movl	$0, %eax
addl	$15, %eax
addl	$15, %eax
shrl	$4, %eax
sall	$4, %eax
movl	%eax, -4(%ebp)
movl	-4(%ebp), %eax

Clearly the code is not optimized as there are a lot of unnecessary lines. Moreover, final EAX's value is also stored into memory previously reserved on the stack. It seems the value in EAX is a parameter for the _alloca invocation in the two following lines:

call	__alloca
call	___mai

These two calls are unnecessary for our toy application. We won't delve into details, but I'll say the alloca() is a function used to allocate memory on the stack. And if PE/COFF binaries are used, and our application has an int main() function, then a function void __main() should be called first thing after entering main(). We'll leave it at that for now. More information can be found in this excellent and instructive article from OSDevWiki.

At last, we find the useful code

movl    $LC0, (%esp)
call    _printf

It moves the address of the ascii string into the stack, and invokes printf. Now, where's the definition of printf? Well, we'll take it from the C library, of course. The linker (ld) is responsible of associating our code with the definition of printf.

Finally, we found

movl    $0, %eax
leave
ret

These instructions constitute the "returning code." Store the return value (0 == success!) in EAX, destroy the stack, and pop the saved Instruction Pointer from the stack in order to return control to the calling procedure or program.

If we strip all the unnecessary lines, our hello, world! would acquire this form:

.data
LC0:
    .ascii "hello, world!\n\0"
.text
    .global _main
_main:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $4, %esp
    movl    $LC0, (%esp)
    call    _printf
    movl    $0, %eax
    leave
    ret

Shorter and clearer. I assembled the hard way, step by step:

as -o hello.o hello.s

ld -o hello.exe
/mingw/lib/crt2.o
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/crtbegin.o
-LC:/MinGW/bin/../lib/gcc/mingw32/3.4.5
-LC:/MinGW/lib hello.o
-lmingw32 -lgcc -lmsvcrt -lkernel32
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/crtend.o

But it's better to just type gcc -o hello.exe hello.s

The hexadecimal code of our program is:

EB 12 0D 0A 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64
21 0D 0A 24 B4 09 BA 02 01 CD 21 B4 00 CD 21 0D

Now, we only have to input and redirect these hexadecimal values to a file, that we'll name hello.com.

That would be fairly easy except for some values such as 00 and 09, which represent the NULL and TAB characters, respectively. How do you input those characters as parameters for the echo command? I found no way of doing that. If you know a way, please drop me a line. Therefore, I changed the code of the program in two ways:

• The 09 character comes from the instruction mov ah,9. I replaced that by two instructions: mov ah,7 and add ah,2. The semantic stays intact, but the contrived approach allows us to discard the 09 character.
• Regarding the NULL character (00), it's a consequence of the line mov ah,00. But we can accomplish the effect of clearing ah by executing xor ax,ax instead. And that's it.

Take a look at the complete command I used:

Nice

x86: It refers to the instruction set of the Intel-compatible CPU architectures (chips produced by Intel, AMD, VIA, and others) inaugurated by Intel's original 16-bit 8086 CPU. A decision which proved wise was to make each new instance of x86 processors almost fully backwards compatible.
IA-32: It is Intel's 32-bit implementation of the x86 architecture; IA-32 distinguishes this implementation from the preceding 16-bit x86 processors. Note that when the 64-bit era arrived, Intel launched its Itanium processor, which discards compatibility with the IA-32 instruction set. Such 64-bit architecture description and implementation is referred to as IA-64, meaning "Intel Architecture, 64-bit", but even though the names are similar, IA-32 and IA-64 are very different architectures and instructions sets. However, AMD's response to Intel 64-bit processors, uses an instruction set that, in essence, is composed of 64-bit extensions to IA-32, i.e., it's a superset of the x86 instruction set. Such instruction set is referred to as AMD64 (initially, x86-64.) Later, Intel cloned it under the name Intel 64. AMD's processors Athlon 64, Terium, Opteron, Sempron, etc., are based on AMD64.
Opcode: An opcode (operation code) is the part of a machine language instruction (pure binary code) specifying the operation to be performed. The other portion of the instruction is the operand, which is optional and represents the data to be operated on. In assembly language, mnemonics are used to represent the opcodes. Concretely, and according to the IASDM, a mnemonic is a reserved name for a class of instruction opcodes which have the same function. For example, in JMP 114, the mnemonic is JMP, and the operand is 114 (remember, 114 in hexadecimal, which is 276 in decimal.)

Unlike in high-level languages, there is usually a one-to-one correspondence between basic assembly statements and the binary code of machine language instructions. Nevertheless, in some cases, an assembler may provide pseudo-instructions which expand into several machine language instructions to provide commonly needed functionality. Or no instruction at all, such as DB in

db 0d,0a,"hello, world!",0d,0a,"$"

which directly translates into the sequence of characters (in hexadecimal):

0D 0A 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64 110 21 0D 0A 24

Therefore, pseudo-instruction DB acts only as a data markup for the assembler. Now, for clarity, I'll repeat the code of Debugging "hello, world" here:

- a 100
CS:0100 jmp 114         ; Jump over the 18 bytes of the string
CS:0102 db 0d,0a,"hello, world!",0d,0a,"$"
CS:0114 mov ah,9       ; Print function
CS:0116 mov dx,102
CS:0119 int 21
CS:011B mov ah, 0      ; Terminate the program
CS:011D int 21
CS:011F
-g =100

Translation of the second line is a direct and solved issue. What about jmp 114? Well, we want to jump over the data (18 bytes, one byte per each character in the string.) IASDM tell us (Appendix B) that the opcode for unconditional jumps in the same segment is 11101011, which in hexadecimal, is expressed as EB. We need to provide the operand for completing the instruction. In this case, as we want to jump over the string data, our operand is 18 (12 in hexadecimal.) That's why jmp 114 translates into EB12. Note that the operand for this jmp specifies the 8-bit displacement, i.e., the operand is not an explicit address.

Translation of the other instructions is straightforward, and again we only have to follow the IASDM. Let's analyze encoding of mov ah,9 anyway. In this case we have an immediate operand (a constant, 9.) Thus, for moving an immediate operand to a register the encoding adopts this form:

1011 w reg : immediate data

There, w represents the bit for operand size. That bit specifies if data is byte or full-sized (where full-sized is either 16 or 32 bits.) As we'll be using 8-bit operands, set the bit to 0. On its side, reg is a 3-bit sequence identifying the destination register. Table B-3 of the IASDM dictates that if w = 0, then register AH is encoded as binary 100. Thus, encoding of mov ah,9 is

10110100 00001001

which in hexadecimal is expressed as B409. The next instruction, mov dx,102, follows a similar approach:

1011 1 010 0000 0001 0000 0010

In this case, however, w is set to 1, as the operand 102 requires more than 1-byte storage. The 3-bit sequence for DX is 010. Needless to say, 0000 0001 0000 0010 is the binary representation of the hexadecimal value 102 (16 bits are required). Expressing in hexadecimal, we would have BA0102. However, the bytes for the operand has to be stored in reverse order, and thereby the right encoding for the instruction is BA0201.

Next, INT n (Interruption type n) is encoded as 1100 1101 : type. Therefore, int 21 is encoded as 1100 1101 0010 0001 (CD21 in hexadecimal.) And encoding of mov ah, 0 as B400 follows directly from our previous explanations. Finally, we can translate our little "hello, world!" into binary code directly:

-e 100 EB 12 0D 0A 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64
-e 110 21 0D 0A 24 B4 09 BA 02 01 CD 21 B4 00 CD 21 0D
-g =100

And that's all. I think that my explanations have been clear. But I'm always open to any suggestions and corrections. Thanks for reading.

But wait a minute. I remember that, according to Brooks' law, "adding people to a late software project makes it later."

Cowboy wisdom #1: Yeah. But "if you don't add people to a late software project then it has been canceled."

Do they indeed come from the farthest west? Not necessarily. Perhaps they have been members of the team since the start. Frequently, cowboy (cowgirl) programmers are not external newcomers. They are hidden (or not) in the core of the team. And they are important contributors to the flaws of the project. Blame managers, though, for accepting them in and for trusting their nonsense advices.

However, I've also seen a lot of fellow programmers to crumble under the project's pressure. In such circumstances, they awaken their hidden alter ego, and happily wear their hats. I have met several of such outlaws, and in the following, I pay tribute to this lovely and legendary figure of programming.

>> The Truth about Software Development Life Cycle (SDLC)

Cowboy programmers are the absolute reference for everything. Masters of all trades (although they don't have any clue about SDLC, but who cares?) Analysis, Design, and related topics are for sissies, and for allowing professors of Computer Science who are bad at mathematics to make a living. SDLC is a pony. Cowboys ride horses.

Requirements Elicitation anyone? What for? Cowboy programmers know what customers want. Besides, filling myriad pages with arrows and boxes is a complete waste of time: we should be coding instead! That's why the project is late!

Cowboy wisdom #2: Reading too much Software Engineering books has rot your mind. Welcome to life, boy.

>> Learning to Code

Cowboy programmers have no time for thinking. Their code is rushed, but effective. Optimizations are for compilers. They just get the things done. How to reverse a string? Here's your answer, enjoy it:

char* rev_str(char* str)
{
  int str_l = strlen(str);
  char* r = (char*)malloc(str_l);
  int i =  str_l-1;
  while (*str)
  {
    r[i] = *str;
    str++;
    i--;
  }
  r[str_l-1] = 0;
  return r;
}

Please, don't rush into believing that Cowboy Programmers don't comment their code. They do. And they do it excessively. The main difference, perhaps, is that their comments are what is known as auxiliary comments. Let me explain. Imagine that our cowboy programmer finally accepts that his code contains a bug, and decides to use a function of some library. These are the germane comments our cowboy introduces in his code:

char* rev_str(char* str)
{
  /*
  int str_l = strlen(str);
  char* r = (char*)malloc(str_l);
  int i =  str_l-1;
  while (*str)
  {
    r[i] = *str;
    str++;
    i--;
  }
  r[str_l-1] = 0;
  */
  return lib_str_reverse(str);
}

Note how the old code turns into auxiliary comments which nicely explains what lib_str_reverse(char*) does.

Cowboy wisdom #3: He that is without sin among you, let him first cast a stone...

>> The Dusty Road to Testing

For the cowboy programmer, the notion of "testing" implies the possibility of his code being buggy. Only people with poor self-confidence do tests. People who think of performing tests should be politely removed from the project. If we were to run tests in our project, our cowboy could not make the smallest change in the project without rerunning all sorts of tests. The project is late, remember?

Cowboy programmers always believe that their ideas and code are perfect. Any fiasco in the deliverables is a consequence of bugs in the code of someone else. Fear not, our cowboy even has solutions for such problems.

Cowboy wisdom #4: Did you learn in school what a watchdog is? It's a program that restarts the hardware if it seems to be wedged. Do you know what was the first piece of code I wrote just arriving here? Do you know?

>> Spawns Everywhere

Finally, other important trait of cowboy programmers is their disrespect for the code of other programmers. They will introduce changes everywhere, at will, always bitching about others' incompetency. Their code will dangerously spread.

Cowboy wisdom #5: I'm a mac daddy.

Nowadays, they are very, very healthy. Long life the cowboys.

I remember that a 100 tells DEBUG to accept code in memory starting out from CS:0100. Ok.

Now comes the data, which here simply consist of the string 'hello, world!'. A neat output, however, would require newlines before and after our intended string. A newline is comprised of a carriage return (CR = ASCII 13) and a line feed (LF = ASCII 10) on the display. As DEBUG only understand hexadecimal numbers, we must use 0Dh and 0Ah for CR and LF, respectively. Except in code, we will represent hexadecimal numbers by following the value with 'h'.) Fortunately, DEBUG also admits ASCII characters directly (and the pseudo-instructions DB and DW!), so we can express our complete string as

db 0d,0a,"hello, world!",0d,0a,"$"

The "$" requires an explanation. In order to print our string in STDOUT, we are going to recur to the function 09h of INT 21h. This function prints all the characters in memory, beginning at DX and finishing when the "$" (24h) sign is encountered (i.e., "$" acts as the zero in C strings.) Finally, we invoke function 00h of INT 21h for terminating the program after the string is echoed. And that's it.

- a 100
CS:0100 jmp 114         ; Jump over the 18 bytes of the string
CS:0102 db 0d,0a,"hello, world!",0d,0a,"$"
CS:0114 mov ah,9       ; Print function
CS:0116 mov dx,102
CS:0119 int 21
CS:011B mov ah, 0      ; Terminate the program
CS:011D int 21
CS:011F
-g =100

The Go command (g) will run the program starting at the given address (in this case, CS:0100) If everything goes right, the program should output the intended "hello, world!" string, and finish with the message "Program terminated normally."

You may save this program to a folder in your hard drive (I'll use c:\tmp). Simply input:

-n c:\tmp\hello.com
-rcx
CX 0000
:20
-w

-rcx allows to change the content of the CX register. We store there the value "20" which is the size of our program (why? note that our program occupies exactly 32 bytes... "32" is "20" in hexadecimal.) Write (w) uses CX for knowing how much bytes it has to save.

Now, you can dump memory contents (d) and view your program in hexadecimal (or open hello.com with a hexadecimal viewer):

-d
CS:0100 EB 12 0D 0A 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64
CS:0110 21 0D 0A 24 B4 09 BA 02 01 CD 21 B4 00 CD 21 0D

The hexadecimal patterns are very clear. For example, 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 is our "hello, world!" string. 0D and 0A are CR and LF, respectively. CD 21 is INT 21h. B4 09 is MOV AH,9. And so further.

Finally, remember that you may use Enter (e) to write your code directly into memory:

-e 100 EB 12 0D 0A 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64
-e 110 21 0D 0A 24 B4 09 BA 02 01 CD 21 B4 00 CD 21 0D
-g =100

Pretty, uh?

The full title of this book is "OpenGL Programming on Mac OS X: Architecture, Performance and Integration." Its fortunate authors are Robert P. Kuehne and J. D. Sullivan, two professionals who thoroughly know what they are talking about. Moreover, the book has been published by one of my favorites, Addison-Wesley. Therefore, success in conveying the details of OpenGL Programming on the Apple platform seems guaranteed. After reading it, I confirmed that any graphics programmer will learn a lot of things from this book. And nowadays, with a market saturated by rushed books, it's a bliss.

As suggested, this book has plenty of shining points, but there is a germane disclaimer: this is not a book for starting to learn OpenGL. As stated in the book's first pages, it's aimed at two categories of programmers:

1. Mac developers in general,
2. and those with OpenGL foundations who want to explore the enormous benefits of OpenGL development on Mac OS X.

I do strongly believe that any OpenGL developer will benefit of studying this great book. However, I don't know of any good book for learning OpenGL from scratch. I can point you to the Red Book or even the OpenGL SuperBible, which are superb references for novices, but both exhibit some important pedagogical flaws. On the contrary, "OpenGL Programming for Mac OS X" is indeed a very good book from the pedagogical standpoint, but it has a somewhat advanced level, covering very specific topics:

1. Mac OpenGL Introduction
2. OpenGL Architecture on OS X
3. Mac Hardware Architecture
4. Application Programming on OS X
5. OpenGL Configuration and Integration
6. The CGL API for OpenGL Configuration
7. The AGL API for OpenGL Configuration
8. The Cocoa API for OpenGL Configuration
9. The GLUT API for OpenGL Configuration
10. API Interoperability
11. Performance
12. Mac Platform Compatibility
13. OpenGL Extensions

The book also contains 4 useful appendices:

1. X11 APIs for OpenGL Configuration
2. Glossary
3. The Cocoa API for OpenGL Configuration in Leopard, Mac OS X 10.5
4. Bibliography

More resources should be available on the book's companion website. At the time of this writing, you can download the source code from that page as a locked zipped file. By the way, it's interesting (to say the least) the authors' decision of password-protecting their sources

In respect to the content, all of the explanations are crystal clear, focused into the concepts and techniques OpenGL developers really need. The book comprises OpenGL architecture and configuration on OS X, and the various APIs we can use in order to create OpenGL applications, specifically, CGL, AGL, Cocoa, (our old buddy) GLUT, and X11 APIs. A chapter focused into API Interoperability is also included, and is very complete. But there is much more information in this book: history notes, a germane review of Mac's hardware, OS X programming, compatibility between Mac platforms, and a discussion about OpenGL extensions. The glossary in the appendices proves to be very useful, and so are the notes about Cocoa API for OpenGL in Leopard.

Personally, Chapter 11 is the one I've enjoyed the most. The technical wisdom revealed in such chapter almost justifies by itself the full cost of the book. It's such a fine chapter. The almost 5 pages covering the "Axioms for Designing High-Performance OpenGL Applications" are very interesting, particularly the care we must have when doing our OpenGL drawing in Object-Oriented programs; we could easily incur considerable glVertex overhead, if our code is not properly structured. The little tutorial section "Putting It All Together" includes a detailed optimization of an OpenGL program, "Please Tune Me". It's just the kind of practical stuff that programmers love. Delicious. Very Recommended.

In K&R’s C Tutorial, this feel at ease perception it's also intended:

The only way to learn a new programming language is by writing programs in it. The first program to write is the same for all languages: Print the words hello, world. This is the basic hurdle; to leap over it you have to be able to create the program text somewhere, compile it successfully, load it, run it, and find out where your output went.

This way, "hello, world" should be our first step for pummeling through the new beast (language).

Origins and B detour

In respect to its origins, the Tutorial Introduction to the Language B, by Kernighan, contains the primigenial use of our salutation, under the section "External Variables":

main( ) {
extrn a, b, c;
putchar(a); putchar(b); putchar(c); putchar('!*n');
}
 
a 'hell';
b 'o, w';
c 'orld';

I recognize a lot of familiar things going on here in B:

1. First, our beloved main is already incarnated.
2. Parentheses, brackets, semicolons and the syntax for passing arguments are right in their position.
3. And extrn -> extern.
4. Clearly, that '*n' resembles '\n': notice that the literal passed to putchar is '!*n' (comprised of two characters) and thereby the exact, original output is "hello, world!", with the "!".
5. Interestingly, B is typeless and not suited for numeric computation, so no int, no float.
6. Besides, a, b and c are global variables (static storage), which means they can be initialized. But for any B function being able to access such global variables, use of extrn declaration is mandatory... delightful. Now, albeit the language does not include a mechanism for explicit types, the three variables in the example are initialized to character constants, which in B are single-quoted and can have from one to four ascii characters (in C a character constant is formed by enclosing a single character from the representable character set within single quotation marks). By the way, the upper bound of four characters is a hardware restriction, as Stephen Johnson points out in the Users' Reference to B on MH-TSS:

A character constant is represented by ' followed by one or more characters (possibly escaped) followed by another '. It has an rvalue equal to the value of the characters packed and right adjusted, with zero fill. Obviously, the number of characters in a character constant is a machine dependent quantity; on the H6070, up to four characters are allowed.

B looks a lot like C, and had its roots in an older language called BCPL. One of its authors, Ken Thompson, when asked if B was a subset of BCPL, answered this:

It wasn't a subset. It was almost exactly the same. It was a interpreter instead of a compiler. It had two passes. One went into intermediate language and which one was the interpreter of the intermediate language. Dennis wrote a compiler for B, that worked out of the intermediate language. It was very portable and in less than a day you could get very versatile (not clear). Typically the interpreter was a set macros for your interpreter, they were very field orientated and you just define these macros with these fields and then write a little interpreter that would switch the set routines, and you had to write about twenty three-line routines, and it would run. And it was very small, very clean. It was the same language as BCPL, it looked completely different, syntactically it was, you know, a redo. The semantics was exactly the same as BCPL. And in fact the syntax of it was, if you looked at, you didn't look too close, you would say it was C. Because in fact it was C, without types. There's no word like interchar or struct or anything like that. The word for... There was a word for extern, which means to declare an external thing. There was a word auto, which declared an auto thing.

"Dennis" of course is the other author (and C's creator), Dennis Ritchie. Chapter 1 of The C Programming Language by Kernighan and Ritchie, includes the clearer version:

main()
{
printf("hello, world\n");
}

Now the compiler does more things for you. Good.

Reminiscences

Personally, by reading "hello, world", I evoke orange and warm afternoons, with my eyes strained (and soothed) by code. Nice, and overly inefficient Pascal code. In some images, a few BASIC snippets interleave, but those are not that nice to remember That was not too long ago. I had to complete projects and projects in Pascal for some undergraduate courses, which amounted to lots of tangled pasta. Lovely functions and procedures which required scrolling several pages in order to reach the closing end. Today, I wonder how I was able to bear all that insanely long units. Miracles of youth. I do remember having one of this procedures for drawing a primitive text-mode GUI, based on ALT +196 and ALT + 179: Write('─') and Write('│'). Thanks Turbo Pascal, for so much blessings. Such procedure was flooded with this:

{ Draw a line }
For Loop := 1 To 80 Do
Write('─');

You've gotta love the obnoxious formatting (including the capitalization of To and Do), the dumb comment, the shining constants, and the good programming practice that such For-flooded procedures are. And for clarity, I omitted that such For was inside a super-nested If. Beautiful. Undoubtedly, spaghetti code was my premature approach to cryptography. That code, by the way, reminds me of the First year in college style ("hello, world" GNU joke).

I used to think that Pascal was a cool language (I still do). But other work by Kernighan, again and perhaps unwillingly, made explicit to me that the distance between boys and men was greater than I had thought. Dated April 2, 1981 (incidentally, a few days before I was born) Why Pascal is Not My Favorite Programming Language shed new light on my lag. From there on, Pascal lost some charm, and some of my spare time. But I would not say it's not my favorite language... I'd prefer to say that it's one of my favorite languages, with C being the most liked (so far). The inconsistencies of affection...

A little homage to a great buddy, and first post. "hello, world".