તે બધા દ્વારા જાણીતું છે એસેમ્બલર ભાષા સૌથી ઝડપી છે કેટલાક મુદ્દાઓ માટે અને આ કારણોસર તે વિવિધ operatingપરેટિંગ સિસ્ટમ્સના કર્નલમાં સૌથી વધુ ઉપયોગમાં લેવાય છે અને તે જ વાસ્તવિક સમયના પ્રોજેક્ટ્સમાં થાય છે જ્યાં અદ્યતન ઇલેક્ટ્રોનિક્સનો ઉપયોગ થાય છે. સમસ્યા પછી આવે છે, જ્યારે તે કોડ જાળવવાની જરૂર હોય છે અને તે નથી, અને તેથી લિનક્સ કર્નલના કિસ્સામાં, વિકાસકર્તાઓએ તે એસેમ્બલર કોડને સીમાં અનુવાદિત કરવાનું પસંદ કર્યું છે.
સી એ સૌથી પ્રતિનિધિ લિનક્સ પ્રોગ્રામિંગ ભાષા છે (ખરેખર, બધા * નિક્સ પ્લેટફોર્મ) ના, તે દ્વારા વિકસાવવામાં આવી હતી ડેનિસ રિચી અને કેન થોમ્પસન 1972 માં, તે યુનિક્સ પીડીપી -11 સિસ્ટમ પર બનાવવામાં આવ્યો હતો અને તે યુનિક્સ સંસ્કરણ 2 નો ભાગ હતો. તેની ઉચ્ચ કામગીરી અને સુવાહ્યતાને જોતા, તે operatingપરેટિંગ સિસ્ટમ્સના અમલમાં વધુ અને વધુ ઉપયોગમાં લેવાનું શરૂ કર્યું અને તેથી લીનસ ટોરવાલ્ડ્સ 1990 માં પાછા જ્યારે તે મિનિક્સનો મફત અને ખુલ્લો વિકલ્પ શોધી રહ્યો હતો ત્યારે તેણે તેનો ઉપયોગ તેના પ્રોજેક્ટ માટે કર્યો હતો.
અલબત્ત, ઘણી બધી શક્તિ હોવા છતાં, એસેમ્બલરને સી કરતા કેટલાક ફાયદા છે જેમ કે આપણે શરૂઆતમાં ઉલ્લેખ કર્યો છે, તેથી આ નિર્ણયને આશ્ચર્ય થયું છે પરંતુ તે મુજબ ટિપ્પણીઓ એન્ડી લ્યુટોમિર્સ્કી કર્નલ મેઇલિંગ સૂચિ પર તમારું કાર્ય ચાલુ છે અને લિનક્સ કર્નલ 4.1 આ એસેમ્બલર સ્રોત કોડને સીમાં ફરીથી લખવા માટેનો પ્રથમ પ્રયત્ન કરશે. ખાસ કરીને, યુઝર મોડથી સંબંધિત તમામ બાબતો, જેમાં હાલમાં આ બંને પ્રોગ્રામિંગ ભાષાઓના કોડના મિશ્રણનો સમાવેશ થાય છે પરંતુ જેની ઓછી જાળવણી આપવામાં આવે છે, ત્યારે અપડેટ કરતી વખતે વધુને વધુ જટિલ બને છે.
તે છે એસેમ્બલરમાં કોડ તે લાંબા સમયથી અપડેટ કરવામાં આવ્યું નથી અને તેનો અર્થ એ કે નવા વિકાસકર્તાઓ તેના ઓપરેશન વિશે સંપૂર્ણપણે સ્પષ્ટ નથી, અને જે ખરાબ છે, તેને અપડેટ કરવું સરળ રહેશે નહીં. આમ, કેટલાક અંશત change પરિવર્તનનો પ્રયાસ કરવાને બદલે તેઓએ તે તમામ એસેમ્બલર દિનચર્યાઓ સીમાં બદલવાનું શરૂ કરવાનું પસંદ કર્યું છે, અને વ્યક્તિગત રીતે મને લાગે છે કે જોકે અમલની કેટલીક ગતિ ખોવાઈ શકે છે (જો કોડ સી કાર્યક્ષમ હોય તો તે ન્યૂનતમ હોઈ શકે) નવો અને સ્પષ્ટ કોડ હંમેશાં જૂનો થવા કરતાં અને અપડેટ કરવાની લગભગ શૂન્ય સંભાવનાઓ સાથે વધુ સારું છે કારણ કે તે કેવી રીતે અમલમાં આવ્યું તે સારી રીતે સમજાતું નથી.
પ્રથમ સ્થાને તે સ્પેનિશમાં, ENSAMBLADOR છે.
બીજું, બધી ભાષા કમ્પાઇલ કરેલ (અથવા અર્થઘટન) હોવી આવશ્યક છે, તેથી પરિણામની દેવતા કમ્પાઈલર (અથવા દુભાષિયા) પર આધારિત છે
જેમ કે સી કમ્પાઇલરમાં ઘણો સુધારો થયો છે અને એસેમ્બલર ખૂબ જ ઓછો છે (કારણ કે તે પહેલેથી જ ખૂબ જ સારો હતો), આજકાલ એસેમ્બલરમાં લખેલા સમાનની તુલનામાં સીમાં લખાયેલ કમ્પાઈલ પ્રોગ્રામનો તફાવત નજીવા અથવા અસ્તિત્વમાં છે (તે પહેલાં) ન હતી).
સંકલિત (સી અને અન્ય) અને અર્થઘટન (જાવા અને અન્ય) પ્રોગ્રામ વચ્ચેનો તફાવત પણ મોટા પ્રમાણમાં ઘટાડવામાં આવ્યો છે.
તેથી એસેમ્બલર કરતા સી જાળવવાનું ખૂબ સરળ હોવાને કારણે, ખર્ચ લાભ વિશ્લેષણ, નબળાઇઓ, ધમકીઓ, શક્તિઓ અને તકો અથવા કાર્ય કરે છે તેવું કાર્ય કરતી વખતે, કર્નલમાં આ ફેરફારો કરવાનું ખૂબ જ સાચો નિર્ણય છે.
નિર્ણય લેવા માટે.
મિગ્યુઅલ મેયોલ તુરને: સૌ પ્રથમ, દરેક પ્રોગ્રામર કે જે એક હોવાનો દાવો કરે છે તે ASSEMBLER બોલે છે અને અંગ્રેજી સમજે છે. અન્ય વિઝ્યુઅલ બેઝિકનો ઉપયોગ કરે છે અને પોતાને પ્રોગ્રામરો કહે છે. કેટલુ શરમજનક. અને બીજું એસેમ્બલર કમ્પાઇલ કરતું નથી. પ્રોગ્રામ્સ જે તેની સાથે વ્યવહાર કરે છે તે સ્મૃતિશાસ્ત્રને સીધા બાઇટ્સમાં રૂપાંતરિત કરે છે. એસેમ્બલરમાં પ્રોગ્રામિંગ એ જ ભાષામાં મશીન સાથે વાત કરી રહ્યું છે, પરંતુ તેને થોડું સરળ બનાવવા માટે, સ્નેહવિજ્ directlyાનનો ઉપયોગ સીધા અનુરૂપ બાઇટ્સ લખવાને બદલે કરવામાં આવે છે. બાઇટ્સના સેટ અને એસેમ્બલરની સૂચના વચ્ચે એકથી એક પત્રવ્યવહાર છે. પરંતુ આ, અલબત્ત, ફક્ત એક વાસ્તવિક પ્રોગ્રામર જાણે છે, જેઓ ASSEMBLER કહે છે. પરિણામે, એસેમ્બલરથી cપકોડ્સમાં "કન્વર્ટર" માં કોઈ સુધારો થયો નથી કારણ કે પ્રોગ્રામર તે સુધારણા કરવા માટેનો હવાલો લે છે. સી કમ્પાઈલર (અને અન્ય ભાષાઓ) સૂચનોને એસેમ્બલર (અથવા મશીન કોડ) ની પૂર્વ-સ્થાપિત મેક્રો રજૂઆતોમાં ભાષાંતર કરે છે અને તે રૂપાંતર કેવી રીતે થાય છે તેના દ્વારા સુધારાઓ આપવામાં આવે છે.
સી નો ઉપયોગ કેમ કરવો? કારણ કે જે કંઈક વધુ વાંચવા યોગ્ય છે તેની સમીક્ષા અને જાળવણી કરવી વધુ સરળ છે. મોટાભાગના લોકો એસેમ્બલર ઓપ્કોડ્સ અથવા નેમોનિક્સને સીધા સમજી શકતા નથી. તેટલું સરળ.
હું જાવા વિશે વાત કરવાની તસ્દી લેશે નહીં, જે લાંબા સમય પહેલા ધોરણ તરીકે લાદવામાં આવ્યો હોવા છતાં હવે તે કોડ દ્વારા સમજી શકતા લોકો દ્વારા નફરત કરવામાં આવે છે.
પરંતુ મારા પર વિશ્વાસ ન કરો, ગૂગલને પૂછો કે મેં અહીં જે કહ્યું તે ખોટું છે.
સાદર
હેલો ચિગાયર, મારી આંખો મારા ચહેરા પરથી એમ વિચારીને પડી છે કે તમે એંગ્લો-સેક્સન મૂળની શરતોનો ઉપયોગ કર્યા વિના સ્પેનિશમાં લખવા માટે સમર્થ નથી: એવું કહેવામાં આવે છે «એસેમ્બલર».
અલબત્ત, એક વાત પર હું તમારી સાથે સંમત છું, જાવા વિશે વાત ન કરવી તે વધુ સારું છે કારણ કે બકવાસ કહેવા માટે તેને છોડી દેવાનું વધુ સારું છે. મારો એક મિત્ર હતો જે તમારા જેવો હતો પરંતુ સુથાર (નિષ્ણાત પ્રોગ્રામર નહીં) અને તેણે કહ્યું હતું કે શ્રેષ્ઠ વસ્તુ હેન્ડસો અને અન્ય ટૂલ્સ હતી, તેનો ઉલ્લેખ ન કરવો, તેણે તેની સાથે સ્ક્રૂ પણ કડક કર્યા. શું અનુસરવાનું છે!
અંગ્રેજી ભાષા હંમેશાં તમામ ગણતરીના શબ્દોના મૂળમાં હોય છે. જો આપણે સ્પેનિશ ભાષીઓને ન જોઈએ તો પણ તે આ રીતે છે. આમાં ઉમેરો કે એવી શરતો છે કે જેનો અર્થ "બીટ", "બાઇટ", "યુનિક્સ", "લિનોક્સ", "ડોસ" અને ઘણા અન્ય તરીકે અનુવાદિત કરી શકાતો નથી. અને કેટલાક એવા છે કે અનુવાદ કરવામાં આવે છે પરંતુ "સીએમઓએસ", "સીએસએસ", "રેમ" જેવું કોઈ કેસ નથી કારણ કે ત્યાં કેટલાક પ્રારંભિક છે જેનો ટેક્નોલ nothingજી સાથે કોઈ લેવા-દેવા નથી અને તેને ટોચ પર મૂકવા માટે તે ગૂગલમાં પણ અસ્તિત્વમાં નથી. . જ્યારે ઉત્પન્ન થયેલ સંદેશ વાંચવાલાયક ન હોય ત્યારે ભાષાંતર કરવામાં કોઈ અર્થ નથી. નિષ્કર્ષ: તકનીકી અથવા ગણતરીના પ્રશ્નો માટે અંગ્રેજીમાં તકનીકી શરતોનો ઉપયોગ કરવો તે વધુ સારું છે. સમાન કારણોસર: હું લખવાનું પસંદ કરું છું કે હું theપરેટિંગ સિસ્ટમ "વિંડોઝ" નો ઉપયોગ કરવા માટે "વિંડોઝ" નો ઉપયોગ કરું છું. અને હું સીએસએસ વિશે વાત કરવાનું પસંદ કરું છું અને હું ટાઇપ = text ટેક્સ્ટ / સીએસએસનો ઉપયોગ કરવા માટે એમ કહીશ કે હું dia કર્ણ ટેક્સ્ટ સ્ટાઇલ શીટ્સની સમાન ટાઇપવાળી સ્ટાઇલ શીટ શીટનો ઉપયોગ કરું છું ». આરોગ્ય.
એસેમ્બલી ભાષામાં લખાયેલા પ્રોગ્રામ હંમેશા સંકલિત કરવામાં આવે છે, ક્યારેય અર્થઘટન કરવામાં આવતું નથી. જો કે, સ્પેનિશને બદલે સ્પેનિશનો ઉપયોગ કરવામાં કંઇ ખોટું નથી. યોગ્ય નામોનું ક્યારેય ભાષાંતર થતું નથી, પરંતુ તકનીકી શબ્દો ત્યારે હોય છે જ્યારે તે લોકપ્રિય ટૂંકાક્ષરો ન હોય. તો પણ, દરેક જ્યારે પણ અમે તે સમજી શકીએ ત્યારે તેઓ ગમે તે રીતે બોલી શકે છે.