What do the pseudo-ops in Minix assembly code mean?
An ACK assembly file can have a number of sections. Things
declared in the same section are collected together by the loader
in the order they are found in an assembly file and in the order
the object files are loaded together.
Sections get meaning once they are put in a Minix binary.
Section 0 (usually named .text) contains program code and is
put in the code segment, section 1 (.rom) is read-only data
and is put in the data segment, and so are section 2 (.data)
for read-write data and section 3 (.bss) for read-write data
initialized to zero.
The ACK binary to Minix binary converter (cv) will
complain if there are nonzero objects in the .bss section,
but it doesn't care if there's code in .rom/.data, or
data in .text.
With .define a label is turned into a global variable
that other files can use, otherwise it stays local to the assembly
file it is in. With .extern one can import a global label,
but the assembler seems to do that automatically anyway.
With .comm you can put a label on a bunch of zeros. This
is useful in the .bss section. I haven't found a difference
between ".comm junk, 10" and "junk: .space 100".
With .align you can insert the number of zeros needed to
align '.' (the address where stuff is put) to a given
multiple. Objects bigger than a byte should be aligned to multiples
of 2 or 4 bytes. Otherwise it will be slow on 386 descendants,
cause alignment fault messages under Minix-vmd on a 486+, and crash
horribly on processors other than the 386.
With .data you can assemble 1, 2 or 4 byte sized
numbers. With '.ascii "xyz"', and '.asciz "xyz"' you
can do the same as with .data1 120, 121, 122 and .data1
120, 121, 122, 0.
At the beginning of the code there is a line: ".sect .text;
.sect .data; .sect .bss". Or there is ".sect .text
begtext:". What do these mean? In the code ".sect .text"
shows up again. What does this mean? What is the explanation of the
segments in Minix assembly code?
A new section name opens up a new section. By naming all
sections in the first line you can be sure that the names are tied
to the proper section numbers.
How are comments indicated?
The comment character is '!'. The C preprocessor is run
on an assembly file if the very first character is a '#'. If
so then the "/*... */" comment characters also work,
because the C preprocessor removes C comments. The quote characters
(', ") are a bit of a problem, because the
preprocessor wants them to match. This is why you see '`'
(backquote) used in comments sometimes where one would normally use
a ''' (single quote).
I've more or less figured this out on my own with no more
information than the rest of you have. When I found a few meagre
manual pages on this in the ACK tree they told me nothing more than
I had already figured out myself. What helps are good Intel manuals
(I got the Pentium Pro set), a bit of imagination on how the ACK
assembler would encode the instructions and then simply trying.
Inconsistency in syntax
From: email@example.com (Sam)
Subject: assembly syntax inconsistency in MINIX.
Date: 31 May 2004 19:42:42 -0700
I was reading two different MINIX assembly files, masterboot.s and
mpx386.s. I then came across some differences between the assembly
syntax used in each files.
In mpx386.s, each section starts with .sect followed by the section
name. For example, a text section starts with .sect .text
However in masterboot.s, a text section starts with just .text
MASTERBOOT.S | MPX386.s
.text | .sect .text
.data | .sect .data
And also, the pound sign(#) is used to indicate an immediate data in
masterboot.s whereas using a pound sign(#) in mpx386.s gives you an
I guess minix compiler understands both syntax. Can anyone tell me why
there are two different ways to start a section?
From: firstname.lastname@example.org (Kees J Bot)
Subject: Re: assembly syntax inconsistency in MINIX.
Date: Tue, 1 Jun 2004 12:18:58 +0200
There's that, and there's this:
mov ax, #10 | mov ax, 10
mov ax, variable | mov ax, (variable)
The syntax for the 16-bit assembler under the 16-bit version was changed
to be like Xenix or something. I have no idea why.
The 32-bit assembler uses the syntax on the right, both with 8086 and
386 input. I had to make an assembly syntax converter to allow this
assembler to process the Xenix syntax. The -Was-ncc option tells the
compiler driver that the assembly input is the "new cc" syntax. (Yes,
there's also an "old cc" syntax. Luckily we buried that.)
Kees J. Bot
Computer Science Dept.
Amsterdam, The Netherlands
Modified 12 March 2003