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

Translation

(itstool) path: sect2/para
English
This differs slightly from what <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> says. That is because <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> describes the C version.
262/2560 · 256
Context English Persian State
Another approach is by using an array of function pointers, something like this: روشی دیگر استفاده از یک آرایه از اشاره‌گرهای تابع است، چیزی مانند این:
(output[state])(inputchar); (output[state])(inputchar);
Yet another is to have <varname>state</varname> be a function pointer, set to point at the appropriate function: با این‌حال روش دیگر داشتن <varname>state</varname> به‌عنوان یک اشاره‌گر تابع است، که برای اشاره کردن به تابع مورد نظر تنظیم شود:
(*state)(inputchar); (*state)(inputchar);
This is the approach we will use in our program because it is very easy to do in assembly language, and very fast, too. We will simply keep the address of the right procedure in <varname role="register">EBX</varname>, and then just issue: این روشی‌ست که ما در برنامهٔ خودمان استفاده می‌کنیم زیرا استفاده از آن در زبان همگذاری بسیار آسان است، و همچنین بسیار سریع. نشانی روش صحیح را در <varname role="register">EBX</varname> نگه می‌داریم، و سپس می‌نویسیم:
call ebx call ebx
This is possibly faster than hardcoding the address in the code because the microprocessor does not have to fetch the address from the memory—it is already stored in one of its registers. I said <emphasis>possibly</emphasis> because with the caching modern microprocessors do, either way may be equally fast. این روش احتمالاً سریع‌تر از سخت‌کد کردن نشانی در کد است زیرا ریزپردازنده نیازی به گرفتن نشانی از حافظه ندارد—از پیش در یکی از ثبات‌هایش ذخیره شده است. من گفتم <emphasis>احتمالاً</emphasis> زیرا با ذخیره‌سازی‌ای که ریزپردازنده‌های امروزی انجام می‌دهند، هر دو روش ممکن است به یک اندازه سریع باشند.
Memory Mapped Files پرونده‌های حافظه نگاشت‌شده
Because our program works on a single file, we cannot use the approach that worked for us before, i.e., to read from an input file and to write to an output file. از آنجه که برنامهٔ ما در یک پروندهٔ واحد کار می‌کند، نمی‌توانیم از روشی که پیش‌تر به ما جواب داده است استفاده کنیم، برای مثال، خواندن از یک پروندهٔ ورودی و نوشتن در یک پروندهٔ خروجی.
<trademark class="registered">UNIX</trademark> allows us to map a file, or a section of a file, into memory. To do that, we first need to open the file with the appropriate read/write flags. Then we use the <function role="syscall">mmap</function> system call to map it into the memory. One nice thing about <function role="syscall">mmap</function> is that it automatically works with virtual memory: We can map more of the file into the memory than we have physical memory available, yet still access it through regular memory op codes, such as <function role="opcode">mov</function>, <function role="opcode">lods</function>, and <function role="opcode">stos</function>. Whatever changes we make to the memory image of the file will be written to the file by the system. We do not even have to keep the file open: As long as it stays mapped, we can read from it and write to it. <trademark class="registered">UNIX</trademark> این امکان را به ما می‌دهد تا یک پرونده، یا قسمتی از یک پرونده را نگاشت کنیم. برای انجام آن، ابتدا باید پرونده را با نشان‌های خواندن/نوشتن مناسب باز کنیم. سپس از فراخوان سامانهٔ <function role="syscall">mmap</function> برای نگاشت آن در حافظه استفاده می‌کنیم. یک چیز خوب در مورد <function role="syscall">mmap</function> این است که به‌طور خودکار با حافظهٔ مجازی کار می‌کند: می‌توانیم نسبت به حافظهٔ فیزیکی موجودی که داریم قسمت بیش‌تری از پرونده را در حافظه نگاشت کنیم، اما در عین حال به‌واسطهٔ کدهای دستوری معمولی به آن دسترسی داشته باشیم، مانند <function role="opcode">mov</function>، <function role="opcode">lods</function>، و <function role="opcode">stos</function>. هر تغییری که در تصویر حافظهٔ پرونده ایجاد می‌کنیم از طریق سامانه در پرونده نوشته می‌شود. حتی نیازی به باز نگاه داشتن پرونده نیست: تا زمانی که نگاشت‌شده بماند، می‌توانیم از آن بخوانیم و در آن بنویسیم.
The 32-bit Intel microprocessors can access up to four gigabytes of memory – physical or virtual. The FreeBSD system allows us to use up to a half of it for file mapping. ریزپردازنده‌های ۳۲ بیتی اینتل می‌توانند تا ۴ گیگابایت از حافظه دسترسی داشته باشند - فیزیکی یا مجازی. سامانهٔ FreeBSD به ما این امکان را می‌دهد تا نیمی از آن را برای نگاشت پرونده استفاده کنیم.
For simplicity sake, in this tutorial we will only convert files that can be mapped into the memory in their entirety. There are probably not too many text files that exceed two gigabytes in size. If our program encounters one, it will simply display a message suggesting we use the original <application>tuc</application> instead. به‌خاطر سادگی، ما در این آموزه تنها پرونده‌هایی را که به‌طور کامل می‌توانند در حافظه نگاشته شوند را تبدیل می‌کنیم. احتمالاً پرونده‌های متنی بسیاری وجود ندارند که اندازه‌شان از ۲ گیگابایت فراتر رود. اگر برنامهٔ ما با یکی از آنها برخورد کند، پیامی نمایش می‌دهد که پیشنهاد می‌دهد به جای آن از <application>tuc</application> اصلی استفاده کنیم.
If you examine your copy of <filename>syscalls.master</filename>, you will find two separate syscalls named <function role="syscall">mmap</function>. This is because of evolution of <trademark class="registered">UNIX</trademark>: There was the traditional <acronym>BSD</acronym> <function role="syscall">mmap</function>, syscall 71. That one was superseded by the <acronym><trademark class="registered">POSIX</trademark></acronym> <function role="syscall">mmap</function>, syscall 197. The FreeBSD system supports both because older programs were written by using the original <acronym>BSD</acronym> version. But new software uses the <acronym><trademark class="registered">POSIX</trademark></acronym> version, which is what we will use. اگر نسخهٔ خود از <filename>syscalls.master</filename> را بیازمایید، با دو فراخوان سامانهٔ جداگانه به نام <function role="syscall">mmap</function> مواجه می‌شوید. این به خاطر سیر تکاملی <trademark class="registered">UNIX</trademark> است: یک فراخوان سامانهٔ سنتی داشتیم، <acronym>BSD</acronym><function role="syscall">mmap</function> فراخون سامانهٔ 71. آن فراخوان توسط <acronym><trademark class="registered">POSIX</trademark></acronym><function role="syscall">mmap</function>، فراخوان سامانهٔ 197 جایگزین شد. سامانهٔ FreeBSD از هر دوی آنها پشتیبانی می‌کند زیرا برنامه‌های قدیمی به‌وسیلهٔ نسخهٔ اصلی <acronym>BSD</acronym> نگاشته شده‌اند. اما نرم‌افزار جدید از نسخهٔ <acronym><trademark class="registered">POSIX</trademark></acronym> استفاده می‌کند، که همان چیزیست که استفاده می‌کنیم.
The <filename>syscalls.master</filename> lists the <acronym><trademark class="registered">POSIX</trademark></acronym> version like this: <filename>syscalls.master</filename> نسخهٔ <acronym><trademark class="registered">POSIX</trademark></acronym> را بدین شکل فهرست می‌کند:
197 STD BSD { caddr_t mmap(caddr_t addr, size_t len, int prot, \
int flags, int fd, long pad, off_t pos); } 		197 STD BSD { caddr_t mmap(caddr_t addr, size_t len, int prot, \
int flags, int fd, long pad, off_t pos); }
This differs slightly from what <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> says. That is because <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> describes the C version. این نسبت به آنچه که <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> می‌گوید تفاوت نسبی دارد. به این خاطر که <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> نسخهٔ C را توضیح می‌دهد.
The difference is in the <varname>long pad</varname> argument, which is not present in the C version. However, the FreeBSD syscalls add a 32-bit pad after <function role="opcode">push</function>ing a 64-bit argument. In this case, <varname>off_t</varname> is a 64-bit value. تفاوت در برهان <varname>long pad</varname> است، که در نسخهٔ C موجود نیست، فراخوان‌های سامانهٔ FreeBSD یک پَد ۳۲ بیتی بعد از <function role="opcode">push</function> کردن یک برهان ۶۴ بیتی اضافه می‌کنند. در این مورد، <varname>off_t</varname> یک مقدار ۶۴ بیتی است.
When we are finished working with a memory-mapped file, we unmap it with the <function role="syscall">munmap</function> syscall: هنگامی‌که کار ما با پروندهٔ memory-mapped تمام شد، نگاشت آن را با فراخوان سامانهٔ <function role="syscall">munmap</function> لغو می‌کنیم:
For an in-depth treatment of <function role="syscall">mmap</function>, see W. Richard Stevens' <link xlink:href="http://www.int80h.org/cgi-bin/isbn?isbn=0130810819">Unix Network Programming, Volume 2, Chapter 12</link>. برای مطالعهٔ عمیق <function role="syscall">mmap</function>، به <link xlink:href="http://www.int80h.org/cgi-bin/isbn?isbn=0130810819">Unix Network Programming, Volume 2, Chapter 12</link> از W. Richard Stevens مراجعه کنید.
Determining File Size تعیین اندازهٔ پرونده
Because we need to tell <function role="syscall">mmap</function> how many bytes of the file to map into the memory, and because we want to map the entire file, we need to determine the size of the file. از آنجا که باید تعداد بایت‌هایی که درون حافظه نگاشت می‌کنیم را به <function role="syscall">mmap</function> اعلام کنیم، و چون می‌خواهیم تمام پرونده را نگاشت کنیم، باید اندازهٔ پرونده را تعیین کنیم.
We can use the <function role="syscall">fstat</function> syscall to get all the information about an open file that the system can give us. That includes the file size. می‌توانیم از فراخوان سامانهٔ <function role="syscall">fstat</function> برای بدست آوردن تمام اطلاعات مربوط به پروندهٔ بازی که سامانه می‌تواند به ما بدهد استفاده کنیم. این اطلاعات شامل اندازهٔ پرونده می‌شود.
Again, <filename>syscalls.master</filename> lists two versions of <function role="syscall">fstat</function>, a traditional one (syscall 62), and a <acronym><trademark class="registered">POSIX</trademark></acronym> one (syscall 189). Naturally, we will use the <acronym><trademark class="registered">POSIX</trademark></acronym> version: دوباره، <filename>syscalls.master</filename> دو نسخه از <function role="syscall">fstat</function> را فهرست می‌کند، یک نسخهٔ سنتی (syscall 62)، و یک نسخهٔ <acronym><trademark class="registered">POSIX</trademark></acronym> (syscall 189). به‌طور طبیعی، از نسخهٔ <acronym><trademark class="registered">POSIX</trademark></acronym> استفاده می‌کنیم:
189 STD POSIX { int fstat(int fd, struct stat *sb); } 189 STD POSIX { int fstat(int fd, struct stat *sb); }
This is a very straightforward call: We pass to it the address of a <varname remap="structname">stat</varname> structure and the descriptor of an open file. It will fill out the contents of the <varname remap="structname">stat</varname> structure. این یک فراخوان بسیار مستقیم است: ما آن را به نشانی یک ساختمان <varname remap="structname">stat</varname> و یک توصیف‌گر پروندهٔ باز منتقل می‌کنیم. محتوای ساختمان <varname remap="structname">stat</varname> را پر می‌کند.
I do, however, have to say that I tried to declare the <varname remap="structname">stat</varname> structure in the <varname>.bss</varname> section, and <function role="syscall">fstat</function> did not like it: It set the carry flag indicating an error. After I changed the code to allocate the structure on the stack, everything was working fine. من، هرچند، لازم است خاطر نشان کنم که سعی کرده‌ام ساختمان <varname remap="structname">stat</varname> را در قسمت <varname>.bss</varname> تعریف کنم، و <function role="syscall">fstat</function> آن را دوست نداشت: نشان رقم نقلی‌ای را تعیین می‌کند که نشان‌گر خطاست . پس از آنکه کد را برای تخصیص ساختمان در پشته تغییر دادم، همه چیز به‌درستی کار می‌کرد.
Changing the File Size تغییر اندازهٔ پرونده
Because our program may combine carriage return / line feed sequences into straight line feeds, our output may be smaller than our input. However, since we are placing our output into the same file we read the input from, we may have to change the size of the file. از آنجا که برنامهٔ ما ممکن است توالی سرسطر / نوسطر را درون نوسطرهای مستقیم ترکیب ‌کند، ممکن است خروجی ما کوچک‌تر از ورودی‌مان باشد. گرچه، از آنجا که خروجی خود را در همان پرونده‌ای که ورودی را از آن می‌خوانیم قرار می‌دهیم، ممکن است مجبور به تغییر اندازهٔ پرونده باشیم.
The <function role="syscall">ftruncate</function> system call allows us to do just that. Despite its somewhat misleading name, the <function role="syscall">ftruncate</function> system call can be used to both truncate the file (make it smaller) and to grow it. فراخوان سامانهٔ <function role="syscall">ftruncate</function> این امکان را به ما می‌دهد تا دقیقاً همین کار را انجام دهیم. با وجود اسم نسبتاً‌ گمراه‌کننده‌اش، فراخوان سامانهٔ <function role="syscall">ftruncate</function> را می‌توان هم برای کوتاه کردن (کوچک‌تر کردن آن) و هم بزرگ کردن آن به کار برد.
And yes, we will find two versions of <function role="syscall">ftruncate</function> in <filename>syscalls.master</filename>, an older one (130), and a newer one (201). We will use the newer one: و بله، ما دو نسخه از <function role="syscall">ftruncate</function> را در <filename>syscalls.master</filename> پیدا خواهیم کرد، یک نسخهٔ‌ قدیمی‌تر (130) و نسخه‌ای جدیدتر (201). ما از نسخهٔ جدیدتر استفاده خواهیم کرد:
201 STD BSD { int ftruncate(int fd, int pad, off_t length); } 201 STD BSD { int ftruncate(int fd, int pad, off_t length); }

Loading…

User avatar qps

New translation

FreeBSD Doc / books_developers-handbook — Persian

This differs slightly from what <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> says. That is because <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> describes the C version.
این نسبت به آنچه که <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> می‌گوید تفاوت نسبی دارد. به این خاطر که <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> نسخهٔ C را توضیح می‌دهد.
4 months ago
Browse all component changes

Glossary

English Persian
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/para
Source string location
book.translate.xml:11691
String age
7 months ago
Source string age
a year ago
Translation file
books/fa/developers-handbook.po, string 1875