Introduction to the Assembly Rebirth ..
مقدمه ای بر احیای زبان اسمبلی
After the oncoming of Windows 3, Assembly had been considered a dead Language by many programmers (including myself).
بعد از به روی کار آمدن ویندوز 3 ، زبان اسمبلی از طرف بسیاری از برنامه نویسان ( از جمله خودم ، رنه تورنویس ) به عنوان یک زبان مرده تلقی شد .
During the years 1995-2000 a couple of pioneers achieved forcing open the closed door.
در طول سالهای 1995 تا 2000 میلادی ، یک گروه از داوطلبان سعی کردند که درب بسته را باز کنند . ( یعنی زبان اسمبلی را احیا نمایند . در اینجا زبان اسمبلی به یک صندوقچه تشبیه شده که به عمق دریا انداخته شده و حالا یک گروه غواص قصد داشتند زور بزنند تا بتوانند در اعماق اقیانوس و با شرایط سخت اقیانوس از جمله فشار بسیار زیاد آب بر روی درب صندوق که مانع از باز شدن درب می شود ، درب این صندوقچه یعنی زبان اسمبلی را باز نمایند !!! . نویسنده مقاله ( رنه تورنویس طراح روسسم ) از قدرت تخیل خود برای تشبیه شرایط بسیار دشوار احیای زبان اسمبلی استفاده کرده است . )
In between time, any request sent to M$, for 'How to program in assembly under Windowz?' regularly got the same answer: 'Impossible! Windows being a C interface, it must be programmed in C...'.
در این زمان ، هر درخواستی که به شرکت پول پرست مایکروسافت ارسال می شد و حاوی این سوال بود که " چطوری می توانیم تحت ویندوز با زبان اسمبلی برنامه بنویسیم ؟؟؟" معمولا یک پاسخ یکسان دریافت می کرد :
پاسخ مایکروسافت :
( بخوانید : پاسخ بیل گیتس نابغه خطاب به برنامه نویسان اسمبلی ) :
" غیرممکن است ! ویندوز با یک رابط گرافیکی کاربر که توسط زبان سی ساخته شده تناسب و سازگاری دارد ، آن (= ویندوز ) باید در زبان سی نوشته شود..... "
The interest of dominant Companies for killing Assembly is quite evident:
They can't sell anything to assembler programmers.
Particularly not illusions.
علاقه ی شرکتهای غالب ( پیروز میدان جنگ ) برای به قتل رساندن زبان اسمبلی ، به حد کافی مشهود (= واضح ) است :
آنها ( شرکتهای کامپیوتری ) نمی توانند هیچ چیزی ( نرم افزار - سیستم عامل - زبان برنامه نویسی - درایور - بازی کامپیوتری - آنتی ویروس و .... ) را به برنامه نویسان زبان اسمبلی بفروشند .
( توضیح مترجم : زیرا اسمبلی نه فقط قدرتمندترین زبان برنامه نویسی جهان است بلکه قدرتمندترین ابزار هک و کرک نیز می باشد و به راحتی می توانید با کمک زبان اسمبلی ، نرم افزارهای تجاری و گران قیمت و انحصاری ، را رایگان و آزاد و اوپن سورس نمایید و این کاملا به ضرر شرکتهای نرم افزاری می باشد خصوصا مایکروسافت و شرکای تجاری اش ( ادوبی - اتودسک - اینتل - انویدیا - اچ پی - دل - و صدها شریک تجاری که همگی دشمن آزادی و بصیرت می باشند ) .
باید توجه داشت که بعد از انتشار اولین نسخه از سیستم عامل یونیکس ، هم یونیکس و هم نرم افزارهایش بصورت کاملا رایگان و همراه با کد منبع در میان دانشگاهها و موسسات و آزمایشگاهها و شرکتها و حتی کاربران خانگی دست به دست می شد و همه این سورس کد را به یکدیگر هدیه می دادند تا اینکه بیل گیتس نابغه با هوش تجاری سرشاری که داشت با ارسال نامه ای سرگشاده خطاب به سران و بزرگان دنیای نرم افزار به آنها گفت که اینکار موجب دلسرد شدن برنامه نویسان و کاهش انگیزه می شود و....
اینگونه شد که این افراد در دهه ی 80 میلادی به حرف بیل گیتس گوش دادند و علاوه بر سیستم عامل یونیکس ، سایر سیستم عاملها و نرم افزارها بصورت پولی و انحصاری و کدبسته و با قیمت بسیار بالا و با محدودیتهای شدید تحت عنوان قانون کپی رایت به کاربران خانگی یا سازمانی فروخته شد که این فاجعه هنوز هم در زمان حال یعنی در سال 2022 میلادی در حال وقوع است و این فاجعه فقط یک سر داشت که به بیل گیتس پول پرست ختم می شد .
سرنخ این فاجعه در دستان بیل گیتس است .
بهرحال با زبان اسمبلی می توانید نرم افزارهای پولی و انحصاری و کدبسته را به نرم افزارهای رایگان و اوپن سورس و آزاد تبدیل نمایید .
نمونه های بارز این تبدیل نرم افزار کدبسته به نرم افزار کد باز با کمک زبان اسمبلی : تبدیل کردن ویندوز به سیستم عامل ری اکت او اس یا تبدیل کردن مایکروسافت آفیس به اوپن آفیس یا لیبره آفیس و تبدیل کردن اتوکد به لیبره کد و تبدیل کردن فوتوشاپ به گیمپ و تبدیل کردن کورل دراو به اینک اسکپ و صدها نمونه ی مختلف که امروزه تحت عنوان نرم افزار آزاد و اوپن سورس و رایگان ، در اختیار همه قرار دارند .
تمام نرم افزارهای آزاد و رایگان و اوپن سورس ، با کمک زبان اسمبلی توانستند از دل مادر انحصاری شان متولد شوند . این یک حقیقت محض است که متاسفانه کمتر کسی به آن توجه می کند . کمتر کسی در دنیا قدرشناس زبان اسمبلی می باشد و به این زبان بها می دهد و این یک فاجعه است . )
+
به منظور جلوگیری از اطاله ی کلام و ترجمه ی ناقص و طولانی شدن پست ، مابقی متن را صرفا ترجمه می کنم و از تفسیر و توضیح خودداری می نمایم . تفسیر را بر عهده ی خودتان می گذارم .
وحیدمی .
تاریخ ترجمه و تفسیر : سه شنبه 7 تیر 1401 شمسی ساعت 9 و 25 دقیقه شب .
مابقی متن را در وقتی دیگر ترجمه خواهم کرد . انشاا...
از پاراگراف بعدی ، صرفا ترجمه خواهم کرد و هیچگونه تفسیر ارائه نمی شود تا این پست به سرنوشت دردناک پست pe.txt دچار نشود .
Despite the recent rebirth, the disaster is still actual, as we can see each time we read some papers with titles like [Why Assembly] or [Assembly advantages].
با وجود احیای اخیر ، فاجعه هنوز واقعی است ، از انجاییکه ما می توانیم هر زمان ببینیم ما برخی کاغذها ( نوشته ها - مطالب - مقاله ها ) با عناوینی همچون ( چرا اسمبلی ؟) یا ( مزایای اسمبلی ) را هنوز هم می بینیم .
(توضیح مترجم : آقای رنه تورنویس طراح اسمبلر RosAsm یک فرانسوی بودند و زبان انگلیسی شان ضعیف بود و البته در پایان این فایل ، خودشان به این ضعف اقرار می کند که بعدا به آن می رسیم و من عین متن را برایتان می نویسم و ترجمه می کنم . لذا کار ترجمه نیز برای من بسیاربسیار دشوار است زیرا با یک متن غیراستاندارد روبرو هستم که ترجمه کردن اش واقعا سخت و پر از غلط نحوی می باشد . بابت ترجمه ی گنگ و مبهم و اشتباهات گرامری و نحوی ، از شما کاربران گرامی عذرخواهی می کنم . وحیدمی ) .
Yet now, it is regularly stated that Assembly is interesting because of its capacity at producing Small and Fast Code, ... by HLL programmers making use of Asm Routines...
هنوز هم در زمان حال ، بطور منظم این موضوع توضیح داده می شود که زبان اسمبلی بخاطر توانایی اش در تولید کد سریع و کوچک بوسیله ی برنامه نویسان زبانهای سطح بالا (HLL) که روتین های اسمبلی را در میان کد زبان سطح بالا ( سی ، سی پلاس پلاس ، پاسکال و ... ) می نویسند ، جالب و بامزه است . ( هنوز هم در سال 2022 میلادی ، ما با این دست از نوشته ها در وب فارسی و انگلیسی و ... روبرو هستیم که تنها مزیت زبان اسمبلی را در تولید کد کوچک و سریع می دانند !!!) .
The sub-line of such claims is always that Assembly is just good for producing inline routines in order to improve the HLLs productions performance quality and to overcome their limitations, but that writing Applications in Assembly would be a strange idea coming from guys unable to use ''the proper tool for the proper thing''.
سرچشمه ی چنین ادعاهایی همیشه این است که اسمبلی فقط برای تولید روتینهای درونی و به منظور بهینه سازی کیفیت کارایی محصولات زبانهای سطح بالا و مغلوب کردن ( از بین بردن ) محدودیتهای زبانهای سطح بالا ، خوب و مفید است ، اما اینکه نوشتن برنامه های کاربردی در زبان اسمبلی می تواند یک ایده ی قوی باشد که از طرف افرادی مطرح می شود که در بکارگیری " ابزار مناسب برای چیز مناسب " ناتوان هستند !! (بابت ترجمه ی گنگ و نامفهوم عذرخواهی می کنم . یک تناقض در نوشتار نویسنده دیده می شود که مرا متحیر کرده است زیرا این ایده اتفاقا به نفع زبان اسمبلی است نه به ضررش . این تناقض را در پاراگراف بعدی متوجه خواهید شد . وحیدمی ) .
These ideas are basically unfounded and stupid from every point of view:
این ایده ها اساسا از هرنقطه نظر ( از هرجهت که فکرش را بکنید ) ، غیرقابل اتکا و احمقانه هستند(!!!) :
If Assembly interest is the speed of produced Code, with the actual Processors performances, the argument is very weak, and the Processors evolutions will go on and on, pushing to stupid and dirty programming methods.
اگر مزیت اسمبلی ( نسبت به زبانهای سطح بالا ) در سرعت بالای کد تولید شده ( کد باینری) می باشد ، با کارایی های پردازنده های واقعی ، این دلیل ، خیلی ضعیف است و تکامل های نسلهای پردازنده ها ، به سمت تحمیل متدهای احمقانه و کثیف برنامه نویسی پیش خواهد رفت . ( امروزه در سال 2022 میلادی نیز این مزیت را از زبان طرفداران زبانهای سطح بالا می شنویم و جالب اینکه این افرد نیز می گویند که سرعت بالای اسمبلی دیگه یک مزیت نیست زیرا پردازنده ها بسیار سریع و قدرتمند شده اند !!! اما من با این حرف طرفداران زبانهای سطح بالا که سو استفاده از این حرف رنه تورنویس می باشد کاملا مخالف هستم زیرا ما همیشه به سرعت بالا نیاز داریم حتی در پردازنده های فوق سریع و قدرتمند . بنابراین ، برخلاف رنه تورنویس و طرفداران زبانهای سطح بالا ، من یعنی وحیدمی ، معتقدم که هرچه سرعت بیشتر باشد بهتر است و زبان اسمبلی به دلیل سرعت بسیار بالا یک مزیت بزرگ محسوب می شود .) .
If Assembly interest is at the size of produced Code, the argument is completely ridiculous, given the actual Hard Disks capacities and given the modern OSes Memory Manager's performances.
اگر مزیت اسمبلی ( نسبت به زبانهای سطح بالا ) در تولید کد کوچک و کم حجم و فشرده ( در قالب کدهای زبان ماشین در شکم نرم افزار) و ایجاد نرم افزارهای کوچک و فشرده ، باشد ، این دلیل نیز کاملا مضحک (خنده دار ) است ، البته با توجه به افزایش ظرفیتهای هارد دیسک و افزایش کارایی های مدیر حافظه ی سیستم عاملهای مدرن ( ویندوز و ...) .
( متاسفانه طرفداران زبانهای سطح بالا بازهم از این حرف رنه تورنویس سو استفاده کردند و امروزه در سال 2022 میلادی شبیه به همین حرفها را می شنویم . اما من یعنی وحیدمی معتقدم که حتی هارد دیسک یا دیسک جامد با ظرفیت 1024 ترابایت (= 1 پتا بایت ) نیز دلیل خوبی برای تولید کد حجیم و زهوار دررفته و پخش و پلا نیست . من خودم با فلت اسمبلر برنامه می نوشتم و سعی می کردم نرم افزارهای بسیار ریز و کوچک و فشرده و تک سکشن و ایمن و کمتر از 1 کیلوبایت را روی هارد دیسک 1 ترابایتی تولید کنم چون اینطوری می توانستم راحتتر با هگز ادیتور برنامه نویسی کنم یعنی این برنامه ها را به الگوهایی برای برنامه نویسی با هگز ادیتور تبدیل می کردم . شخصا از نرم افزارهای حجیم و باد افزار که دهها سکشن و میلیونها کد 00 احمقانه و فضای خالی در لابلای سکشن ها دارند و به راحتی ویروسی و آلوده می شوند نفرت دارم و بیزارم . من طرفدار برنامه نویسی مینی مالیستی هستم . شخصا از فلت اسمبلر و البته هگز ادیتور به دلیل تولید نرم افزار کوچک و فشرده و تک سکشن و ایمن خوشم می آید . این مزیت تولید کد کوچک و فشرده و ایمن ، اتفاقا یک مزیت عالی برای زبان اسمبلی محسوب می شود و خوشبختانه امروزه طرفداران زبان اسمبلی ( فلت اسمبلر و نتواید اسمبلر ) از این مزیت به نفع خودشان و بقیه کاربران استفاده می کنند . وحیدمی) .
Another commonly expressed opinion is that Assembly is more difficult, more error prone and more dangerous than HLLs.
نظر رایج بیان شده ی دیگر اینست که : اسمبلی ، دشوارتر ، خطا سازتر (تولید کننده ی باگ) و خطرناکتر از زبانهای سطح بالا می باشد .
This is partially true for the real beginner, who has to learn, at once, a lot of things, (like with any programming Language), plus the 20 Mnemonics we regularly use in Assembly Applications programming, plus the Asm Data Managements. With actual Assemblers and actual OSes, the Assembly ''difficulties'' are less and less true.
این عقیده ، تا حدودی صحیح است برای مبتدیان واقعی ، که مجبورند یاد بگیرند ، در یک زمان کوتاه ، چیزهای بسیار زیاد ، ( مانند هر زبان برنامه نویسی دیگری ) ، به علاوه تعداد 20 کد یادیار (دستورات زبان اسمبلی ) که ما معمولا بکار می بریم در برنامه نویسی نرم افزارهای تولید شده با زبان اسمبلی ، به علاوه ی مدیریت های داده در زبان اسمبلی ، اما با اسمبلرهای واقعی و سیستم عامل های واقعی ، این " دشواریهای زبان اسمبلی" ، روز به روز کمتر و کمتر می شود .
( ببینید شما حتی در زبان برنامه نویسی انگلیسی یا همان Plain English Programming با نام cal3040.exe که سطح بالاترین و قابل فهم ترین زبان دنیا می باشد مجبورید برای تولید یک برنامه ی ساده ی سلام جهان ، صدها خط کد احمقانه بنویسید در حالیکه در اسمبلر روسسم اینکار تنها با هفت خط کد امکان پذیر است . در مورد زبانهای پاسکال وبیسیک و سی و سی پلاس پلاس و پایتون و ... نیز شما در حالت کلاسیک و سنتی مجبورید هزاران خط کد بنویسید . پس این اصلا یک عیب برای زبان اسمبلی محسوب نمی شود درضمن ، روسسم ثابت کرد که اسمبلی اصلا دشوار نیست و ساده و قابل فهم و بی خطر است . وحیدمی ) .
After the first learning steps, not only has this turned false, but one can even see that Asm is often times easier than HLLs.
بعد از طی کردن مراحل اولیه ی یادگیری زبان اسمبلی ، نه فقط این بهانه ، غلط از آب در می آید ، بلکه هرکسی می تواند حتی ببینید که زبان اسمبلی در اکثر اوقات ، بسیار آسان تر و قابل فهمتر از زبانهای سطح بالا (HLLs) می باشد .
Generally speaking, actual Assembly Sources tend to be much more readable than, say, the usual 'Write-Only' cryptic C and C++ Sources.
مخلص کلام ! ، سورس کدهای اسمبلی واقعی قصد دارند که از ، مثلا ، سورس کدهای رایج رمزی " فقط - نوشتنی " زبانهای سی و سی پلاس پلاس خواناتر و قابل فهمتر باشند .
( اگر به سورس کدی که با زبانهای سی یا سی پلاس پلاس نوشته باشید نگاه کنید می بینید که بدون کامنت و توضیح نمی توانید آنرا بفهمید و عملا خودتان هم نمی فهمید چی نوشتید زیرا این دو زبان مازوخیستی و عوام فریب ، واقعا سینتاکس کثیف و شلخته و درهم و برهم و گنک و نامفهوم و پیچیده و شلوغ دارند . اختراع زبانهای سی و سی پلاس پلاس احمقانه ترین کاری بود که دنیس ریچی و سایر افراد مرتکب شدند ( اسم مخترع زبان سی پلاس پلاس را نمی توانم به خاطر بسپارم !!! اسم خودش نیز مثل اسم زبان اش پیچیده و دشوار است البته مخترع زبان سی پلاس پلاس ، هنوز هم زنده است اما تا پول ندهی حاضر نیست زبان سی پلاس پلاس را به تو تحویل دهد !!! . به درک . به جهنم ! . من که به این آشغال کثیف و پیچیده و مبهم یعنی زبان سی پلاس پلاس هیچ نیازی ندارم زیرا زبان اسمبلی را در اختیار دارم که بسیار ساده و تمیز و شسته و قابل فهم و همه منظوره و خالص و استاندارد و قدرتمند و رایگان و اوپن سورس و آزاد است . گور پدر زبانهای سی و سی پلاس پلاس و مخترعین شان . وحیدمی) ) .
Also, because of the fact that Assembly offers a One-to-One correspondence between what you write and the outputted Code, debugging is made a hundred times easier and much faster in Assembly than with any HLL.
همچنین ، بخاطر این حقیقت که اسمبلی ، مکاتبات و تناظر تک - به - تک بین آن چیزی که شما می نویسید (سورس کد ) و کد خروجی ( باینری یا زبان ماشین ) را عرضه می کند ، دیباگینگ ( اشکال زدایی کد برنامه ) ،در زبان اسمبلی ، صد برابر آسانتر و سریعتر از هر زبان سطح بالا (HLL) می باشد .
( دیس اسمبلی = سورس کد . یکسان بودن سورس و دیس اسمبلی . باینری= سورس . وحیدمی) .
The real difference between Assembly and HLL programming is not that at all, that an Assembly written Application would be an optimized version of what an HLL could ever output.
تفاوت واقعی و حقیقی بین برنامه نویسی با زبان اسمبلی و برنامه نویسی با زبان سطح بالا ابدا به این معنا نیست که ، یک برنامه ی نوشته شده با زبان اسمبلی می تواند یک نسخه ی بهینه شده از آن چیزی باشد که یک زبان سطح بالا هرگز نمی توانست تولید کند .
(یعنی زبان اسمبلی هرگز یک نسخه ی بهینه شده از کد زبان سطح بالا نیست که اگر نباشد آن زبان سطح بالا قادر به تولید نرم افزار نیست ( البته زبان اسمبلی در شکم کامپایلر تمام زبانهای سطح بالا حضور همیشگی دارد و هر دستور زبان سطح بالا را ابتدا به کد میانی و سپس به کد ماشین ترجمه می کند . تعریف درست کامپایلر . اما منظور از این بخش اینست که نوشتن کد اسمبلی در لابلای کد سطح بالا یک کار اشتباه است . این دو مطلب مشابه را با هم قاطی نکنید . ) . بنابراین نوشتن کدهای اسمبلی در لابلای کدهای زبان سطح بالا از قبیل پاسکال یا سی ، یک عمل احمقانه است . البته امیدوارم مرا ببخشید که اینقدر از دایره ی ادب خارج شده ام !!! . وحیدمی ) .
The first point that makes some difference is about Strategy_Optimization.
اولین نکته (نقطه) که مقداری تفاوت را بین زبان اسمبلی و زبانهای سطح بالا ایجاد می کند ، بهینه سازی -استراتژی یا استراتژی بهینه سازی ، می باشد .
( من خودم هنوز نفهمیدم که این عبارت، دقیقا چه معنایی دارد . شاید منظور ، همان بهینه سازی کد اولیه برنامه ؛ قبل از عملیات کامپایل ، می باشد . وحیدمی)
Why can't HLL programmers do real Strategy Optimizations ? Simple: When you do not have the real thing under your eyes, you simply do not know what you are really doing.
چرا برنامه نویسان زبانهای سطح بالا نمی توانند بهینه سازیهای استراتژی واقعی را انجام دهند ؟
ساده است : هنگامیکه شما چیز واقعی را زیر چشمان تان ندارید ، شما به سادگی نمی دانید و خبر ندارید از آن چیزی که واقعا دارید انجام می دهید .
( یعنی کورمال کورمال و در تاریکی و با چشم بسته ، برنامه نویسی می کنید و خودتان هم متوجه نمی شوید که زبان سطح بالا چه فاجعه ای درست می کند. اسمبلی = برنامه نویسی با چشم کاملا باز . ) .
The RosAsm Disassembler, for example, is, more or less, 120 times faster than other Disassemblers and 20 to 50 times smaller,... this is not because I am a genius and/or because the other HLL Disassemblers Authors are stupid.
دیس اسمبلر داخلی اسمبلر روسسم ، بعنوان مثال ، کم و بیش ، 120 برابر سریعتر و 20 تا 50 برابر کوچکتر از سایر دیس اسمبلرها می باشد که توسط زبانهای سطح بالا ( خصوصا پاسکال یا سی پلاس پلاس ) ساخته شده اند .
این مزیت بخاطر این نیست که من (رنه تورنویس خالق اسمبلر روسسم ) یک نابغه هستم و یا بخاطر این نیست که تولید کنندگان دیس اسمبلرهای تولید شده با زبانهای سطح بالا ، کودن و احمق هستند !
This is because, when writing with RosAsm, I can see and I can know what I am really doing, from the bottom-end to the top-end of the logical actual Application building process.
این مزیت بخاطر اینست که ، هنگام نوشتن برنامه با روسسم ( زبان اسمبلی ) ، من ( رنه تورنویس یا هر برنامه نویس دیگه ) می توانیم ببینیم و بدانیم ( آگاه باشیم ) از کاری که ما واقعا داریم انجام می دهیم ، از انتهای پایینی به انتهای بالایی جریان تولید واقعی منطقی نرم افزار !
( یعنی از سرتاسر فرایند و پروسه ی تولید منطقی یک نرم افزار کاملا مطلع هستیم و با چشم کاملا باز می بینیم و می توانیم آنرا مستقیما تغییر دهیم و بهینه کنیم .یعنی همه چیز تحت کنترل است ! ) .
This last point is the important thing.
آخرین نکته ، مطلب مهمی است .
The speed and size gains are nothing but side effects, that will have lesser and lesser interest in the future, and that have a poor direct relationship with the chosen language, but strong relationship with the strategy visibility offered by the language.
مزایایی همچون سرعت بالا و حجم کم نرم افزار در زبان اسمبلی ، چیزی بجز تاثیرات جانبی نیستند ، که به مرور زمان در آینده ( مثلا در سال 2022 میلادی ) از اهمیت آنها کمتر و کمتر می شود و اینها یک رابطه ی مستقیم ضعیف با زبان انتخابی دارند ، اما با دیدگاه استراتژی که توسط زبان تقدیم می شود ، رابطه ی قوی دارند .
( من در هرحال مخالفم ! از نظر من و البته از نظر برنامه نویسان امروزی زبان اسمبلی در سال 2022 میلادی در سایت فلت اسمبلر و سایر سایتهای معتبرخارجی و حتی ایرانی ، سرعت بالا و حجم کم هنوز هم جزو صدها مزیت زبان اسمبلی محسوب می شوند . گذشت زمان هرگز از ارزش این دو فاکتور کم نمی کند جناب رنه تورنویس عزیز !! . وحیدمی ) .
One another great point with Assembly, compared to HLLs, is that Assembly has no organization convention.
نکته ی بزرگ دیگر با زبان اسمبلی ، در مقایسه با زبانهای سطح بالا (HLLs) اینست که اسمبلی ، قرارداد سازمانی ندارد . ( یعنی قانون و قرارداد از پیش تعیین شده و تحمیلی و خشک و سازمانی ندارد و انعطاف پذیر است . وحیدمی )
HLLs authors are telling you how to write. We, Assembly programmers, are telling the Assembler what to do.
به این معنا که ، طراحان زبانهای سطح بالا دارند به شما می گویند چطوری می توان در این زبانها برنامه نویسی کرد . در حالیکه ، ما برنامه نویسان زبان اسمبلی ، داریم می گوییم که زبان اسمبلی چه کارهایی انجام می دهد .
(یعنی طراحان زبانهای سطح بالا فقط روش کلاسیک و کلیشه ای برنامه نویسی در این زبانها را به مردم یاد می دهند اما ما برنامه نویسان زبان اسمبلی به مردم می گوییم که زبان اسمبلی ذاتا چه قابلیتهای شگفت انگیز و جالبی دارد و از انعطاف پذیری و طبیعت ذاتی خود زبان حرف می زنیم نه اینکه بخواهیم روش برنامه نویسی را بصورت کلاسیک و خشک و آکادمیک به خورد کاربر بدهیم ! )
Therefore, we are responsible for our own definition(s), our own organization (s), our own style(s) and choices.
بنابراین ، ما (برنامه نویسان زبان اسمبلی ) برای تعریف هایمان ، سازماندهی هایمان ، یا برای سبکها و انتخاب های متعلق به خودمان ، پاسخگو و مسئولیت پذیر هستیم .
This makes some significant difference... Just like the difference between the wolf and dog, freedom and containment, Anarchy and Fascism.
این حقیقت ، یکسری تفاوتهای معنادار را ایجاد می کند .... مانند تفاوت بین گرگ (زبان اسمبلی ) و سگ ( زبان سطح بالا ) ، آزادی ( زبان اسمبلی ) و دیکتاتوری ( زبانهای سطح بالا ) ، دموکراسی (زبان اسمبلی ) و جنایت (زبانهای سطح بالا ) .
(بسیار شبیه به تفاوت بین لینوکس و ویندوز !! . البته من کاربر ویندوز هستم !!!! وحیدمی) .
Something even more important than freedom is achieved by this convention lack: HLLs (typically C) force the programmers to always do the things in the same way, a bit like a mentally diseased person who would always answer the same sentence to any question.
بعضی چیزها که حتی از آزادی نیز مهمتر هستند این حقیقت است که براساس فقدان قرارداد در زبان اسمبلی به دست آمده است : زبانهای سطح بالا ( بطور معمول ، زبان سی ) همیشه برنامه نویسان را به انجام دادن کارهایی در یک مسیر یکسان و کلیشه ای وادار می کنند ، قدری شبیه به یک انسان عقب مانده ی ذهنی که همیشه یک جمله ی تکراری را به سوالات مختلف می دهد !
(در دنیای برنامه نویسی ، اصطلاحا می گویند که ما هیچ فرمول جهانی و یکسان برای حل تمام مشکلات مختلف ، نداریم . اما من می گویم : داریم . خوب اش هم داریم!! : هگز ادیتور . هگز ادیتور، کلید حل تمام مشکلات دنیای برنامه نویسی و همان فرمول جهانی می باشد ولی عقب مانده نیست بلکه باهوش است . این یک استثنای بزرگ در دنیای برنامه نویسی می باشد که کمتر کسی به آن فکر می کند . البته در اینکه زبانهای سطح بالا ،یک مشت موجود عقب افتاده و کلیشه ای و کودن هستند هیچ شکی نیست و من نیز بر این نوشتار پروفسور رنه تورنویس ، مهر تایید می زنم . وحیدمی) .
In the real programming world , there is no such thing like a universal answer to the various problems we may encounter every day.
در دنیای واقعی برنامه نویسی ، چنین چیزی مانند یک پاسخ جهانی به سوالات و مشکلات مختلف که ما هر روز با آنها مواجه می شویم ، وجود ندارد . ( البته به استثنای هگز ادیتور . زیرا هگز ادیتور ، همه منظوره ترین نرم افزار و راهکار و پاسخ جهانی در دنیای برنامه نویسی واقعی و .... می باشد . وحیدمی ) .
What is good here may be stupid there.
چیزی که اینجا خوب است می تواند آنجا احمقانه باشد . ( باز هم بجز هگزادیتور که در همه جا خوب است . وحیدمی)
This flexibility, is a key for solving problems in Assembly, depending on the problem and not on the Language, is really nothing but what one usually calls... Intelligence.
انعطاف پذیری ، یک کلید برای حل مشکلات در زبان اسمبلی می باشد ، که البته بسته به مشکل دارد و نه به زبان ، واقعا چیزی نیست بجز آن چیزی که هرکس انرا معمولا بدین نام می خواند ... هوش .
(هگز ادیتور ، نهایت انعطاف پذیری و هوشمندی و تنها کلید جهانی برای حل تمام مشکلات است . وحیدمی)
The real question -out of market concerns- is now 'Why HLLs?'.
سوال واقعی - خارج از علاقه های بازار - اکنون این است " چرا زبانهای سطح بالا ؟ "
( یعنی کاری به علاقه ی کاربران به محصولات بازار ندارم . زیرا زبان اسمبلی ؛ راه خودش را می رود و کاری به خیر و شر کسی ندارد و به دنبال افزایش سهم و رقابت با محصولات بازار و سایر جنگولک بازی ها نیست . حالا می خواهم بدانم چه ضرورتی دارد که از زبانهای سطح بالا استفاده کنیم ؟؟!! .وحیدمی) .
By definition, HLLs can do nothing but applying masks upon Assembly.
براساس تعریف (قرارداد یا نام ) ، زبانهای سطح بالا ، بجز ماسک گذاری روی چهره ی زبان اسمبلی . نمی توانند هیچ کار دیگری انجام بدهند .
Masks imply limitations, lesser access to the Asm 'reality', restrictions, illusions of portability, illusions of ease of use, which have always a heavy cost, when one has to force the closed black boxes.
ماسک ها این مفهوم را می رسانند ، دسترسی کمتر به " واقعیت " اسمبلی ، محدودیتها ، توهماتی از قابلیت حمل ، توهماتی از سهولت استفاده ، که همیشه یک هزینه ی سنگین اعمال می کنند ، در هنگامیکه هرکسی مجبور باشد زور بزند تا جعبه سیاه های بسته را باز کند .
(جعبه سیاه = هر نرم افزاری که ماهیت عملکردش مخفی و مرموز باشد و نتوانیم آنرا رمزگشایی کنیم و احتمالا از ما جاسوسی می کند . وحیدمی ) .
The price you don't pay, first, you pay last. Most often... at a much higher price.
هزینه ای که شما الان نمی پردازید ، در آخر کار خواهید پرداخت . البته اغلب اوقات در یک قیمت بالاتر و گران تر .
Added to this, if we have to learn the basics of Asm, at the end, just to push-up the quality level of HLLs produced Applications, then, why use HLLs at all ?
افزون بر این ، اگر ما مجبور باشیم مبانی زبان اسمبلی را ، در نهایت فقط برای اعمال زور برای افزایش کیفیت نرم افزارهای تولید شده توسط زبانهای سطح بالا یاد بگیریم ، آنوقت ، چرا اساسا ما زبانهای سطح بالا را بکار می گیریم ؟
Once you know Assembly programming.
به محض اینکه شما برنامه نویسی با زبان اسمبلی را بدانید .
you are -unless you want to control the Processor electric impulsions- in the 'true thing' and you can do anything you want, with no more development time and no more difficulties than with any HLLs.
آنوقت شما در "جای درست" قرار دارید - بجز زمانیکه شما بخواهید پردازشهای آنی الکتریکی درون پردازنده را کنترل کنید . - و شما می توانید هرکاری که دوست دارید انجام دهید ، نه با زمان توسعه و نه با دشواریهای کار با هر زبان سطح بالا .
An important point, that misleads a lot of people, is that the HLLs so called ease-of-use, is usually not a characteristic of the Languages themselves, but is a characteristic of the user interfaces.
یک نکته ی مهم ، که تحت عنوان سهل الاستفاده بودن (کاربرپسند بودن) ، بسیاری از مردم را گمراه می کند، اینست که زبانهای سطح بالا ، خصوصیاتی از خود زبان نیستند ، بلکه خصوصیاتی از رابط کاربری می باشند .
(یعنی همان IDE که تحت عنوان دلفی یا ویژوال بیسیک یا ویژوال سی پلاس پلاس یا کد بلوک یا ... بسیاری از برنامه نویسان را فریب داده و فریب می دهند ! طوریکه برخی ها به ویژوال بیسیک لقب فناوری داده اند !!!
در حالیکه زبان برنامه نویسی یعنی کامپایلر نه IDE و نه رابط گرافیکی کاربر و نه فناوری یا چارچوب یا .... . وحیدمی )
If you may get a running DataBase in a couple of Clicks with Borland Pascal, this fact has zero relationship with the Pascal Language.
اگر شما می توانید یک دیتابیس ( بانک اطلاعاتی ) را در تنها دو کلیک با کمک زبان بورلند پاسکال ، دریافت کنید ؛ این حقیقت هیچ خویشاوندی و ارتباطی با زبان پاسکال ندارد .
( یا مثل تولید سریع نرم افزار در دلفی 6 تنها با فشردن یک دکمه یا تنها با یک کلیک تحت عنوان RAD ( توسعه ی سریع اپلیکیشن ) که یک کلاه گشاد بود که بر سر مردم گذاشتند و طراح این کلاهبرداری بعدا در شرکت مایکروسافت استخدام شد و زبان سی شارپ را اختراع کرد!!! . وحیدمی )
This is nothing but a ''Wizard'' output, and there is no reason that an Assembler could not be also featured with such Interfaces and Wizards.
این فرایند (تولید سریع نرم افزار تنها با یک کلیک ) چیزی بجز خروجی یک " جادو" نیست و دلیلی وجود ندارد که زبان اسمبلی نتواند به چنین رابطهای گرافیکی و جادوها مجهز شود .
( یعنی این فقط یک شعبده بازی است و اگر برنامه نویسی به این می گویند پس زبان اسمبلی هم می تواند با کمک این ابزارهای فریبنده و گرافیکی ، شعبده بازی کند و شما را فریب دهد و هرگز از اینکار عاجز نمی شود . وحیدمی)
The real fact is that actually, there is no such Visual Components editor implemented in any Assembler, but despite the difficulties, the Assembly Rebirth will necessarily have to go to that point, and it will.
حقیقت واقعی اینست که واقعا ، چنین ویراستار مولفه های بصری در زبان اسمبلی پیاده نشده است ، اما با وجود مشکلات ، بازتولد و احیای زبان اسمبلی ، ضرورتا مجبور است به این نقطه حرکت کند و این اتفاق خواهد افتاد .
( پروفسور رنه تورنویس از قدرت شهودی بسیار بالایی برخوردار بود و می توانست آینده ی دنیای فناوری را با کمک حس ششم و قدرت روشن بینی که داشت پیشگویی کند و امروزه شاهد درست بودن تمام این پیشگویی ها هستیم . طبق پیشگویی ایشان ، الان تمام کامپایلرهای زبان اسمبلی دارای ویراستارهای مدرن گرافیکی با امکان برنامه نویسی شیئ گرا و ویژوال و ... می باشند و روز به روز مدرن تر می شوند و از زبان اسمبلی دورتر می گردند و به سمت زبانهای سطح بالا متمایل شده اند . کاری به خوب بودن یا بد بودن این ویراستارها و این اتفاق ندارم . فقط خواستم بگویم ایشان بخوبی توانست آینده ی دنیای فناوری اطلاعات را پیشگویی نماید و صحت این پیشگویی ها را الان داریم با چشمان خود می بینیم . این نوشته به اواخر دهه ی 90 میلادی مربوط می شود و یک متن قدیمی و معتبر است . ایشان در مورد پیچیده شدن معماری پردازنده ها و کم رنگ شدن قانون مور نیز مطالبی را از سالها پیش پیش گویی کرده است که امروزه شاهد صحت این مطالب هستیم . وحیدمی )
Finally, all actual Assemblers, include good features authoring HLL as writing Styles.
نهایتا ، تمام اسمبلرهای واقعی ، ویژگیهای خوب قدرتمندانه زبانهای سطح بالا از قبیل سبکهای نگارش ( مدلهای مختلف برنامه نویسی و انعطاف پذیری) را شامل می شوند .
These High Level Assembly Styles tend to turn Asm Sources into as easy to read sources as good old time Basic.
این سبکهای اسمبلی سطح بالا قصد دارند سورس های اسمبلی را به همان سهولت خواندن منابع از قبیل دوران خوب قدیمی بیسیک ، تبدیل نمایند !
( به عنوان مثال ، فسمجی دارای یک زبان تفسیری سطح بالا می باشد که باعث شده زبان اسمبلی بر روی پردازنده های مختلف ، قابل حمل شود یا برخی مفسرهای شبیه به زبان بیسیک که در قالب ماکرو برای زبان اسمبلی ساخته شده اند . وحیدمی )
So, what ? In some way, the remaining difference between HLLs featured with inline assembly, and High-Level-able Assemblers, is that the first ones are 'Top-Down', whereas the second ones are 'Bottom-Up'.
خب ، چگونه ؟ در برخی روشها ، تفاوت باقیمانده بین ویژگیهای سطح بالا با اسمبلی درونی ، و اسمبلرهای با قابلیت سطح بالا ، اینست که مدلهای اول ، "بالا به پایین " هستند ( مثل اسمبلر درونی دلفی 6 یا ویژوال سی پلاس پلاس 6 ) ، درحالیکه مدلهای دوم ، " پایین به بالا " می باشند ( مثل اسمبلرهای RosAsm یا Fasm ) .
Top-Down is nothing but just a weird idea: Nothing ever worked that way in any natural world.
مدل بالا به پایین چیزی بجز یک ایده ی خارق العاده نیست : که نه حتی به آن روش در هیچ دنیای طبیعی کار کرده باشد. ( یعنی چیزی مثل اسمبلر درونی دلفی 6 یک چیز غیرطبیعی است که فقط یک ایده ی جذاب است اما کارایی و انعطاف پذیری و قدرت ندارد و محدود کننده است . این محدودیتها را شخصا در دلفی 6 و ویژوال سی پلاس پلاس 6 تجربه کرده ام. عملا اسمبلی توکار در این دو زبان سطح بالای معروف ، هیچ جایگاه و ارزشی و قدرتی نداشت و به شدت محدود و ضعیف شده بود و این عملا یک فریب بزرگ بود تا کاربر را از زبان اسمبلی بیزار کند لذا این دو زبان شیطانی و کثیف یعنی دلفی و ویژوال سی پلاس پلاس را برای همیشه از روی هارد کامپیوترم حذف کردم . وحیدمی) .
All programmers who really know Assembly seem to be of this opinion, that Assembly is perfectly well designed for producing full Applications:
تمام برنامه نویسانی که واقعا اسمبلی را می شناسند به نظر می رسد که این عقیده را داشته باشند ، که زبان اسمبلی برای تولید نرم افزارهای کامل و جامع ، به طرز قابل قبولی و کاملا خوب و بدون هیچ عیب و نقصی طراحی شده است :
Among the last three written Assemblers, two of them (RosAsm, FASM), directly output Applications.
در میان سه اسمبلر نوشته شده اخیر ، دوتا از آنها (RosAsm و FASM ) ، مستقیما نرم افزارها را تولید می کنند . (یعنی تنها با فشردن یک کلید ، سورس برنامه را مستقیما به فایل اجرایی با پسوند exe تبدیل می نمایند . بسیار شبیه به دلفی و فناوری RAD . وحیدمی) .
Two of them (GoAsm, RosAsm), output only PE Files.
دوتا از آنها (GoAsm و RosAsm ) ، فقط فایلهای پی ( نرم افزار ویندوزی) تولید می کنند .
So it seems that we all three authors consider that there is absolutely no reason for not using Asm for building full Applications.
بنابراین به نظر می رسد که ما هر سه طراح به این نتیجه رسیده ایم که مطلقا دلیلی وجود ندارد که برای ساختن نرم افزارهای کامل و بزرگ ، از اسمبلی استفاده نشود .
Needless to say, all three Assemblers are written in Assembly and RosAsm, being auto-compiled, offers a two Megas Octets Source demonstration.
نیازی به گفتن نیست که ، هر سه اسمبلر توسط زبان اسمبلی ساخته شده اند و RosAsm با حالت خودکامپایل ، نمایش کامپایل دو مگابایت سورس را عرضه می کند .
( سورس کد RosAsm در زمان نوشتن این فایل یعنی اواخر دهه ی 90 میلادی ، حدود 2 مگابایت بود که توسط خودش در کمتر از 1 ثانیه کامپایل و بیلد می شد و یک نسخه ی جدید از این اسمبلر را می ساخت . الان در سال 2022 میلادی حجم سورس کد RosAsm به بیش از 5 مگابایت رسیده که در کمتر از 1 ثانیه توسط خودش کامپایل می شود و این ثابت می کند که زبان اسمبلی تا چه حد قدرتمند و سریع است که می تواند سورسهای حجیم را در کمترین زمان کامپایل نماید و نیازی به زبانهای سطح بالا نداریم . وحیدمی ) .
Nevertheless, the Assembly rebirth will remain a long journey, as we will have to slowly rebuild a user base from zero, mainly with real beginners.
با این وجود ، نهضت احیای زبان اسمبلی ، یک سفر طولانی در پیش دارد ، بدلیل اینکه ما مجبور خواهیم شد به کندی یک مبنای کاربر را ، از صفر ، اساسا با مبتدیان واقعی احیا کنیم .
Several facts will dramatically slow down this rebirth.
حقایق متعددی بطور چشمگیری ، این بازتولد و احیا را کند خواهند کرد .
The first one is, of course, the existence of a group of HLLs programmers using and defending Microsoft MASM, which, alas, is actually the Main-Stream, and which, alas, will go on misleading beginners for several years, wasting a lot of effort on a dead end road.
اولین حقیقت این است ، البته ، وجود یک گروه از برنامه نویسان زبانهای سطح بالا با بکارگیری و دفاع کردن از مایکروسافت مسم ، که ، جریان اصلی مخالف احیا می باشد ، و اینکه به سمت گمراه سازی مبتدیان در طول سالهای طولانی پیش خواهد رفت ، همراه با اتلاف تلاش ها روی یک کوره راه و مسیر مرده .
The second fact comes from us, the Assemblers' authors, as we have been unable to federalize our works.
حقیقت دوم از سمت ما می آید ، طراحان اسمبلرها ، از انجاییکه ما ناتوان بوده ایم در فدرالیزه کردن کارهایمان .
( یعنی یک استاندارد جهانی برای گرامر زبان اسمبلی طراحی نکردیم و کارهایمان را مطابق استانداردهای جهانی هماهنگ نکردیم با همدیگه متحد و یکدل نشدیم و هرکسی طبق سلیقه ی شخصی خودش یک کامپایلر برای زبان اسمبلی ساخت و کارهایمان را با همدیگه سازگار و یکسان نکردیم . وحیدمی)
Not only several Projects are running on different roads, but, even worse, despite my repeated efforts, we have never been able to define any generally accepted syntax common base (!!!...). A third and recent event will delay the Assembly Rebirth for several years:
نه فقط پروژه های متعدد در حال اجرا روی روشهای متفاوت می باشند ، بلکه حتی به روش غلط ، با وجود تلاشهای تکراری من ( رنه تورنویس ) ، ما هرگز قادر نبودیم یک مبنای مشترک سینتاکس متفق القول عمومی را برای زبان اسمبلی تعیین کنیم (!!!!....) .
یک رویداد سوم و کنونی ، نهضت احیای زبان اسمبلی را تا سالهای سال به تاخیر خواهد انداخت :
The oncoming of HLA (an HLL Pre-Parser to other Assemblers, that its Author calls 'An Assembler'), and the book publication of associated Tutorials, are going to dry out the tiny flow of Assembly new comers for all the serious Assemblers Projects.
به روی کار آمدن اسمبلی سطح بالا ( رندل هاید ) ( یک پیش - تجزیه گر برای سایر اسمبلرها ، که طراح اش آنرا " یک اسمبلر " می نامد ) ، و انتشار کتاب خودآموزهای وابسته ، به منظور خشک سازی ( ایجاد خشکسالی مصنوعی ) رودخانه ی ضعیف زبان اسمبلی برای افراد جدید برای تمام پروژه های مهم اسمبلی .
... So that the upcoming situation is actually as follows:
در حال حاضر وضعیت واقعا به شکل زیر است :
1) Very few Assembly Programmers.
1- تعداد اندک برنامه نویسان زبان اسمبلی
2) 50% of those very few, lost for ever to MASM.
2- پنجاه درصد از این تعداد اندک ، تا ابد در بیراه ی مسم ، از دست می روند .
3) The remainder, divided into GoAsm, RosAsm, FASM and NASM, ...
3- باقیمانده ی افراد ، تقسیم می شوند به گوآسم و روسسم و فسم و نسم و ....
4) Among the new Assemblers, only two (NASM and RosAsm) are GPLed and open to collective developments, while the others are clearly ''Anti-GPL'' (!?!?!?...).
4- در میان اسمبلرهای جدید ، فقط دوتا ( نسم و روسسم ) دارای لایسنس گنو جی پی ال هستند و برای توسعه های جمعی ، باز می باشند ، در حالیکه سایرین بطور شفاف ، " آنتی جی پی ال " می باشند (!؟!؟!؟!!؟؟.....)
(مدتی است که نسم ( Nasm ) از لایسنس BSD استفاده می کند زیرا به این نتیجه رسیده است که لایسنس گنو باعث ایجاد مشتق ها و فورکهای موازی و ضعیف می شود و همان بلایی که بر سر سیستم عامل گنو لینوکس و اسمبلر روسسم آمد ممکن است بر سر او نیز بیاید . من خودم شخصا با لایسنس گنو مخالف هستم زیرا لایسنس گنو نوعی دیکتاتوری جدید را بر برنامه نویس تحمیل کرده و اصالت نرم افزار را نیز از بین می برد و نرم افزار دچار مشتق های ناسازگار می شود و از درجه ی اعتبار ساقط می گردد و از حمایت شرکتها و توسعه دهندگان بزرگ محروم می شود . شخصا لایسنس های دیگه مثل BSD یا MIT را بیشتر قبول دارم هرچند که خودم یک لایسنس جدید به نام FREEDOM را در همین وبلاگ به کاربران معرفی کرده ام که ایده ی این لایسنس متعلق به خودم می باشد !! . وحیدمی) .
عنوان پست :
مجوز آزادی
آدرس پست :
So, most efforts go directly into the dust bin, and, if an Anti-GPL Project would rise to success, in the coming years, all of the work would have to be re-written again (!!!...).
بنابراین ، اکثریت تلاشها مستقیما به سطل زباله انداخته می شوند ، و ، اگر یک پروژِه ی ضد جی پی ال بتواند به موفقیت برسد ، در سالهای بعد ، تمام کار باید از اول بازنویسی شود (!!!!.... )
( البته در این یک مورد، ایشان اشتباه پیشگویی کرده است زیرا طراح فلت اسمبلر وقتیکه دید قرار است روی سایر پردازنده ها فسم را پورت نماید بجای رو آوردن به لایسنس گنو ، یک موتور جدید به نام فسمجی را طراحی کرد که بتواند قابلیت حمل را به زبان اسمبلی وارد نماید . این موتور شامل ماکرواینستراکشن هایی است که در قالب یک زبان شبه سطح بالا ، امکان برنامه نویسی شبه اسمبلی برای انواع و اقسام پردازنده ها و سیستم عامل ها را فراهم می کند .
بنابراین برای پیشرفت یک پروژه ، لزوما نیازی به لایسنس گنو نیست و سایر لایسنس ها و نیز طراحی یک ساختار و معماری جدید یا یک فناوری جدید می تواند مشکل را حل کند لذا فلت اسمبلر و سایر اسمبلرهای غیرگنویی هنوز هم به حیات خود ادامه می دهند و هرگز به دوباره کاری و بازنویسی روی نیاوردند درحالیکه روسسم که یک اسمبلر گنویی می باشد سالهاست که متوقف شده است !!! . وحیدمی ) .
Well, now, let the better win, but... what a waste!
خب ! اکنون ، اجازه دهید به پیروزی بهتر ، اما .... هرچیزی ضایع می شود !
( یعنی مغزم ترکید تا توانستم این متن را به فارسی ترجمه کنم . بابت ترجمه ی چکشی و مبهم مرا عفو کنید . بهرحال نویسنده ی این مطلب، انگلیسی زبان نبوده و زبان مادری اش فرانسوی بوده و در نتیجه نوشتار ایشان پر از ابهام است و در نتیجه کار مترجم را بسیار سخت کرده است . وحیدمی . )
هم اکنون دچار سردرد بسیار شدید شده ام و لازمست چند روزی استراحت کنم . پست بعدی را پس از چند روز استراحت و رفع سردرد ، منتشر و ترجمه خواهم کرد . انشاا....
امیدوارم این ترجمه ، مفید بوده باشد . وحید محمدی . وبلاگ وحیدمی .
تاریخ ترجمه و اتمام این پست :
چهارشنبه 8 تیر 1401 شمسی ساعت 7 و 50 دقیقه عصر .
~~~~~~~
===========
===========
https://vahidmy.blog.ir/sitemap.xml