(itstool) path: step/para
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.
Context English Persian State
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. این تغییر از محبوس شدن در یک مورد بسیار خاص پیش‌گیری می‌کند. من از آن به‌عنوان <emphasis>نیمهٔ تاریک میان‌گیری</emphasis> یاد می‌کنم، بیشتر به این خاطر که خطری را مطرح می‌کند که به‌طور کامل مشهود نیست.
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. احتمال وقوع آن با برنامه‌ای چون <application>csv</application> که بالاتر آمده است بعید است، از این رو بگذارید فیلتر دیگری را در نظر بگیریم: در این مورد انتظار داریم ورودی‌مان دادهٔ خامی باشد که نشان‌گر مقادیر رنگ باشد، مانند شدت‌های <emphasis>سرخ</emphasis>، <emphasis>سبز</emphasis>، و <emphasis>آبی</emphasis> از یک پیکسل. خروجی ما برخلاف ورودی‌مان خواهد بود.
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: نوشتن چنین فیلتری بسیار ساده است. اکثر آن شبیه به تمام فیلترهایی است که تابحال نوشته‌ایم، در نتیجه من فقط حلقه‌های درونی آن را نشان شما خواهم داد:
call getchar
not al ; Create a negative
call putchar
jmp short .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. اما می‌توان نرم‌افزار دستکاری تصویر را فراخوانی کرد. و، به جز آنکه <function>write</function> را قبل از هر فراخوان به <function>read</function> فراخوانی کند، احتمال محبوس شدن آن وجود دارد.
Here is what might happen: آنچه که ممکن است روی دهد:
The image editor will load our filter using the C function <function>popen()</function>. ویرایشگر تصویر فیلتر ما را با استفاده از تابع <function>popen()</function> در C بارگیری می‌کند.
It will read the first row of pixels from a bitmap or pixmap. اولین ردیف از پیکسل‌ها را از یک bitmap یا pixmap می‌خواند.
It will write the first row of pixels to the <emphasis>pipe</emphasis> leading to the <varname></varname> of our filter. اولین ردیف از پیکسل‌ها را در <emphasis>pipe</emphasis> منتهی به <varname></varname> فیلتر ما می‌نویسد.
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> را فراخوانی می‌کند تا پیکسل بعدی را بگیرد.
<function>getchar</function> will find an empty input buffer, so it will call <function>read</function>. <function>getchar</function> یک میان‌گیر ورودی خالی پیدا می‌کند، از این رو <function>read</function> را فراخوانی می‌کند.
<function>read</function> will call the <function role="syscall">SYS_read</function> system call. تابع <function>read</function> فراخوان سامانهٔ <function role="syscall">SYS_read</function> را فراخوانی می‌کند.
The <emphasis>kernel</emphasis> will suspend our filter until the image editor sends more data to the pipe. <emphasis>هسته</emphasis> فیلتر ما را تا زمانی‌که ویرایشگر تصویر داده‌های بیشتری به 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> استفاده از <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.


No matching activity found.

Browse all component changes


English Persian
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: step/para
Source string location
String age
6 months ago
Source string age
a year ago
Translation file
books/fa/developers-handbook.po, string 1954