The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect2/para
Context English State
Our filter will read each pixel from its input, turn it to a negative, and write it to its output buffer.
Our filter will call <function>getchar</function> to fetch the next pixel.
<function>getchar</function> will find an empty input buffer, so it will call <function>read</function>.
<function>read</function> will call the <function role="syscall">SYS_read</function> system call.
The <emphasis>kernel</emphasis> will suspend our filter until the image editor sends more data to the pipe.
The image editor will read from the other pipe, connected to the <varname>fd.out</varname> of our filter so it can set the first row of the output image <emphasis>before</emphasis> it sends us the second row of the input.
The <emphasis>kernel</emphasis> suspends the image editor until it receives some output from our filter, so it can pass it on to the image editor.
At this point our filter waits for the image editor to send it more data to process, while the image editor is waiting for our filter to send it the result of the processing of the first row. But the result sits in our output buffer.
The filter and the image editor will continue waiting for each other forever (or, at least, until they are killed). Our software has just entered a <link linkend="secure-race-conditions">race condition</link>.
This problem does not exist if our filter flushes its output buffer <emphasis>before</emphasis> asking the <emphasis>kernel</emphasis> for more input data.
Using the <acronym>FPU</acronym>
Strangely enough, most of assembly language literature does not even mention the existence of the <acronym>FPU</acronym>, or <emphasis>floating point unit</emphasis>, let alone discuss programming it.
Yet, never does assembly language shine more than when we create highly optimized <acronym>FPU</acronym> code by doing things that can be done <emphasis>only</emphasis> in assembly language.
Organization of the <acronym>FPU</acronym>
The <acronym>FPU</acronym> consists of 8 80–bit floating–point registers. These are organized in a stack fashion—you can <function>push</function> a value on <acronym>TOS</acronym> (<emphasis>top of stack</emphasis>) and you can <function>pop</function> it.
That said, the assembly language op codes are not <function role="opcode">push</function> and <function role="opcode">pop</function> because those are already taken.
You can <function>push</function> a value on <acronym>TOS</acronym> by using <function role="opcode">fld</function>, <function role="opcode">fild</function>, and <function role="opcode">fbld</function>. Several other op codes let you <function>push</function> many common <emphasis>constants</emphasis>—such as <emphasis>pi</emphasis>—on the <acronym>TOS</acronym>.
Similarly, you can <function>pop</function> a value by using <function role="opcode">fst</function>, <function role="opcode">fstp</function>, <function role="opcode">fist</function>, <function role="opcode">fistp</function>, and <function role="opcode">fbstp</function>. Actually, only the op codes that end with a <emphasis>p</emphasis> will literally <function>pop</function> the value, the rest will <function>store</function> it somewhere else without removing it from the <acronym>TOS</acronym>.
We can transfer the data between the <acronym>TOS</acronym> and the computer memory either as a 32–bit, 64–bit, or 80–bit <emphasis>real</emphasis>, a 16–bit, 32–bit, or 64–bit <emphasis>integer</emphasis>, or an 80–bit <emphasis>packed decimal</emphasis>.
The 80–bit <emphasis>packed decimal</emphasis> is a special case of <emphasis>binary coded decimal</emphasis> which is very convenient when converting between the <acronym>ASCII</acronym> representation of data and the internal data of the <acronym>FPU</acronym>. It allows us to use 18 significant digits.
No matter how we represent data in the memory, the <acronym>FPU</acronym> always stores it in the 80–bit <emphasis>real</emphasis> format in its registers.
Its internal precision is at least 19 decimal digits, so even if we choose to display results as <acronym>ASCII</acronym> in the full 18–digit precision, we are still showing correct results.
We can perform mathematical operations on the <acronym>TOS</acronym>: We can calculate its <emphasis>sine</emphasis>, we can <emphasis>scale</emphasis> it (i.e., we can multiply or divide it by a power of 2), we can calculate its base–2 <emphasis>logarithm</emphasis>, and many other things.
We can also <emphasis>multiply</emphasis> or <emphasis>divide</emphasis> it by, <emphasis>add</emphasis> it to, or <emphasis>subtract</emphasis> it from, any of the <acronym>FPU</acronym> registers (including itself).
The official Intel op code for the <acronym>TOS</acronym> is <varname role="register">st</varname>, and for the <emphasis>registers</emphasis> <varname role="register">st(0)</varname>–<varname role="register">st(7)</varname>. <varname role="register">st</varname> and <varname role="register">st(0)</varname>, then, refer to the same register.
For whatever reasons, the original author of <application>nasm</application> has decided to use different op codes, namely <varname role="register">st0</varname>–<varname role="register">st7</varname>. In other words, there are no parentheses, and the <acronym>TOS</acronym> is always <varname role="register">st0</varname>, never just <function role="opcode">st</function>.
The Packed Decimal Format
The <emphasis>packed decimal</emphasis> format uses 10 bytes (80 bits) of memory to represent 18 digits. The number represented there is always an <emphasis>integer</emphasis>.
You can use it to get decimal places by multiplying the <acronym>TOS</acronym> by a power of 10 first.
The highest bit of the highest byte (byte 9) is the <emphasis>sign bit</emphasis>: If it is set, the number is <emphasis>negative</emphasis>, otherwise, it is <emphasis>positive</emphasis>. The rest of the bits of this byte are unused/ignored.
The remaining 9 bytes store the 18 digits of the number: 2 digits per byte.


No matching activity found.

Browse all component changes

Things to check

Long untranslated

The string has not been translated for a long time


Multiple failing checks

Following checks are failing:
Mismatched full stop: Portuguese (Brazil)
Trailing space: Portuguese (Brazil)


Source information

Source string comment
(itstool) path: sect2/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/developers-handbook.pot, string 1964