Next Chapter | Previous Chapter | Contents | Index
NASM contains a powerful macro processor, which supports conditional
assembly, multi-level file inclusion, two forms of macro (single-line and
multi-line), and a `context stack' mechanism for extra macro power.
Preprocessor directives all begin with a
sign.
The preprocessor collapses all lines which end with a backslash (\) character into a single line. Thus:
%define THIS_VERY_LONG_MACRO_NAME_IS_DEFINED_TO \ THIS_VALUE
will work like a single-line macro without the backslash-newline sequence.
%define
Single-line macros are defined using the
preprocessor directive. The definitions
work in a similar way to C; so you can do things like
%define ctrl 0x1F & %define param(a,b) ((a)+(a)*(b)) mov byte [param(2,ebx)], ctrl 'D'
which will expand to
mov byte [(2)+(2)*(ebx)], 0x1F & 'D'
When the expansion of a single-line macro contains tokens which invoke another macro, the expansion is performed at invocation time, not at definition time. Thus the code
%define a(x) 1+b(x) %define b(x) 2*x mov ax,a(8)
will evaluate in the expected way to
, even though the macro
wasn't defined at the time of definition of
.
Macros defined with
are case
sensitive: after
, only
will expand to
:
or
will not. By
using
instead of
(the `i' stands for `insensitive') you
can define all the case variants of a macro at once, so that
would cause
,
,
,
and so on all
to expand to
.
There is a mechanism which detects when a macro call has occurred as a result of a previous expansion of the same macro, to guard against circular references and infinite loops. If this happens, the preprocessor will only expand the first occurrence of the macro. Hence, if you code
%define a(x) 1+a(x) mov ax,a(3)
the macro
will expand once, becoming
, and will then expand no further. This
behaviour can be useful: see section
9.1 for an example of its use.
You can overload single-line macros: if you write
%define foo(x) 1+x %define foo(x,y) 1+x*y
the preprocessor will be able to handle both types of macro call, by
counting the parameters you pass; so
will
become
whereas
will become
. However, if you define
%define foo bar
then no other definition of
will be
accepted: a macro with no parameters prohibits the definition of the same
name as a macro with parameters, and vice versa.
This doesn't prevent single-line macros being redefined: you can perfectly well define a macro with
%define foo bar
and then re-define it later in the same source file with
%define foo baz
Then everywhere the macro
is invoked, it
will be expanded according to the most recent definition. This is
particularly useful when defining single-line macros with
(see section
4.1.7).
You can pre-define single-line macros using the `-d' option on the NASM command line: see section 2.1.18.
%define
: %xdefine
To have a reference to an embedded single-line macro resolved at the
time that the embedding macro is defined, as opposed to when the
embedding macro is expanded, you need a different mechanism to the
one offered by
. The solution is to use
, or it's case-insensitive counterpart
.
Suppose you have the following code:
%define isTrue 1 %define isFalse isTrue %define isTrue 0 val1: db isFalse %define isTrue 1 val2: db isFalse
In this case,
is equal to 0, and
is equal to 1. This is because, when a
single-line macro is defined using
, it is
expanded only when it is called. As
expands to
, the expansion will be the
current value of
. The first time it is
called that is 0, and the second time it is 1.
If you wanted
to expand to the value
assigned to the embedded macro
at the time
that
was defined, you need to change the
above code to use
.
%xdefine isTrue 1 %xdefine isFalse isTrue %xdefine isTrue 0 val1: db isFalse %xdefine isTrue 1 val2: db isFalse
Now, each time that
is called, it
expands to 1, as that is what the embedded macro
expanded to at the time that
was defined.
%[...]
The
construct can be used to expand
macros in contexts where macro expansion would otherwise not occur,
including in the names other macros. For example, if you have a set of
macros named
,
and
, you
could write:
mov ax,Foo%[__BITS__] ; The Foo value
to use the builtin macro
(see
section 4.12.5) to automatically select
between them. Similarly, the two statements:
%xdefine Bar Quux ; Expands due to %xdefine %define Bar %[Quux] ; Expands due to %[...]
have, in fact, exactly the same effect.
concatenates to adjacent tokens in the
same way that multi-line macro parameters do, see
section 4.3.9 for details.
%+
Individual tokens in single line macros can be concatenated, to produce longer tokens for later processing. This can be useful if there are several similar macros that perform similar functions.
Please note that a space is required after
,
in order to disambiguate it from the syntax
used in multiline macros.
As an example, consider the following:
%define BDASTART 400h ; Start of BIOS data area
struc tBIOSDA ; its structure .COM1addr RESW 1 .COM2addr RESW 1 ; ..and so on endstruc
Now, if we need to access the elements of tBIOSDA in different places, we can end up with:
mov ax,BDASTART + tBIOSDA.COM1addr mov bx,BDASTART + tBIOSDA.COM2addr
This will become pretty ugly (and tedious) if used in many places, and can be reduced in size significantly by using the following macro:
; Macro to access BIOS variables by their names (from tBDA):
%define BDA(x) BDASTART + tBIOSDA. %+ x
Now the above code can be written as:
mov ax,BDA(COM1addr) mov bx,BDA(COM2addr)
Using this feature, we can simplify references to a lot of macros (and, in turn, reduce typing errors).
%?
and %??
The special symbols
and
can be used to reference the macro name
itself inside a macro expansion, this is supported for both single-and
multi-line macros.
refers to the macro name as
invoked, whereas
refers to the macro
name as declared. The two are always the same for case-sensitive
macros, but for case-insensitive macros, they can differ.
For example:
%idefine Foo mov %?,%?? foo FOO
will expand to:
mov foo,Foo mov FOO,Foo
The sequence:
%idefine keyword $%?
can be used to make a keyword "disappear", for example in case a new instruction has been used as a label in older code. For example:
%idefine pause $%? ; Hide the PAUSE instruction
%undef
Single-line macros can be removed with the
directive. For example, the following
sequence:
%define foo bar %undef foo mov eax, foo
will expand to the instruction
,
since after
the macro
is no longer defined.
Macros that would otherwise be pre-defined can be undefined on the command-line using the `-u' option on the NASM command line: see section 2.1.19.
%assign
An alternative way to define single-line macros is by means of the
command (and its case-insensitive
counterpart
, which differs from
in exactly the same way that
differs from
).
is used to define single-line macros
which take no parameters and have a numeric value. This value can be
specified in the form of an expression, and it will be evaluated once, when
the
directive is processed.
Like
, macros defined using
can be re-defined later, so you can do
things like
%assign i i+1
to increment the numeric value of a macro.
is useful for controlling the
termination of
preprocessor loops: see
section 4.5 for an example of this. Another use
for
is given in
section 8.4 and
section 9.1.
The expression passed to
is a critical
expression (see section 3.8), and
must also evaluate to a pure number (rather than a relocatable reference
such as a code or data address, or anything involving a register).
%defstr
, and its case-insensitive counterpart
, define or redefine a single-line macro
without parameters but converts the entire right-hand side, after macro
expansion, to a quoted string before definition.
For example:
%defstr test TEST
is equivalent to
%define test 'TEST'
This can be used, for example, with the
construct (see section 4.10.2):
%defstr PATH %!PATH ; The operating system PATH variable
%deftok
, and its case-insensitive counterpart
, define or redefine a single-line macro
without parameters but converts the second parameter, after string
conversion, to a sequence of tokens.
For example:
%deftok test 'TEST'
is equivalent to
%define test TEST
It's often useful to be able to handle strings in macros. NASM supports a few simple string handling macro operators from which more complex operations can be constructed.
All the string operators define or redefine a value (either a string or
a numeric value) to a single-line macro. When producing a string value, it
may change the style of quoting of the input string or strings, and
possibly use
-escapes inside
-quoted strings.
%strcat
The
operator concatenates quoted
strings and assign them to a single-line macro.
For example:
%strcat alpha "Alpha: ", '12" screen'
... would assign the value
to
. Similarly:
%strcat beta '"foo"\', "'bar'"
... would assign the value
to
.
The use of commas to separate strings is permitted but optional.
%strlen
The
operator assigns the length of a
string to a macro. For example:
%strlen charcnt 'my string'
In this example,
would receive the
value 9, just as if an
had been used. In
this example,
was a literal string
but it could also have been a single-line macro that expands to a string,
as in the following example:
%define sometext 'my string' %strlen charcnt sometext
As in the first case, this would result in
being assigned the value of 9.
%substr
Individual letters or substrings in strings can be extracted using the
operator. An example of its use is
probably more useful than the description:
%substr mychar 'xyzw' 1 ; equivalent to %define mychar 'x' %substr mychar 'xyzw' 2 ; equivalent to %define mychar 'y' %substr mychar 'xyzw' 3 ; equivalent to %define mychar 'z' %substr mychar 'xyzw' 2,2 ; equivalent to %define mychar 'yz' %substr mychar 'xyzw' 2,-1 ; equivalent to %define mychar 'yzw' %substr mychar 'xyzw' 2,-2 ; equivalent to %define mychar 'yz'
As with
(see
section 4.2.2), the first parameter is the
single-line macro to be created and the second is the string. The third
parameter specifies the first character to be selected, and the optional
fourth parameter preceeded by comma) is the length. Note that the first
index is 1, not 0 and the last index is equal to the value that
would assign given the same string. Index
values out of range result in an empty string. A negative length means
"until N-1 characters before the end of string", i.e.
means until end of string,
until one character before, etc.
%macro
Multi-line macros are much more like the type of macro seen in MASM and TASM: a multi-line macro definition in NASM looks something like this.
%macro prologue 1 push ebp mov ebp,esp sub esp,%1 %endmacro
This defines a C-like function prologue as a macro: so you would invoke the macro with a call such as
myfunc: prologue 12
which would expand to the three lines of code
myfunc: push ebp mov ebp,esp sub esp,12
The number
after the macro name in the
line defines the number of parameters the
macro
expects to receive. The use of
inside the macro definition refers to the
first parameter to the macro call. With a macro taking more than one
parameter, subsequent parameters would be referred to as
,
and so on.
Multi-line macros, like single-line macros, are case-sensitive, unless
you define them using the alternative directive
.
If you need to pass a comma as part of a parameter to a multi-line macro, you can do that by enclosing the entire parameter in braces.  This time, no exception is made for macros with no parameters at all. So you could define
%macro prologue 0 push ebp mov ebp,esp %endmacro
to define an alternative form of the function prologue which allocates no local stack space.
Sometimes, however, you might want to `overload' a machine instruction; for example, you might want to define
%macro push 2 push %1 push %2 %endmacro
so that you could code
push ebx ; this line is not a macro call push eax,ecx ; but this one is
Ordinarily, NASM will give a warning for the first of the above two
lines, since
is now defined to be a macro,
and is being invoked with a number of parameters for which no definition
has been given. The correct code will still be generated, but the assembler
will give a warning. This warning can be disabled by the use of the
command-line option (see
section 2.1.24).
NASM allows you to define labels within a multi-line macro definition in
such a way as to make them local to the macro call: so calling the same
macro multiple times will use a different label each time. You do this by
prefixing
to the label name. So you can invent
an instruction which executes a
if the
flag is set by doing this:
%macro retz 0 jnz %%skip ret %%skip: %endmacro
You can call this macro as many times as you want, and every time you
call it NASM will make up a different `real' name to substitute for the
label
. The names NASM invents are of the
form
, where the number 2345 changes
with every macro call. The
prefix prevents
macro-local labels from interfering with the local label mechanism, as
described in section 3.9. You
should avoid defining your own labels in this form (the
prefix, then a number, then another period)
in case they interfere with macro-local labels.
Occasionally it is useful to define a macro which lumps its entire command line into one parameter definition, possibly after extracting one or two smaller parameters from the front. An example might be a macro to write a text string to a file in MS-DOS, where you might want to be able to write
writefile [filehandle],"hello, world",13,10
NASM allows you to define the last parameter of a macro to be greedy, meaning that if you invoke the macro with more parameters than it expects, all the spare parameters get lumped into the last defined one along with the separating commas. So if you code:
%macro writefile 2+ jmp %%endstr %%str: db %2 %%endstr: mov dx,%%str mov cx,%%endstr-%%str mov bx,%1 mov ah,0x40 int 0x21 %endmacro
then the example call to
above will
work as expected: the text before the first comma,
, is used as the first macro
parameter and expanded when
is referred to,
and all the subsequent text is lumped into
and
placed after the
.
The greedy nature of the macro is indicated to NASM by the use of the
sign after the parameter count on the
line.
If you define a greedy macro, you are effectively telling NASM how it
should expand the macro given any number of parameters from the
actual number specified up to infinity; in this case, for example, NASM now
knows what to do when it sees a call to
with 2, 3, 4 or more parameters. NASM will take this into account when
overloading macros, and will not allow you to define another form of
taking 4 parameters (for example).
Of course, the above macro could have been implemented as a non-greedy macro, in which case the call to it would have had to look like
writefile [filehandle], {"hello, world",13,10}
NASM provides both mechanisms for putting commas in macro parameters, and you choose which one you prefer for each macro definition.
See section 6.3.1 for a better way to write the above macro.
NASM allows you to expand parameters via special construction
where
is the
first parameter index and
is the last. Any
index can be either negative or positive but must never be zero.
For example
%macro mpar 1-* db %{3:5} %endmacro mpar 1,2,3,4,5,6
expands to
range.
Even more, the parameters can be reversed so that
%macro mpar 1-* db %{5:3} %endmacro mpar 1,2,3,4,5,6
expands to
range.
But even this is not the last. The parameters can be addressed via negative indices so NASM will count them reversed. The ones who know Python may see the analogue here.
%macro mpar 1-* db %{-1:-3} %endmacro mpar 1,2,3,4,5,6
expands to
range.
Note that NASM uses comma to separate parameters being expanded.
By the way, here is a trick - you might use the index
} which gives you the last argument passed
to a macro.
NASM also allows you to define a multi-line macro with a range of allowable parameter counts. If you do this, you can specify defaults for omitted parameters.  writefile 2,%1 mov ax,0x4c01 int 0x21 %endmacro
This macro (which makes use of the
macro defined in section 4.3.3) can be called
with an explicit error message, which it will display on the error output
stream before exiting, or it can be called with no parameters, in which
case it will use the default error message supplied in the macro
definition.
In general, you supply a minimum and maximum number of parameters for a macro of this type; the minimum number of parameters are then required in the macro call, and then you provide defaults for the optional ones. So if a macro definition began with the line
%macro foobar 1-3 eax,[ebx+2]
then it could be called with between one and three parameters, and
would always be taken from the macro call.
, if not specified by the macro call, would
default to
, and
if not specified would default to
.
You can provide extra information to a macro by providing too many default parameters:
%macro quux 1 something
This will trigger a warning by default; see
section 2.1.24 for more
information. When
is invoked, it receives
not one but two parameters.
can be
referred to as
. The difference between passing
this way and writing
in the macro body is that with this way
is evaluated when the macro is defined,
not when it is expanded.
You may omit parameter defaults from the macro definition, in which case
the parameter default is taken to be blank. This can be useful for macros
which can take a variable number of parameters, since the
token (see section
4.3.6) allows you to determine how many parameters were really passed
to the macro call.
This defaulting mechanism can be combined with the greedy-parameter
mechanism; so the
macro above could be made
more powerful, and more useful, by changing the first line of the
definition to
%macro die 0-1+ "Painful program death has occurred.",13,10
The maximum parameter count can be infinite, denoted by
. In this case, of course, it is impossible to
provide a full set of default parameters. Examples of this usage
are shown in section 4.3.8.
%0
: Macro Parameter CounterThe parameter reference
will return a
numeric constant giving the number of parameters received, that is, if
is n then
n is the
last parameter.
is mostly useful for macros
that can take a variable number of parameters. It can be used as an
argument to
(see
section 4.5) in order to iterate through all the
parameters of a macro. Examples are given in
section 4.3.8.
%00
: Label Preceeding Macro
will return the label preceeding the macro
invocation, if any. The label must be on the same line as the macro
invocation, may be a local label (see
section 3.9), and need not end in a
colon.
%rotate
: Rotating Macro ParametersUnix shell programmers will be familiar with the
shell command, which allows the arguments
passed to a shell script (referenced as
,
and so on) to be moved left by one place, so
that the argument previously referenced as
becomes available as
, and the argument
previously referenced as
is no longer
available at all.
NASM provides a similar mechanism, in the form of
. As its name suggests, it differs from
the Unix
in that no parameters are lost:
parameters rotated off the left end of the argument list reappear on the
right, and vice versa.
is invoked with a single numeric
argument (which may be an expression). The macro parameters are rotated to
the left by that many places. If the argument to
is negative, the macro parameters are
rotated to the right.
So a pair of macros to save and restore a set of registers might work as follows:
%macro multipush 1-* %rep %0 push %1 %rotate 1 %endrep %endmacro
This macro invokes the
instruction on
each of its arguments in turn, from left to right. It begins by pushing its
first argument,
, then invokes
to move all the arguments one place to
the left, so that the original second argument is now available as
. Repeating this procedure as many times as
there were arguments (achieved by supplying
as
the argument to
) causes each argument in
turn to be pushed.
Note also the use of
as the maximum
parameter count, indicating that there is no upper limit on the number of
parameters you may supply to the
macro.
It would be convenient, when using this macro, to have a
equivalent, which didn't require the
arguments to be given in reverse order. Ideally, you would write the
macro call, then cut-and-paste the line
to where the pop needed to be done, and change the name of the called macro
to
, and the macro would take care of
popping the registers in the opposite order from the one in which they were
pushed.
This can be done by the following definition:
%macro multipop 1-* %rep %0 %rotate -1 pop %1 %endrep %endmacro
This macro begins by rotating its arguments one place to the
right, so that the original last argument appears as
. This is then popped, and the arguments are
rotated right again, so the second-to-last argument becomes
. Thus the arguments are iterated through in
reverse order.
NASM can concatenate macro parameters and macro indirection constructs on to other text surrounding them. This allows you to declare a family of symbols, for example, in a macro definition. If, for example, you wanted to generate a table of key codes along with offsets into the table, you could code something like
%macro keytab_entry 2 keypos%1 equ $-keytab db %2 %endmacro keytab: keytab_entry F1,128+1 keytab_entry F2,128+2 keytab_entry Return,13
which would expand to
keytab: keyposF1 equ $-keytab db 128+1 keyposF2 equ $-keytab db 128+2 keyposReturn equ $-keytab db 13
You can just as easily concatenate text on to the other end of a macro
parameter, by writing
.
If you need to append a digit to a macro parameter, for example
defining labels
and
when passed the parameter
, you can't code
because that would be taken as the eleventh macro parameter. Instead, you
must code
, which will separate the first
(giving the number of the macro parameter) from
the second (literal text to be concatenated to the parameter).
This concatenation can also be applied to other preprocessor in-line
objects, such as macro-local labels (section
4.3.2) and context-local labels (section
4.7.2). In all cases, ambiguities in syntax can be resolved by
enclosing everything after the
sign and before
the literal text in braces: so
concatenates the text
to the end of the real
name of the macro-local label
. (This is
unnecessary, since the form NASM uses for the real names of macro-local
labels means that the two usages
and
would both expand to the same thing
anyway; nevertheless, the capability is there.)
The single-line macro indirection construct,
(section
4.1.3), behaves the same way as macro parameters for the purpose of
concatenation.
See also the
operator,
section 4.1.4.
NASM can give special treatment to a macro parameter which contains a
condition code. For a start, you can refer to the macro parameter
by means of the alternative syntax
, which informs NASM that this macro parameter
is supposed to contain a condition code, and will cause the preprocessor to
report an error message if the macro is called with a parameter which is
not a valid condition code.
Far more usefully, though, you can refer to the macro parameter by means
of
, which NASM will expand as the
inverse condition code. So the
macro defined in section 4.3.2 can be replaced
by a general conditional-return macro like this:
%macro retc 1 j%-1 %%skip ret %%skip: %endmacro
This macro can now be invoked using calls like
, which will cause the conditional-jump
instruction in the macro expansion to come out as
, or
which
will make the jump a
.
The
macro-parameter reference is quite
happy to interpret the arguments
and
as valid condition codes; however,
will report an error if passed either of
these, because no inverse condition code exists.
When NASM is generating a listing file from your program, it will generally expand multi-line macros by means of writing the macro call and then listing each line of the expansion. This allows you to see which instructions in the macro expansion are generating what code; however, for some macros this clutters the listing up unnecessarily.
NASM therefore provides the
qualifier,
which you can include in a macro definition to inhibit the expansion of the
macro in the listing file. The
qualifier
comes directly after the number of parameters, like this:
%macro foo 1.nolist
Or like this:
%macro bar 1-5+.nolist a,b,c,d,e,f,g,h
%unmacro
Multi-line macros can be removed with the
directive. Unlike the
directive, however,
takes an argument specification, and
will only remove exact matches with that argument specification.
For example:
%macro foo 1-3 ; Do something %endmacro %unmacro foo 1-3
removes the previously defined macro
, but
%macro bar 1-3 ; Do something %endmacro %unmacro bar 1
does not remove the macro
, since
the argument specification does not match exactly.
Similarly to the C preprocessor, NASM allows sections of a source file to be assembled only if certain conditions are met. The general syntax of this feature looks like this:
%if<condition> ; some code which only appears if <condition> is met %elif<condition2> ; only appears if <condition> is not met but <condition2> is %else ; this appears if neither <condition> nor <condition2> was met %endif
The inverse forms
and
are also supported.
The
clause is optional, as is the
clause. You can have more than one
clause as well.
There are a number of variants of the
directive. Each has its corresponding
,
, and
directives; for example, the equivalents to the
directive are
,
, and
.
%ifdef
: Testing Single-Line Macro ExistenceBeginning a conditional-assembly block with the line
will assemble the subsequent code
if, and only if, a single-line macro called
is defined. If not, then the
and
blocks (if any) will be processed instead.
For example, when debugging a program, you might want to write code such as
; perform some function %ifdef DEBUG writefile 2,"Function performed successfully",13,10 %endif ; go and do something else
Then you could use the command-line option
to create a version of the program which
produced debugging messages, and remove the option to generate the final
release version of the program.
You can test for a macro not being defined by using
instead of
. You can also test for macro definitions
in
blocks by using
and
.
%ifmacro
: Testing Multi-Line Macro ExistenceThe
directive operates in the same
way as the
directive, except that it
checks for the existence of a multi-line macro.
For example, you may be working with a large project and not have control over the macros in a library. You may want to create a macro with one name if it doesn't already exist, and another name if one with that name does exist.
The
is considered true if defining a
macro with the given name and number of arguments would cause a definitions
conflict. For example:
%ifmacro MyMacro 1-3 %error "MyMacro 1-3" causes a conflict with an existing macro. %else %macro MyMacro 1-3 ; insert code to define the macro %endmacro %endif
This will create the macro "MyMacro 1-3" if no macro already exists which would conflict with it, and emits a warning if there would be a definition conflict.
You can test for the macro not existing by using the
instead of
. Additional tests can be performed in
blocks by using
and
.
%ifctx
: Testing the Context StackThe conditional-assembly construct
will
cause the subsequent code to be assembled if and only if the top context on
the preprocessor's context stack has the same name as one of the arguments.
As with
, the inverse and
forms
,
and
are also supported.
For more details of the context stack, see
section 4.7. For a sample use of
, see section
4.7.6.
%if
: Testing Arbitrary Numeric ExpressionsThe conditional-assembly construct
will cause the subsequent code to be assembled if and only if the value of
the numeric expression
is non-zero. An
example of the use of this feature is in deciding when to break out of a
preprocessor loop: see
section 4.5 for a detailed example.
The expression given to
, and its
counterpart
, is a critical expression (see
section 3.8).
extends the normal NASM expression syntax,
by providing a set of relational operators which are not normally available
in expressions. The operators
,
,
,
,
and
test equality, less-than, greater-than,
less-or-equal, greater-or-equal and not-equal respectively. The C-like
forms
and
are
supported as alternative forms of
and
.  These work like the C
logical operators (although C has no logical XOR), in that they always
return either 0 or 1, and treat any non-zero input as 1 (so that
, for example, returns 1 if exactly one of its
inputs is zero, and 0 otherwise). The relational operators also return 1
for true and 0 for false.
Like other
constructs,
has a counterpart
, and negative forms
and
.
%ifidn
and %ifidni
: Testing Exact Text IdentityThe construct
will cause
the subsequent code to be assembled if and only if
and
, after
expanding single-line macros, are identical pieces of text. Differences in
white space are not counted.
is similar to
, but is case-insensitive.
For example, the following macro pushes a register or number on the
stack, and allows you to treat
as a real
register:
%macro pushparam 1 %ifidni %1,ip call %%label %%label: %else push %1 %endif %endmacro
Like other
constructs,
has a counterpart
, and negative forms
and
.
Similarly,
has counterparts
,
and
.
%ifid
, %ifnum
, %ifstr
: Testing Token TypesSome macros will want to perform different tasks depending on whether they are passed a number, a string, or an identifier. For example, a string output macro might want to be able to cope with being passed either a string constant or a pointer to an existing string.
The conditional assembly construct
,
taking one parameter (which may be blank), assembles the subsequent code if
and only if the first token in the parameter exists and is an identifier.
works similarly, but tests for the token
being a numeric constant;
tests for it
being a string.
For example, the
macro defined in
section 4.3.3 can be extended to take
advantage of
in the following fashion:
%macro writefile 2-3+ %ifstr %2 jmp %%endstr %if %0 = 3 %%str: db %2,%3 %else %%str: db %2 %endif %%endstr: mov dx,%%str mov cx,%%endstr-%%str %else mov dx,%2 mov cx,%3 %endif mov bx,%1 mov ah,0x40 int 0x21 %endmacro
Then the
macro can cope with being
called in either of the following two ways:
writefile [file], strpointer, length writefile [file], "hello", 13, 10
In the first,
is used as the
address of an already-declared string, and
is used as its length; in the second, a string is given to the macro, which
therefore declares it itself and works out the address and length for
itself.
Note the use of
inside the
: this is to detect whether the macro was
passed two arguments (so the string would be a single string constant, and
would be adequate) or more (in which case,
all but the first two would be lumped together into
, and
would
be required).
The usual
...,
..., and
...
versions exist for each of
,
and
.
%iftoken
: Test for a Single TokenSome macros will want to do different things depending on if it is
passed a single token (e.g. paste it to something else using
) versus a multi-token sequence.
The conditional assembly construct
assembles the subsequent code if and only if the expanded parameters
consist of exactly one token, possibly surrounded by whitespace.
For example:
%iftoken 1
will assemble the subsequent code, but
%iftoken -1
will not, since
contains two tokens: the
unary minus operator
, and the number
.
The usual
,
, and
variants are also provided.
%ifempty
: Test for Empty ExpansionThe conditional assembly construct
assembles the subsequent code if and only if the expanded parameters do not
contain any tokens at all, whitespace excepted.
The usual
,
, and
variants are also provided.
%ifenv
: Test If Environment Variable ExistsThe conditional assembly construct
assembles the subsequent code if and only if the environment variable
referenced by the
directive exists.
The usual
,
, and
variants are also provided.
Just as for
the argument should
be written as a string if it contains characters that would not be legal in
an identifier. See section 4.10.2.
%rep
NASM's
prefix, though useful, cannot be
used to invoke a multi-line macro multiple times, because it is processed
by NASM after macros have already been expanded. Therefore NASM provides
another form of loop, this time at the preprocessor level:
.
The directives
and
(
takes a
numeric argument, which can be an expression;
takes no arguments) can be used to
enclose a chunk of code, which is then replicated as many times as
specified by the preprocessor:
%assign i 0 %rep 64 inc word [table+2*i] %assign i i+1 %endrep
This will generate a sequence of 64
instructions, incrementing every word of memory from
to
.
For more complex termination conditions, or to break out of a repeat
loop part way along, you can use the
directive to terminate the loop, like this:
fibonacci: %assign i 0 %assign j 1 %rep 100 %if j > 65535 %exitrep %endif dw j %assign k j+i %assign i j %assign j k %endrep fib_number equ ($-fibonacci)/2
This produces a list of all the Fibonacci numbers that will fit in 16
bits. Note that a maximum repeat count must still be given to
. This is to prevent the possibility of NASM
getting into an infinite loop in the preprocessor, which (on multitasking
or multi-user systems) would typically cause all the system memory to be
gradually used up and other applications to start crashing.
Note a maximum repeat count is limited by 62 bit number, though it is hardly possible that you ever need anything bigger.
These commands allow you to split your sources into multiple files.
%include
: Including Other FilesUsing, once again, a very similar syntax to the C preprocessor, NASM's
preprocessor lets you include other source files into your code. This is
done by the use of the
directive:
%include "macros.mac"
will include the contents of the file
into the source file containing the
directive.
Include files are searched for in the current directory (the directory
you're in when you run NASM, as opposed to the location of the NASM
executable or the location of the source file), plus any directories
specified on the NASM command line using the
option.
The standard C idiom for preventing a file being included more than once
is just as applicable in NASM: if the file
has the form
%ifndef MACROS_MAC %define MACROS_MAC ; now define some macros %endif
then including the file more than once will not cause errors, because
the second time the file is included nothing will happen because the macro
will already be defined.
You can force a file to be included even if there is no
directive that explicitly includes it,
by using the
option on the NASM command line
(see section 2.1.17).
%pathsearch
: Search the Include PathThe
directive takes a single-line
macro name and a filename, and declare or redefines the specified
single-line macro to be the include-path-resolved version of the filename,
if the file exists (otherwise, it is passed unchanged.)
For example,
%pathsearch MyFoo "foo.bin"
... with
in the include path may end
up defining the macro
to be
.
%depend
: Add Dependent FilesThe
directive takes a filename and
adds it to the list of files to be emitted as dependency generation when
the
options and its relatives (see
section 2.1.4) are used. It
produces no output.
This is generally used in conjunction with
. For example, a simplified version of
the standard macro wrapper for the
directive looks like:
%imacro incbin 1-2+ 0 %pathsearch dep %1 %depend dep incbin dep,%2 %endmacro
This first resolves the location of the file into the macro
, then adds it to the dependency lists, and
finally issues the assembler-level
directive.
%use
: Include Standard Macro PackageThe
directive is similar to
, but rather than including the contents
of a file, it includes a named standard macro package. The standard macro
packages are part of NASM, and are described in
chapter 5.
Unlike the
directive, package names
for the
directive do not require quotes, but
quotes are permitted. In NASM 2.04 and 2.05 the unquoted form would be
macro-expanded; this is no longer true. Thus, the following lines are
equivalent:
%use altreg %use 'altreg'
Standard macro packages are protected from multiple inclusion. When a
standard macro package is used, a testable single-line macro of the form
package
is also defined, see section 4.12.8.
Having labels that are local to a macro definition is sometimes not
quite powerful enough: sometimes you want to be able to share labels
between several macro calls. An example might be a
...
loop,
in which the expansion of the
macro would
need to be able to refer to a label which the
macro had defined. However, for such a
macro you would also want to be able to nest these loops.
NASM provides this level of power by means of a context stack.
The preprocessor maintains a stack of contexts, each of which is
characterized by a name. You add a new context to the stack using the
directive, and remove one using
. You can define labels that are local to a
particular context on the stack.
%push
and %pop
: Creating and Removing ContextsThe
directive is used to create a new
context and place it on the top of the context stack.
takes an optional argument, which is the
name of the context. For example:
%push foobar
This pushes a new context called
on the
stack. You can have several contexts on the stack with the same name: they
can still be distinguished. If no name is given, the context is unnamed
(this is normally used when both the
and
the
are inside a single macro definition.)
The directive
, taking one optional
argument, removes the top context from the context stack and destroys it,
along with any labels associated with it. If an argument is given, it must
match the name of the current context, otherwise it will issue an error.
Just as the usage
defines a label which
is local to the particular macro call in which it is used, the usage
is used to define a label which is local to
the context on the top of the context stack. So the
and
example given above could be implemented by means of:
%macro repeat 0 %push repeat %$begin: %endmacro %macro until 1 j%-1 %$begin %pop %endmacro
and invoked by means of, for example,
mov cx,string repeat add cx,3 scasb until e
which would scan every fourth byte of a string in search of the byte in
.
If you need to define, or access, labels local to the context
below the top one on the stack, you can use
, or
for
the context below that, and so on.
NASM also allows you to define single-line macros which are local to a particular context, in just the same way:
%define %$localmac 3
will define the single-line macro
to be local to the top context on the stack. Of course, after a subsequent
, it can then still be accessed by the name
.
Context fall-through lookup (automatic searching of outer contexts) is a feature that was added in NASM version 0.98.03. Unfortunately, this feature is unintuitive and can result in buggy code that would have otherwise been prevented by NASM's error reporting. As a result, this feature has been deprecated. NASM version 2.09 will issue a warning when usage of this deprecated feature is detected. Starting with NASM version 2.10, usage of this deprecated feature will simply result in an expression syntax error.
An example usage of this deprecated feature follows:
%macro ctxthru 0 %push ctx1 %assign %$external 1 %push ctx2 %assign %$internal 1 mov eax, %$external mov eax, %$internal %pop %pop %endmacro
As demonstrated,
is being defined
in the
context and referenced within the
context. With context fall-through lookup,
referencing an undefined context-local macro like this implicitly searches
through all outer contexts until a match is made or isn't found in any
context. As a result,
referenced
within the
context would implicitly use
as defined in
. Most people would expect NASM to issue an
error in this situation because
was
never defined within
and also isn't
qualified with the proper context depth,
.
Here is a revision of the above example with proper context depth:
%macro ctxthru 0 %push ctx1 %assign %$external 1 %push ctx2 %assign %$internal 1 mov eax, %$$external mov eax, %$internal %pop %pop %endmacro
As demonstrated,
is still being
defined in the
context and referenced within
the
context. However, the reference to
within
has been fully qualified with the proper context depth,
, and thus is no longer ambiguous,
unintuitive or erroneous.
%repl
: Renaming a ContextIf you need to change the name of the top context on the stack (in
order, for example, to have it respond differently to
), you can execute a
followed by a
; but this will have the side effect of
destroying all context-local labels and macros associated with the context
that was just popped.
NASM provides the directive
, which
replaces a context with a different name, without touching the
associated macros and labels. So you could replace the destructive code
%pop %push newname
with the non-destructive version
.
This example makes use of almost all the context-stack features,
including the conditional-assembly construct
, to implement a block IF statement as a
set of macros.
%macro if 1 %push if j%-1 %$ifnot %endmacro %macro else 0 %ifctx if %repl else jmp %$ifend %$ifnot: %else %error "expected `if' before `else'" %endif %endmacro %macro endif 0 %ifctx if %$ifnot: %pop %elifctx else %$ifend: %pop %else %error "expected `if' or `else' before `endif'" %endif %endmacro
This code is more robust than the
and
macros given in
section 4.7.2, because it uses conditional
assembly to check that the macros are issued in the right order (for
example, not calling
before
) and issues a
if they're not.
In addition, the
macro has to be able to
cope with the two distinct cases of either directly following an
, or following an
. It achieves this, again, by using
conditional assembly to do different things depending on whether the
context on top of the stack is
or
.
The
macro has to preserve the context on
the stack, in order to have the
referred
to by the
macro be the same as the one defined
by the
macro, but has to change the
context's name so that
will know there was
an intervening
. It does this by the use of
.
A sample usage of these macros might look like:
cmp ax,bx if ae cmp bx,cx if ae mov ax,cx else mov ax,bx endif else cmp ax,cx if ae mov ax,cx endif endif
The block-
macros handle nesting quite
happily, by means of pushing another context, describing the inner
, on top of the one describing the outer
; thus
and
always refer to the last unmatched
or
.
The following preprocessor directives provide a way to use labels to refer to local variables allocated on the stack.
%arg
(see section
4.8.1)
%stacksize
(see
section 4.8.2)
%local
(see section
4.8.3)
%arg
DirectiveThe
directive is used to simplify the
handling of parameters passed on the stack. Stack based parameter passing
is used by many high level languages, including C, C++ and Pascal.
While NASM has macros which attempt to duplicate this functionality (see
section 8.4.5), the syntax is not
particularly convenient to use and is not TASM compatible. Here is an
example which shows the use of
without any
external macros:
some_function: %push mycontext ; save the current context %stacksize large ; tell NASM to use bp %arg i:word, j_ptr:word mov ax,[i] mov bx,[j_ptr] add ax,[bx] ret %pop ; restore original context
This is similar to the procedure defined in
section 8.4.5 and adds the value
in i to the value pointed to by j_ptr and returns the sum in the ax
register. See section 4.7.1 for an explanation
of
and
and the
use of context stacks.
%stacksize
DirectiveThe
directive is used in
conjunction with the
(see
section 4.8.1) and the
(see section
4.8.3) directives. It tells NASM the default size to use for subsequent
and
directives. The
directive takes one
required argument which is one of
,
,
or
.
%stacksize flat
This form causes NASM to use stack-based parameter addressing relative
to
and it assumes that a near form of call
was used to get to this label (i.e. that
is
on the stack).
%stacksize flat64
This form causes NASM to use stack-based parameter addressing relative
to
and it assumes that a near form of call
was used to get to this label (i.e. that
is
on the stack).
%stacksize large
This form uses
to do stack-based parameter
addressing and assumes that a far form of call was used to get to this
address (i.e. that
and
are on the stack).
%stacksize small
This form also uses
to address stack
parameters, but it is different from
because it also assumes that the old value of bp is pushed onto the stack
(i.e. it expects an
instruction). In other
words, it expects that
,
and
are on the
top of the stack, underneath any local space which may have been allocated
by
. This form is probably most useful when
used in combination with the
directive
(see section 4.8.3).
%local
DirectiveThe
directive is used to simplify the
use of local temporary stack variables allocated in a stack frame.
Automatic local variables in C are an example of this kind of variable. The
directive is most useful when used with
the
(see
section 4.8.2 and is also compatible with the
directive (see
section 4.8.1). It allows simplified reference
to variables on the stack which have been allocated typically by using the
instruction. An example of its use is the
following:
silly_swap: %push mycontext ; save the current context %stacksize small ; tell NASM to use bp %assign %$localsize 0 ; see text for explanation %local old_ax:word, old_dx:word enter %$localsize,0 ; see text for explanation mov [old_ax],ax ; swap ax & bx mov [old_dx],dx ; and swap dx & cx mov ax,bx mov dx,cx mov bx,[old_ax] mov cx,[old_dx] leave ; restore old bp ret ; %pop ; restore original context
The
variable is used internally by
the
directive and must be defined
within the current context before the
directive may be used. Failure to do so will result in one expression
syntax error for each
variable declared.
It then may be used in the construction of an appropriately sized ENTER
instruction as shown in the example.
%error
, %warning
, %fatal
The preprocessor directive
will cause
NASM to report an error if it occurs in assembled code. So if other users
are going to try to assemble your source files, you can ensure that they
define the right macros by means of code like this:
%ifdef F1 ; do some setup %elifdef F2 ; do some different setup %else %error "Neither F1 nor F2 was defined." %endif
Then any user who fails to understand the way your code is supposed to be assembled will be quickly warned of their mistake, rather than having to wait until the program crashes on being run and then not knowing what went wrong.
Similarly,
issues a warning, but
allows assembly to continue:
%ifdef F1 ; do some setup %elifdef F2 ; do some different setup %else %warning "Neither F1 nor F2 was defined, assuming F1." %define F1 %endif
and
are issued only on the final assembly pass. This makes them safe to use in
conjunction with tests that depend on symbol values.
terminates assembly immediately,
regardless of pass. This is useful when there is no point in continuing the
assembly further, and doing so is likely just going to cause a spew of
confusing error messages.
It is optional for the message string after
,
or
to be quoted. If it is not, then
single-line macros are expanded in it, which can be used to display more
information to the user. For example:
%if foo > 64 %assign foo_over foo-64 %error foo is foo_over bytes too large %endif
NASM also has preprocessor directives which allow access to information from external sources. Currently they include:
%line
enables NASM to correctly handle the
output of another preprocessor (see section
4.10.1).
%!
enables NASM to read in the value of an
environment variable, which can then be used in your program (see
section 4.10.2).
%line
DirectiveThe
directive is used to notify NASM
that the input line corresponds to a specific line number in another file.
Typically this other file would be an original source file, with the
current NASM input being the output of a pre-processor. The
directive allows NASM to output messages
which indicate the line number of the original source file, instead of the
file that is being read by NASM.
This preprocessor directive is not generally of use to programmers, by
may be of interest to preprocessor authors. The usage of the
preprocessor directive is as follows:
%line nnn[+mmm] [filename]
In this directive,
identifies the line of
the original source file which this line corresponds to.
is an optional parameter which specifies a
line increment value; each line of the input file read in is considered to
correspond to
lines of the original source
file. Finally,
is an optional parameter
which specifies the file name of the original source file.
After reading a
preprocessor directive,
NASM will report all file name and line numbers relative to the values
specified therein.
%!
<env>
: Read an environment variable.The
directive makes it possible
to read the value of an environment variable at assembly time. This could,
for example, be used to store the contents of an environment variable into
a string, which could be used at some other point in your code.
For example, suppose that you have an environment variable
, and you want the contents of
to be embedded in your program. You could do
that as follows:
%defstr FOO %!FOO
See section 4.1.8 for notes on the
directive.
If the name of the environment variable contains non-identifier characters, you can use string quotes to surround the name of the variable, for example:
%defstr C_colon %!'C:'
%comment
The
and
directives are used to specify a
block of commented (i.e. unprocessed) code/text. Everything between
and
will be ignored by the preprocessor.
%comment ; some code, text or data to be ignored %endcomment
NASM defines a set of standard macros, which are already defined when it
starts to process any source file. If you really need a program to be
assembled with no pre-defined macros, you can use the
directive to empty the preprocessor of
everything but context-local preprocessor variables and single-line macros.
Most user-level assembler directives (see chapter 6) are implemented as macros which invoke primitive directives; these are described in chapter 6. The rest of the standard macro set is described here.
The single-line macros
,
,
and
expand to the major, minor,
subminor and patch level parts of the version number of NASM being used.
So, under NASM 0.98.32p1 for example,
would be defined to be 0,
would be defined as 98,
would be defined to 32, and
would be defined as 1.
Additionally, the macro
is
defined for automatically generated snapshot releases only.
__NASM_VERSION_ID__
: NASM Version IDThe single-line macro
expands to a dword integer representing the full version number of the
version of nasm being used. The value is the equivalent to
,
,
and
concatenated to produce a
single doubleword. Hence, for 0.98.32p1, the returned number would be
equivalent to:
dd 0x00622001
or
db 1,32,98,0
Note that the above lines are generate exactly the same code, the second line is used just to give an indication of the order that the separate values will be present in memory.
__NASM_VER__
: NASM Version stringThe single-line macro
expands to
a string which defines the version number of nasm being used. So, under
NASM 0.98.32 for example,
db __NASM_VER__
would expand to
db "0.98.32"
__FILE__
and __LINE__
: File Name and Line NumberLike the C preprocessor, NASM allows the user to find out the file name
and line number containing the current instruction. The macro
expands to a string constant giving the
name of the current input file (which may change through the course of
assembly if
directives are used), and
expands to a numeric constant giving the
current line number in the input file.
These macros could be used, for example, to communicate debugging
information to a macro, since invoking
inside a macro definition (either single-line or multi-line) will return
the line number of the macro call, rather than
definition. So to determine where in a piece of code a crash is
occurring, for example, one could write a routine
, which is passed a line number in
and outputs something like `line 155: still
here'. You could then write a macro
%macro notdeadyet 0 push eax mov eax,__LINE__ call stillhere pop eax %endmacro
and then pepper your code with calls to
until you find the crash point.
__BITS__
: Current BITS ModeThe
standard macro is updated every
time that the BITS mode is set using the
or
directive, where XX is a valid mode
number of 16, 32 or 64.
receives the
specified mode number and makes it globally available. This can be very
useful for those who utilize mode-dependent macros.
__OUTPUT_FORMAT__
: Current Output FormatThe
standard macro holds the
current Output Format, as given by the
option
or NASM's default. Type
for a list.
%ifidn __OUTPUT_FORMAT__, win32 %define NEWLINE 13, 10 %elifidn __OUTPUT_FORMAT__, elf32 %define NEWLINE 10 %endif
NASM provides a variety of macros that represent the timestamp of the assembly session.
__DATE__
and
__TIME__
macros give the assembly date and time
as strings, in ISO 8601 format ("YYYY-MM-DD"
and
"HH:MM:SS"
, respectively.)
__DATE_NUM__
and
__TIME_NUM__
macros give the assembly date and
time in numeric form; in the format YYYYMMDD
and
HHMMSS
respectively.
__UTC_DATE__
and
__UTC_TIME__
macros give the assembly date and
time in universal time (UTC) as strings, in ISO 8601 format
("YYYY-MM-DD"
and
"HH:MM:SS"
, respectively.) If the host platform
doesn't provide UTC time, these macros are undefined.
__UTC_DATE_NUM__
and
__UTC_TIME_NUM__
macros give the assembly date
and time universal time (UTC) in numeric form; in the format
YYYYMMDD
and HHMMSS
respectively. If the host platform doesn't provide UTC time, these macros
are undefined.
__POSIX_TIME__
macro is defined as a
number containing the number of seconds since the POSIX epoch, 1 January
1970 00:00:00 UTC; excluding any leap seconds. This is computed using UTC
time if available on the host platform, otherwise it is computed using the
local time as if it was UTC.
All instances of time and date macros in the same assembly session produce consistent output. For example, in an assembly session started at 42 seconds after midnight on January 1, 2010 in Moscow (timezone UTC+3) these macros would have the following values, assuming, of course, a properly configured environment with a correct clock:
__DATE__ "2010-01-01" __TIME__ "00:00:42" __DATE_NUM__ 20100101 __TIME_NUM__ 000042 __UTC_DATE__ "2009-12-31" __UTC_TIME__ "21:00:42" __UTC_DATE_NUM__ 20091231 __UTC_TIME_NUM__ 210042 __POSIX_TIME__<PHONE_NUMBER>
__USE_
package__
: Package Include TestWhen a standard macro package (see chapter
5) is included with the
directive (see
section 4.6.4), a single-line macro of the
form
package
is automatically defined. This allows testing if a particular package is
invoked or not.
For example, if the
package is included
(see section 5.1), then the macro
is defined.
__PASS__
: Assembly PassThe macro
is defined to be
on preparatory passes, and
on the final pass. In preprocess-only mode, it
is set to
, and when running only to generate
dependencies (due to the
or
option, see
section 2.1.4) it is set to
.
Avoid using this macro if at all possible. It is tremendously easy to generate very strange errors by misusing it, and the semantics may change in future versions of NASM.
STRUC
and ENDSTRUC
: Declaring Structure Data TypesThe core of NASM contains no intrinsic means of defining data
structures; instead, the preprocessor is sufficiently powerful that data
structures can be implemented as a set of macros. The macros
and
are
used to define a structure data type.
takes one or two parameters. The first
parameter is the name of the data type. The second, optional parameter is
the base offset of the structure. The name of the data type is defined as a
symbol with the value of the base offset, and the name of the data type
with the suffix
appended to it is defined
as an
giving the size of the structure. Once
has been issued, you are defining the
structure, and should define fields using the
family of pseudo-instructions, and then
invoke
to finish the definition.
For example, to define a structure called
containing a longword, a word, a byte and
a string of bytes, you might code
struc mytype mt_long: resd 1 mt_word: resw 1 mt_byte: resb 1 mt_str: resb 32 endstruc
The above code defines six symbols:
as
0 (the offset from the beginning of a
structure to the longword field),
as 4,
as 6,
as
7,
as 39, and
itself as zero.
The reason why the structure type name is defined at zero by default is a side effect of allowing structures to work with the local label mechanism: if your structure members tend to have the same names in more than one structure, you can define the above structure like this:
struc mytype .long: resd 1 .word: resw 1 .byte: resb 1 .str: resb 32 endstruc
This defines the offsets to the structure fields as
,
,
and
.
NASM, since it has no intrinsic structure support, does not
support any form of period notation to refer to the elements of a structure
once you have one (except the above local-label notation), so code such as
is not valid.
is a constant just like any other
constant, so the correct syntax is
or
.
Sometimes you only have the address of the structure displaced by an offset. For example, consider this standard stack frame setup:
push ebp mov ebp, esp sub esp, 40
In this case, you could access an element by subtracting the offset:
mov [ebp - 40 + mytype.word], ax
However, if you do not want to repeat this offset, you can use -40 as a base offset:
struc mytype, -40
And access an element this way:
mov [ebp + mytype.word], ax
ISTRUC
, AT
and IEND
: Declaring Instances of StructuresHaving defined a structure type, the next thing you typically want to do
is to declare instances of that structure in your data segment. NASM
provides an easy way to do this in the
mechanism. To declare a structure of type
in a program, you code something like this:
mystruc: istruc mytype at mt_long, dd 123456 at mt_word, dw 1024 at mt_byte, db 'x' at mt_str, db 'hello, world', 13, 10, 0 iend
The function of the
macro is to make use of
the
prefix to advance the assembly position
to the correct point for the specified structure field, and then to declare
the specified data. Therefore the structure fields must be declared in the
same order as they were specified in the structure definition.
If the data to go in a structure field requires more than one source
line to specify, the remaining source lines can easily come after the
line. For example:
at mt_str, db 123,134,145,156,167,178,189 db 190,100,0
Depending on personal taste, you can also omit the code part of the
line completely, and start the structure field
on the next line:
at mt_str db 'hello, world' db 13,10,0
ALIGN
and ALIGNB
: Data AlignmentThe
and
macros provides a convenient way to align code or data on a word, longword,
paragraph or other boundary. (Some assemblers call this directive
.) The syntax of the
and
macros
is
align 4 ; align on 4-byte boundary align 16 ; align on 16-byte boundary align 8,db 0 ; pad with 0s rather than NOPs align 4,resb 1 ; align to 4 in the BSS alignb 4 ; equivalent to previous line
Both macros require their first argument to be a power of two; they both
compute the number of additional bytes required to bring the length of the
current section up to a multiple of that power of two, and then apply the
prefix to their second argument to perform
the alignment.
If the second argument is not specified, the default for
is
, and the
default for
is
. So if the second argument is specified,
the two macros are equivalent. Normally, you can just use
in code and data sections and
in BSS sections, and never need the second
argument except for special purposes.
and
,
being simple macros, perform no error checking: they cannot warn you if
their first argument fails to be a power of two, or if their second
argument generates more than one byte of code. In each of these cases they
will silently do the wrong thing.
(or
with a second argument of
) can be used
within structure definitions:
struc mytype2 mt_byte: resb 1 alignb 2 mt_word: resw 1 alignb 4 mt_long: resd 1 mt_str: resb 32 endstruc
This will ensure that the structure members are sensibly aligned relative to the base of the structure.
A final caveat:
and
work relative to the beginning of the
section, not the beginning of the address space in the final
executable. Aligning to a 16-byte boundary when the section you're in is
only guaranteed to be aligned to a 4-byte boundary, for example, is a waste
of effort. Again, NASM does not check that the section's alignment
characteristics are sensible for the use of
or
.
Both
and
do call
macro implicitly. See
section 4.12.13 for details.
See also the
standard macro
package, section 5.2.
SECTALIGN
: Section AlignmentThe
macros provides a way to modify
alignment attribute of output file section. Unlike the
attribute (which is allowed at section
definition only) the
macro may be used
at any time.
For example the directive
SECTALIGN 16
sets the section alignment requirements to 16 bytes. Once increased it can not be decreased, the magnitude may grow only.
Note that
(see
section 4.12.12) calls the
macro implicitly so the active section
alignment requirements may be updated. This is by default behaviour, if for
some reason you want the
do not call
at all use the directive
SECTALIGN OFF
It is still possible to turn in on again by
SECTALIGN ON


| synopsis: | Renders a graphical overview of your project or specified apps. |
|---|
Creates a GraphViz dot file for the specified app names based on their models.py. You can pass multiple app names and they will all be combined into a single model. Output is usually directed to a dot file.
Several options are available: grouping models, including inheritance, excluding models and columns, and changing the layout when rendering to an output image.
With the latest revisions it’s also possible to specify an output file if pygraphviz is installed and render directly to an image or other supported file-type.
You need to select the library to generate the image. You can do so by passing the –pygraphviz or –pydot parameter, depending on which library you want to use.
When neither of the command line parameters are given the default is to try and load pygraphviz or pydot (in that order) to generate the image.
To install pygraphviz you usually need to run this command:
$ pip install pygraphviz
It is possible you can’t install it because it needs some C extensions to build. In that case you can try other methods to install or you can use PyDot.
To install pydot you need to run this command:
$ pip install pyparsing==1.5.7
$ pip install pydot
Installation should be fast and easy. Remember to install this exact version of pyparsing, otherwise it’s possible you get this error:
Couldn’t import dot_parser, loading of dot files will not be possible.
The option GRAPH_MODELS = {} can be used in the settings file to specify default options:
GRAPH_MODELS = {
'all_applications': True,
'group_models': True,
}
It uses the same names as on the command line only with the leading two dashes removed and the other dashes replaced by underscores.
Django templates are used to generate the dot code. This in turn can be drawn into a image by libraries like pygraphviz or pydot. You can extend or override the templates if needed.
Templates used:
- django_extensions/graph_models/digraph.dot
- django_extensions/graph_models/label.dot
- django_extensions/graph_models/relation.dot
Documentation on how to create dot files can be found here: http://www.graphviz.org/Documentation.php
Warning
Modifying Django’s default templates behaviour might break graph_models
Please be aware that if you use any template_loaders or extensions that change the way templates are rendered that this can cause graph_models to fail.
An example of this is the Django app django-template-minifier this automatically removed the newlines before/after template tags even for none-html templates which leads to a mallformed file.
With django-extensions installed you can create a dot-file or an image by using the graph_models command:
# Create a dot file
$ ./manage.py graph_models -a > my_project.dot
# Create a PNG image file called my_project_visualized.png with application grouping
$ ./manage.py graph_models -a -g -o my_project_visualized.png
# Same example but with explicit selection of pygraphviz or pydot
$ ./manage.py graph_models --pygraphviz -a -g -o my_project_visualized.png
$ ./manage.py graph_models --pydot -a -g -o my_project_visualized.png
# Create a dot file for only the 'foo' and 'bar' applications of your project
$ ./manage.py graph_models foo bar > my_project.dot


Privacy Policy
Last updated Aug 12, 2023Our policy is short and sweet because we value your information & privacy. We don't track or collect any personally identifiable information from our users. We do our best to limit the number of 3rd parties we rely on.
If you have any questions or concerns about our privacy policy, please contact us<EMAIL_ADDRESS>Terms of Use
Last updated November 15, 2020Premium Subscription Terms
Subscriptions will automatically renew unless canceled within 24-hours before the end of the current period. You can cancel anytime with your iTunes account settings. Any unused portion of a free trial will be forfeited if you purchase a subscription.If you have any questions or concerns about our terms of use, please contact us: support@shayesapps.com


HTML5 DND File Demo
drop a text file here from desktop!
drop a picture here from desktop!
you can drag multiple pictures at a time.


I was called in for induction at Codetelligent in Khayelitsha, so we were introduced in the indusrty of Web development/Software development(coding) amd also getting to know each other,on how to work as team because when you in this industry you must be able to work as a team.
We were given a group project to creat a Website about Fountain of Hope that is in Ekasi, it was hard since it was our first time but the outcome was for someone thats has been in the industry of coding.
So on this day we were given another website for Siki's coffe cafe from Ekasi. Discussing on how can we make Siki's cafe go viral/publc so that everyone around capetown can know about, so we thought how about we create a website for his cafe so that everyone can get in touch with Siki's coffee cafe. We were splited into groups, then everyone were given a task to do on that website.


Open to all. Come and help us decide what the CSGSA should work on next.
Working all the time is hard! Come play games and enjoy light refreshments with other CS graduate students.
A weekly time focused on coffee, writing and productivity (and bagels). Some meetings will involve a quick presentation before a writing/work session.


Travel
Home
Travel
New York
Los Angeles
Canada
Taipei
France
Japan
Australia
Vancouver
Vladivostok
Contact
Travel Around The World.
Get Started
New York
Los Angeles
Canada
Taipei
France
Japan
Australia
Vancouver
Vladivostok


This outlines how data should be returned. This document is really all there is to pyodec. It is split into 3 sections, input, output, and library rules.
Though Pyodec is really a loosely connected set of independently written codes, it is important for the data model API to be compatible between different decoders. The goal of these rules will be to allow a single piece of code to take a diverse set of files (knowing their decoders), and both decode them and look at the data with the same code.
Basic python rules for internal consistency, variable and method naming, etc. should be followed.
This is python, so there are no private methods. Rewrite/reallocate any internal method as you please, but when doing so please try to follow these usage guidelines. If you find a better way to do the central decode method, then share it!
A decoder object is a class, which supports methods defined in the sections below relating to variables and a primary decoding function. It is essential that any decoder class supports decoding in the methods described, inputs as described, and handles variables in a very similar manner.
Decoders should accept file path string, file object, and (where possible) string inputs to the decoder method as the first argument.
At a minimum, a decoder class should contain a decode method which can be run conforming to these input and interface protocols.
Decoders should produce a generator object, (usually using yield), and should allow the keyword argument generator control whether a generator or list is returned. generator should default to True.
| Argument | Type | Default | Purpose |
|---|---|---|---|
| limit | int | 1000 | Number of discrete data results to accumulate before yielding |
| generator | bool | False | Produce a generator based on limit, or a single set of values representing the entire dataset. |
Warning Not all decoders at this time implement this protocol, and simply return generators at all times. These input requirements will evolve and expand over time (such as a requirement to handle certain keyword arguments properly)
The possible range of outputs is far more diverse than the possible inputs, however there are a few goals that can be shared.
Discrete observations (rows) are collected in a list
Not the other way around. This is slightly less efficient with memory, but it is conceptually much simpler, and allows the second rule to actually work. .. highlight:: python
yield [(12,[4,4,4]), (12,[5,5,5]), ... ]
not
yield [[[12,12,...],[[4,4,4],[5,5,5],...]]
Note
This allows the returned data to be considered “records” as far as numpy is concerned, and can be easily converted into a very powerful recarray type simply with:
data = np.rec.fromrecords(data, dtype=decoder.get_dtype())
Iterative and procedural output are the same structure
Simply, you interact with a returned list of values in the same manner, whether you receive them from a yield or a return.
This is the least-defined rule of the library. Many data files are self-describing in some manner, and it is essential to extract this metadata from files.
The current procedure for a decoder class object to reveal the descriptions of the variables is through three methods with the following functionality.
Method Function .getvars() Return a list of dictionaries containing name, dtype and shape info, whose indices correspond to the index of the returned dataset (e.g. column names and descriptions). .get_fixed_vars() Return similar info to .getvars(), but includes the actual data elements as well, since fixed vars are not yielded with the rest of the data by default. .get_dtype() Return a valud Numpy-recarray dtype description, such that you could say import pyodec.files.myDecoder as dec import numpy as np for data in dec.decode(src):
# convert data into a super awesome numpy recarray data = np.rec.fromrecords(data, dtype=decoder.get_dtype())
By default, the return values of these methods are defined by the VariableList and FixedVariableList class objects, but as always, the functionality can be overwritten in a decoder class when necessary.
As noted, these variable/metadata requirements are not set in stone, and will likely change through development with other users. Obviously backwards compatibility will become an issue pretty quickly, however.
top
Naming conventions In accordance with python convention, classes will be in CamelCase, and everything else will be in lowercase with underscores. However, there is some inconsistency regarding naming of decoders, and decoder modules.
The current naming convention for the files that contain the decoders is to use lowercase and underscores where necessary.
This is up for debate.


Mentoring
Trey Hunner / @treyhunner / Python & Django trainer
In-person mentoring at a workshop
- Not curriculum development
- Not lecturing
- Not how to run a workshop
- Not life coaching
- Not teaching over the internet
Focus on the task at hand
- Avoid pointing out issues that aren't relevant
- Don't nitpick over code style unless you're asked to
- Focus on the immediate task, not everything that's wrong
- Ask what is expected and run the code together to see what actually happens
Be deliberate and positive
- Speak slowly and try to enunciate well
- Be careful with words: don't say "obviously" or "it's easy"
- Be on the same level: sit or squat instead of hovering
- Encourage and congratulate
Supporter, not super hero
- Dethrone yourself: be a helper more than an expert
- Keep your learner in control: don't touch their keyboard!
- Don't tell, show/do together
- Walk through error messages together
- Encourage looking it up: "I don't know, let's go to Google"


Pesticides
Job Application
"Bees? Where are they?"
graph
How_to_be_human.pdf
New Developments
This is the default dialog which is useful for displsssssaying information. The dialog window can be moved, resized and closed with the 'x' icon.


Jordan Algebras#
AUTHORS:
Travis Scrimshaw (2014-04-02): initial version
Travis Scrimshaw (2023-05-09): added the 27 dimensional exceptional Jordan algebra
- class sage.algebras.jordan_algebra.ExceptionalJordanAlgebra(O)#
Bases:
JordanAlgebra
The exceptional \(27\) dimensional Jordan algebra as self-adjoint \(3 \times 3\) matrix over an octonion algebra.
Let \(\mathbf{O}\) be the
OctonionAlgebra
over a commutative ring \(R\) of characteristic not equal to \(2\). The exceptional Jordan algebra \(\mathfrak{h}_3(\mathbf{O})\) is a \(27\) dimensional free \(R\)-module spanned by the matrices\[\begin{split}\begin{bmatrix} \alpha & x & y \\ x^* & \beta & z \\ y^* & z^* & \gamma \end{bmatrix}\end{split}\]for \(\alpha, \beta, \gamma \in R\) and \(x, y, z \in \mathbf{O}\), with multiplication given by the usual symmetrizer operation \(X \circ Y = \frac{1}{2}(XY + YX)\).
These are also known as Albert algebras due to the work of Abraham Adrian Albert on these algebras over \(\RR\).
EXAMPLES:
We construct an exceptional Jordan algebra over \(\QQ\) and perform some basic computations:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: gens = J.gens() sage: gens[1] [0 0 0] [0 1 0] [0 0 0] sage: gens[3] [0 1 0] [1 0 0] [0 0 0] sage: gens[1] * gens[3] [ 0 1/2 0] [1/2 0 0] [ 0 0 0]
The Lie algebra of derivations of the exceptional Jordan algebra is isomorphic to the simple Lie algebra of type \(F_4\). We verify that we the derivation module has the correct dimension:
sage: len(J.derivations_basis()) # long time 52 sage: LieAlgebra(QQ, cartan_type='F4').dimension() 52
REFERENCES:
- class Element(parent, data)#
Bases:
AlgebraElement
An element of an exceptional Jordan algebra.
- monomial_coefficients(copy=True)#
Return a dictionary whose keys are indices of basis elements in the support of
self
and whose values are the corresponding coefficients.INPUT:
copy
– ignored
EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: elt = sum(~QQ(ind) * b for ind, b in enumerate(J.basis()[::6], start=1)); elt [ 1 1/2*k 1/3*i + 1/4*lk] [ -1/2*k 0 1/5*li] [-1/3*i - 1/4*lk -1/5*li 0] sage: elt.monomial_coefficients() {0: 1, 6: 1/2, 12: 1/3, 18: 1/4, 24: 1/5}
- algebra_generators()#
Return a basis of
self
.EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: B = J.basis() sage: B[::6] ([1 0 0] [0 0 0] [0 0 0], [ 0 k 0] [-k 0 0] [ 0 0 0], [ 0 0 i] [ 0 0 0] [-i 0 0], [ 0 0 lk] [ 0 0 0] [-lk 0 0], [ 0 0 0] [ 0 0 li] [ 0 -li 0]) sage: len(B) 27
- basis()#
Return a basis of
self
.EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: B = J.basis() sage: B[::6] ([1 0 0] [0 0 0] [0 0 0], [ 0 k 0] [-k 0 0] [ 0 0 0], [ 0 0 i] [ 0 0 0] [-i 0 0], [ 0 0 lk] [ 0 0 0] [-lk 0 0], [ 0 0 0] [ 0 0 li] [ 0 -li 0]) sage: len(B) 27
- gens()#
Return the generators of
self
.EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: G = J.gens() sage: G[0] [1 0 0] [0 0 0] [0 0 0] sage: G[5] [ 0 j 0] [-j 0 0] [ 0 0 0] sage: G[22] [ 0 0 0] [ 0 0 k] [ 0 -k 0]
- one()#
Return multiplicative identity.
EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: J.one() [1 0 0] [0 1 0] [0 0 1] sage: all(J.one() * b == b for b in J.basis()) True
- some_elements()#
Return some elements of
self
.EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: J.some_elements() [[6/5 0 0] [ 0 6/5 0] [ 0 0 6/5], [1 0 0] [0 1 0] [0 0 1], [0 0 0] [0 0 0] [0 0 0], [0 0 0] [0 1 0] [0 0 0], [ 0 j 0] [-j 0 0] [ 0 0 0], [ 0 0 lj] [ 0 0 0] [-lj 0 0], [ 0 0 0] [ 0 1 1/2*lj] [ 0 -1/2*lj 0], [ 1 0 j + 2*li] [ 0 1 0] [-j - 2*li 0 1], [ 1 j + lk l] [-j - lk 0 i + lj] [ -l -i - lj 0], [ 1 3/2*l 2*k] [-3/2*l 0 5/2*j] [ -2*k -5/2*j 0]] sage: O = OctonionAlgebra(GF(3)) sage: J = JordanAlgebra(O) sage: J.some_elements() [[-1 0 0] [ 0 -1 0] [ 0 0 -1], [1 0 0] [0 1 0] [0 0 1], [0 0 0] [0 0 0] [0 0 0], [0 0 0] [0 1 0] [0 0 0], [ 0 j 0] [-j 0 0] [ 0 0 0], [ 0 0 lj] [ 0 0 0] [-lj 0 0], [ 0 0 0] [ 0 1 -lj] [ 0 lj 0], [ 1 0 j - li] [ 0 1 0] [-j + li 0 1], [ 1 j + lk l] [-j - lk 0 i + lj] [ -l -i - lj 0], [ 1 0 -k] [ 0 0 j] [ k -j 0]]
- zero()#
Return the additive identity.
EXAMPLES:
sage: O = OctonionAlgebra(QQ) sage: J = JordanAlgebra(O) sage: J.zero() [0 0 0] [0 0 0] [0 0 0]
- class sage.algebras.jordan_algebra.JordanAlgebra#
Bases:
UniqueRepresentation
,Parent
A Jordan algebra.
A Jordan algebra is a magmatic algebra (over a commutative ring \(R\)) whose multiplication satisfies the following axioms:
\(xy = yx\), and
\((xy)(xx) = x(y(xx))\) (the Jordan identity).
See [Ja1971], [Ch2012], and [McC1978], for example.
These axioms imply that a Jordan algebra is power-associative and the following generalization of Jordan’s identity holds [Al1947]: \((x^m y) x^n = x^m (y x^n)\) for all \(m, n \in \ZZ_{>0}\).
Let \(A\) be an associative algebra over a ring \(R\) in which \(2\) is invertible. We construct a Jordan algebra \(A^+\) with ground set \(A\) by defining the multiplication as
\[x \circ y = \frac{xy + yx}{2}.\]Often the multiplication is written as \(x \circ y\) to avoid confusion with the product in the associative algebra \(A\). We note that if \(A\) is commutative then this reduces to the usual multiplication in \(A\).
Jordan algebras constructed in this fashion, or their subalgebras, are called special. All other Jordan algebras are called exceptional.
Jordan algebras can also be constructed from a module \(M\) over \(R\) with a symmetric bilinear form \((\cdot, \cdot) : M \times M \to R\). We begin with the module \(M^* = R \oplus M\) and define multiplication in \(M^*\) by
\[(\alpha + x) \circ (\beta + y) = \underbrace{\alpha \beta + (x,y)}_{\in R} + \underbrace{\beta x + \alpha y}_{\in M},\]where \(\alpha, \beta \in R\) and \(x,y \in M\).
INPUT:
Can be either an associative algebra \(A\) or a symmetric bilinear form given as a matrix (possibly followed by, or preceded by, a base ring argument).
EXAMPLES:
We let the base algebra \(A\) be the free algebra on 3 generators:
sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F); J Jordan algebra of Free Algebra on 3 generators (x, y, z) over Rational Field sage: a,b,c = map(J, F.gens()) sage: a*b 1/2*x*y + 1/2*y*x sage: b*a 1/2*x*y + 1/2*y*x
Jordan algebras are typically non-associative:
sage: (a*b)*c 1/4*x*y*z + 1/4*y*x*z + 1/4*z*x*y + 1/4*z*y*x sage: a*(b*c) 1/4*x*y*z + 1/4*x*z*y + 1/4*y*z*x + 1/4*z*y*x
We check the Jordan identity:
sage: (a*b)*(a*a) == a*(b*(a*a)) True sage: x = a + c sage: y = b - 2*a sage: (x*y)*(x*x) == x*(y*(x*x)) True
Next we construct a Jordan algebra from a symmetric bilinear form:
sage: m = matrix([[-2,3],[3,4]]) sage: J.<a,b,c> = JordanAlgebra(m); J Jordan algebra over Integer Ring given by the symmetric bilinear form: [-2 3] [ 3 4] sage: a 1 + (0, 0) sage: b 0 + (1, 0) sage: x = 3*a - 2*b + c; x 3 + (-2, 1)
We again show that Jordan algebras are usually non-associative:
sage: (x*b)*b -6 + (7, 0) sage: x*(b*b) -6 + (4, -2)
We verify the Jordan identity:
sage: y = -a + 4*b - c sage: (x*y)*(x*x) == x*(y*(x*x)) True
The base ring, while normally inferred from the matrix, can also be explicitly specified:
sage: J.<a,b,c> = JordanAlgebra(m, QQ); J Jordan algebra over Rational Field given by the symmetric bilinear form: [-2 3] [ 3 4] sage: J.<a,b,c> = JordanAlgebra(QQ, m); J # either order work Jordan algebra over Rational Field given by the symmetric bilinear form: [-2 3] [ 3 4]
REFERENCES:
- class sage.algebras.jordan_algebra.JordanAlgebraSymmetricBilinear(R, form, names=None)#
Bases:
JordanAlgebra
A Jordan algebra given by a symmetric bilinear form \(m\).
- class Element(parent, s, v)#
Bases:
AlgebraElement
An element of a Jordan algebra defined by a symmetric bilinear form.
- bar()#
Return the result of the bar involution of
self
.The bar involution \(\bar{\cdot}\) is the \(R\)-linear endomorphism of \(M^*\) defined by \(\bar{1} = 1\) and \(\bar{x} = -x\) for \(x \in M\).
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J.<a,b,c> = JordanAlgebra(m) sage: x = 4*a - b + 3*c sage: x.bar() 4 + (1, -3)
We check that it is an algebra morphism:
sage: y = 2*a + 2*b - c sage: x.bar() * y.bar() == (x*y).bar() True
- monomial_coefficients(copy=True)#
Return a dictionary whose keys are indices of basis elements in the support of
self
and whose values are the corresponding coefficients.INPUT:
copy
– ignored
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J.<a,b,c> = JordanAlgebra(m) sage: elt = a + 2*b - c sage: elt.monomial_coefficients() {0: 1, 1: 2, 2: -1}
- norm()#
Return the norm of
self
.The norm of an element \(\alpha + x \in M^*\) is given by \(n(\alpha + x) = \alpha^2 - (x, x)\).
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J.<a,b,c> = JordanAlgebra(m) sage: x = 4*a - b + 3*c; x 4 + (-1, 3) sage: x.norm() 13
- trace()#
Return the trace of
self
.The trace of an element \(\alpha + x \in M^*\) is given by \(t(\alpha + x) = 2 \alpha\).
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J.<a,b,c> = JordanAlgebra(m) sage: x = 4*a - b + 3*c sage: x.trace() 8
- algebra_generators()#
Return a basis of
self
.The basis returned begins with the unity of \(R\) and continues with the standard basis of \(M\).
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J = JordanAlgebra(m) sage: J.basis() Family (1 + (0, 0), 0 + (1, 0), 0 + (0, 1))
- basis()#
Return a basis of
self
.The basis returned begins with the unity of \(R\) and continues with the standard basis of \(M\).
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J = JordanAlgebra(m) sage: J.basis() Family (1 + (0, 0), 0 + (1, 0), 0 + (0, 1))
- gens()#
Return the generators of
self
.EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J = JordanAlgebra(m) sage: J.gens() (1 + (0, 0), 0 + (1, 0), 0 + (0, 1))
- one()#
Return the element 1 if it exists.
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J = JordanAlgebra(m) sage: J.one() 1 + (0, 0)
- zero()#
Return the element 0.
EXAMPLES:
sage: m = matrix([[0,1],[1,1]]) sage: J = JordanAlgebra(m) sage: J.zero() 0 + (0, 0)
- class sage.algebras.jordan_algebra.SpecialJordanAlgebra(A, names=None)#
Bases:
JordanAlgebra
A (special) Jordan algebra \(A^+\) from an associative algebra \(A\).
- class Element(parent, x)#
Bases:
AlgebraElement
An element of a special Jordan algebra.
- monomial_coefficients(copy=True)#
Return a dictionary whose keys are indices of basis elements in the support of
self
and whose values are the corresponding coefficients.INPUT:
copy
– (default:True
) ifself
is internally represented by a dictionaryd
, then make a copy ofd
; ifFalse
, then this can cause undesired behavior by mutatingd
EXAMPLES:
sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F) sage: a,b,c = map(J, F.gens()) sage: elt = a + 2*b - c sage: elt.monomial_coefficients() {x: 1, y: 2, z: -1}
- algebra_generators()#
Return the basis of
self
.EXAMPLES:
sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F) sage: J.basis() Lazy family (Term map(i))_{i in Free monoid on 3 generators (x, y, z)}
- basis()#
Return the basis of
self
.EXAMPLES:
sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F) sage: J.basis() Lazy family (Term map(i))_{i in Free monoid on 3 generators (x, y, z)}
- gens()#
Return the generators of
self
.EXAMPLES:
sage: cat = Algebras(QQ).WithBasis().FiniteDimensional() sage: C = CombinatorialFreeModule(QQ, ['x','y','z'], category=cat) sage: J = JordanAlgebra(C) sage: J.gens() (B['x'], B['y'], B['z']) sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F) sage: J.gens() Traceback (most recent call last): ... NotImplementedError: infinite set
- one()#
Return the element \(1\) if it exists.
EXAMPLES:
sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F) sage: J.one() 1
- zero()#
Return the element \(0\).
EXAMPLES:
sage: F.<x,y,z> = FreeAlgebra(QQ) sage: J = JordanAlgebra(F) sage: J.zero() 0


A common filtering method involves selecting rows which have a time value which lies within what is called a Good Time Interval or GTI. The time intervals are defined in a separate FITS table extension which contains 2 columns giving the start and stop time of each good interval. The filtering operation accepts only those rows of the input table which have an associated time which falls within one of the time intervals defined in the GTI extension. A high level function, gtifilter(a,b,c,d), is available which evaluates each row of the input table and returns TRUE or FALSE depending whether the row is inside or outside the good time interval. The syntax is
gtifilter( [ "gtifile" [, expr [, "STARTCOL", "STOPCOL" ] ] ] ) or gtifilter( [ 'gtifile' [, expr [, 'STARTCOL', 'STOPCOL' ] ] ] )where each "[]" demarks optional parameters. Note that the quotes around the gtifile and START/STOP column are required. Either single or double quotes may be used. In cases where this expression is entered on the Unix command line, enclose the entire expression in double quotes, and then use single quotes within the expression to enclose the 'gtifile' and other terms. It is also usually possible to do the reverse, and enclose the whole expression in single quotes and then use double quotes within the expression. The gtifile, if specified, can be blank ("") which will mean to use the first extension with the name "*GTI*" in the current file, a plain extension specifier (eg, "+2", "[2]", or "[STDGTI]") which will be used to select an extension in the current file, or a regular filename with or without an extension specifier which in the latter case will mean to use the first extension with an extension name "*GTI*". Expr can be any arithmetic expression, including simply the time column name. A vector time expression will produce a vector boolean result. STARTCOL and STOPCOL are the names of the START/STOP columns in the GTI extension. If one of them is specified, they both must be.
In its simplest form, no parameters need to be provided - default values will be used. The expression "gtifilter()" is equivalent to
gtifilter( "", TIME, "*START*", "*STOP*" )This will search the current file for a GTI extension, filter the TIME column in the current table, using START/STOP times taken from columns in the GTI extension with names containing the strings "START" and "STOP". The wildcards ('*') allow slight variations in naming conventions such as "TSTART" or "STARTTIME". The same default values apply for unspecified parameters when the first one or two parameters are specified. The function automatically searches for TIMEZERO/I/F keywords in the current and GTI extensions, applying a relative time offset, if necessary.


|
Elektra
0.9.0
|
I/O example binding. More...
#include <stdlib.h>
#include <string.h>
#include <kdbassert.h>
#include <kdbhelper.h>
#include <kdbio.h>
#include <kdblogger.h>
Classes | |
| struct | SomeIoLibHandle |
| Example I/O management library data structure. More... | |
| struct | DocOperationData |
| [kdbio operation data] More... | |
| struct | DocBindingData |
| [kdbio operation data] More... | |
Typedefs | |
| typedef struct SomeIoLibHandle | SomeIoLibHandle |
| Example I/O management library data structure. | |
| typedef struct DocOperationData | DocOperationData |
| [kdbio operation data] More... | |
| typedef struct DocBindingData | DocBindingData |
| [kdbio operation data] More... | |
Enumerations | |
| enum | SomeIoLibFlags { SOME_IOLIB_READABLE = 1 << 0, SOME_IOLIB_WRITABLE = 1 << 1 } |
| Example I/O mangement library bitmask flags. More... | |
Functions | |
| DocOperationData * | newOperationData (void) |
| [kdbio binding data] More... | |
| int | someBitMaskToElektraIoFlags (int bitmask) |
| Convert your I/O library bit mask to Elektra's I/O flags. More... | |
| void | ioDocBindingFdCallback (SomeIoLibHandle *handle, int bitmask) |
| Calls the associated operation callback. More... | |
| void | ioDocBindingTimerCallback (SomeIoLibHandle *handle) |
| [kdbio operation callback] More... | |
| void | ioDocBindingIdleCallback (SomeIoLibHandle *handle) |
| Calls the associated operation callback. More... | |
| int | ioDocBindingUpdateFd (ElektraIoFdOperation *fdOp) |
| Update information about a file descriptor watched by I/O binding. More... | |
| int | ioDocBindingAddFd (ElektraIoInterface *binding, ElektraIoFdOperation *fdOp) |
| Add file descriptor to I/O binding. More... | |
| int | ioDocBindingRemoveFd (ElektraIoFdOperation *fdOp) |
| Remove file descriptor from I/O binding. More... | |
| int | ioDocBindingUpdateTimer (ElektraIoTimerOperation *timerOp) |
| Update timer in I/O binding. More... | |
| int | ioDocBindingAddTimer (ElektraIoInterface *binding, ElektraIoTimerOperation *timerOp) |
| Add timer for I/O binding. More... | |
| int | ioDocBindingRemoveTimer (ElektraIoTimerOperation *timerOp) |
| Remove timer from I/O binding. More... | |
| int | ioDocBindingUpdateIdle (ElektraIoIdleOperation *idleOp) |
| Update idle operation in I/O binding. More... | |
| int | ioDocBindingAddIdle (ElektraIoInterface *binding, ElektraIoIdleOperation *idleOp) |
| Add idle operation to I/O binding. More... | |
| int | ioDocBindingRemoveIdle (ElektraIoIdleOperation *idleOp) |
| Remove idle operation from I/O binding. More... | |
| int | ioDocBindingCleanup (ElektraIoInterface *binding) |
| Cleanup. More... | |
| ElektraIoInterface * | elektraIoDocNew (char *foo) |
| Create and initialize a new doc I/O binding. More... | |
I/O example binding.
All functions except the I/O binding entry point (elektraIoDocNew()) would normally be static but for documentation purposes they are not.
| typedef struct DocBindingData DocBindingData |
[kdbio operation data]
[kdbio binding data] Container for additional information for an I/O binding.
| typedef struct DocOperationData DocOperationData |
[kdbio operation data]
Container for additional information for I/O binding operations.
It is helpful to create a data structure for your binding to store additional data
| enum SomeIoLibFlags |
| ElektraIoInterface* elektraIoDocNew | ( | char * | foo | ) |
Create and initialize a new doc I/O binding.
| foo | Some data from I/O management library (e.g. a handle) |
[kdbio binding create]
[kdbio binding create] [kdbio binding setdata]
[kdbio binding setdata]
| int ioDocBindingAddFd | ( | ElektraIoInterface * | binding, |
| ElektraIoFdOperation * | fdOp | ||
| ) |
Add file descriptor to I/O binding.
[kdbio binding addfd]
[kdbio binding addfd]
| int ioDocBindingAddIdle | ( | ElektraIoInterface * | binding, |
| ElektraIoIdleOperation * | idleOp | ||
| ) |
Add idle operation to I/O binding.
| int ioDocBindingAddTimer | ( | ElektraIoInterface * | binding, |
| ElektraIoTimerOperation * | timerOp | ||
| ) |
Add timer for I/O binding.
| int ioDocBindingCleanup | ( | ElektraIoInterface * | binding | ) |
| void ioDocBindingFdCallback | ( | SomeIoLibHandle * | handle, |
| int | bitmask | ||
| ) |
Calls the associated operation callback.
Called by your I/O management library whenever a file descriptor status has changed.
| handle | some I/O management handle |
| flags | flags bit mask[kdbio operation callback] |
| void ioDocBindingIdleCallback | ( | SomeIoLibHandle * | handle | ) |
Calls the associated operation callback.
Called by your I/O management library whenever an idle operation can run without interfering with other operations.
| handle | some I/O management handle |
| int ioDocBindingRemoveFd | ( | ElektraIoFdOperation * | fdOp | ) |
Remove file descriptor from I/O binding.
[kdbio operation getdata]
[kdbio operation getdata]
| int ioDocBindingRemoveIdle | ( | ElektraIoIdleOperation * | idleOp | ) |
Remove idle operation from I/O binding.
| int ioDocBindingRemoveTimer | ( | ElektraIoTimerOperation * | timerOp | ) |
Remove timer from I/O binding.
| void ioDocBindingTimerCallback | ( | SomeIoLibHandle * | handle | ) |
[kdbio operation callback]
Calls the associated operation callback. Called by your I/O management library whenever a timer interval has passed.
| handle | some I/O management handle |
| int ioDocBindingUpdateFd | ( | ElektraIoFdOperation * | fdOp | ) |
Update information about a file descriptor watched by I/O binding.
| int ioDocBindingUpdateIdle | ( | ElektraIoIdleOperation * | idleOp | ) |
Update idle operation in I/O binding.
| int ioDocBindingUpdateTimer | ( | ElektraIoTimerOperation * | timerOp | ) |
Update timer in I/O binding.
| DocOperationData* newOperationData | ( | void | ) |
[kdbio binding data]
A little helper function for allocating our custom operation data structure
| int someBitMaskToElektraIoFlags | ( | int | bitmask | ) |
Convert your I/O library bit mask to Elektra's I/O flags.
| bitmask | bit mask from I/O management library |


| Opcode*/Instruction | Op/En | 64/32 bit Mode Support | CPUID Feature Flag | Description |
|---|---|---|---|---|
| NFx 0F C7 /6 RDRAND r16 | M | V/V | RDRAND | Read a 16-bit random number and store in the destination register. |
| NFx 0F C7 /6 RDRAND r32 | M | V/V | RDRAND | Read a 32-bit random number and store in the destination register. |
| NFx REX.W + 0F C7 /6 RDRAND r64 | M | V/I | RDRAND | Read a 64-bit random number and store in the destination register. |
| Op/En | Operand 1 | Operand 2 | Operand 3 | Operand 4 |
| M | ModRM:r/m (w) | NA | NA | NA |
Loads a hardware generated random value and store it in the destination register. The size of the random value is determined by the destination register size and operating mode. The Carry Flag indicates whether a random value is available at the time the instruction is executed. CF=1 indicates that the data in the destination is valid. Otherwise CF=0 and the data in the destination operand will be returned as zeros for the specified width. All other flags are forced to 0 in either situation. Software must check the state of CF=1 for determining if a valid random value has been returned, otherwise it is expected to loop and retry execution of RDRAND (see Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, Section 7.3.17, “Random Number Generator Instructions”).
This instruction is available at all privilege levels.
In 64-bit mode, the instruction's default operation size is 32 bits. Using a REX prefix in the form of REX.B permits access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bit operands. See the summary chart at the beginning of this section for encoding data and limits.
IF HW_RND_GEN.ready = 1 THEN CASE of osize is 64: DEST[63:0] ← HW_RND_GEN.data; osize is 32: DEST[31:0] ← HW_RND_GEN.data; osize is 16: DEST[15:0] ← HW_RND_GEN.data; ESAC CF ← 1; ELSE CASE of osize is 64: DEST[63:0] ← 0; osize is 32: DEST[31:0] ← 0; osize is 16: DEST[15:0] ← 0; ESAC CF ← 0; FI OF, SF, ZF, AF, PF ← 0;
The CF flag is set according to the result (see the “Operation” section above). The OF, SF, ZF, AF, and PF flags are set to 0.
RDRAND: int _rdrand16_step( unsigned short * );
RDRAND: int _rdrand32_step( unsigned int * );
RDRAND: int _rdrand64_step( unsigned __int64 *);
| #UD | If the LOCK prefix is used. |
| If CPUID.01H:ECX.RDRAND[bit 30] = 0. |
Same exceptions as in protected mode.
Same exceptions as in protected mode.
Same exceptions as in protected mode.
Same exceptions as in protected mode.


{% extends 'deluxe/create_base.html' %} {% load static %} {% load crispy_forms_tags %} {% block content %} {{tag_line}} {% csrf_token %} Do you really want to delete ...? {{ hobby.hobby }} Yes Cancle {% endblock %}
Do you really want to delete ...?
{{ hobby.hobby }}


Preparation time
30 mins to 1 hour
Cooking time
over 2 hours
Serves
Serves 6
Dietary
If you’ve got a sweet tooth and a love of banana and caramel flavours, this is the pud for you. Served with proper homemade custard.
For the banana and treacle pudding, butter the insides of a large pudding basin thoroughly. Put the golden syrup in the base, then arrange the sliced banana on top.
Cream the butter and sugar together, then add the eggs one at a time with a tablespoon of flour after each one. Incorporate the rest of the flour and the banana. Add a squeeze of lime juice to loosen the consistency slightly, then scrape the mixture into the pudding basin.
Cover the basin with a sheet of greaseproof paper (or foil) with a pleat folded down the middle (this lets the air expand during cooking). Put an upturned heatproof saucer or small trivet in a large, deep saucepan, and place the pudding basin on top. Add enough just-boiled water to the pan to come halfway up the sides of the basin. Cover the pan with a tight-fitting lid and place over a low heat. Allow to steam in the gently simmering water for 2 hours, adding more water to the pan if necessary. (Make sure the pan does not boil dry.) The pudding is done when a skewer inserted into the centre of the pudding (through the foil or paper) comes out clean. When done, turn off the heat and carefully lift the basin from the water. Leave to stand for 5 minutes.
Discard the aluminium foil and paper. Run a cutlery knife around the edge of the pudding to loosen the sides. Carefully invert onto a deep plate and remove the basin.
While the pudding is steaming, make the custard. Put the milk and the cream into a saucepan with the vanilla pod or extract. Bring almost to the boil, then remove from the heat and leave it so the flavours will infuse until it cools.
Whisk the egg yolks and sugar together until pale with a foamy, aerated texture. Reheat the milk and cream again until just below boiling point. Strain the milk mixture through a sieve into a jug and rinse out the saucepan.
Slowly pour the milk mixture over the eggs, whisking constantly as you do so, then pour back into the saucepan. Set over a very low heat and stir constantly until the custard has thickened slightly and you can draw a line through it when it coats the back of a spoon.
Strain the custard again and stir in the banana liqueur, if using.
To serve, turn the pudding out onto a plate and serve with the custard.
You need JavaScript to view this clip.
Wrapping a pudding for steaming


Portal of the Department of computer science is designed to provide information for applicants, students and teachers, about the schedule of scientific activity and innovative teaching methods.
P.S. Also, there is a version in English language
Bazylyan Rostislav Sergeevich – Student of the direction "Applied computer science in information sphere"
Podymova Ekaterina Sergeevna – Student of the direction "Applied computer science in information sphere"