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

Source string Read only

(itstool) path: step/para
Context English State
The Dark Side of Buffering
This change prevents a mysterious lockup in a very specific case. I refer to it as the <emphasis>dark side of buffering</emphasis>, mostly because it presents a danger that is not quite obvious.
It is unlikely to happen with a program like the <application>csv</application> above, so let us consider yet another filter: In this case we expect our input to be raw data representing color values, such as the <emphasis>red</emphasis>, <emphasis>green</emphasis>, and <emphasis>blue</emphasis> intensities of a pixel. Our output will be the negative of our input.
Such a filter would be very simple to write. Most of it would look just like all the other filters we have written so far, so I am only going to show you its inner loop:
.loop:
call getchar
not al ; Create a negative
call putchar
jmp short .loop
Because this filter works with raw data, it is unlikely to be used interactively.
But it could be called by image manipulation software. And, unless it calls <function>write</function> before each call to <function>read</function>, chances are it will lock up.
Here is what might happen:
The image editor will load our filter using the C function <function>popen()</function>.
It will read the first row of pixels from a bitmap or pixmap.
It will write the first row of pixels to the <emphasis>pipe</emphasis> leading to the <varname>fd.in</varname> of our filter.
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.

Loading…

No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

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

Reset

Source information

Source string comment
(itstool) path: step/para
Flags
read-only
Source string location
book.translate.xml:12603
String age
a year ago
Source string age
a year ago
Translation file
books/developers-handbook.pot, string 1953