તાજેતરમાં એક ઇમેઇલ બહાર પાડવામાં આવ્યો હતો લિનક્સ કર્નલ મેઇલિંગ સૂચિ દ્વારા અને આ ઇમેઇલ તેના મુખ્ય ઉદ્દેશ તરીકે છે x32 સબઅરકીટેક્ચર અમલીકરણમાંથી કોડને દૂર કરો (x86 આઇએ -32 સાથે મૂંઝવણમાં ન આવે).
જે તમને 32-બીટ મેમરી એડ્રેસિંગ મોડેલનો ઉપયોગ કરવાની મંજૂરી આપે છે (વર્ણસંકર x86 અને x86_64) x86 64-બીટ સિસ્ટમ્સ પર.
X32 આર્કીટેક્ચર શું છે?
તે જણાવવું મહત્વપૂર્ણ છે કે x32 પેટા આર્કિટેક્ચર એ એક વર્ણસંકર x86_64 એબીઆઈ છે, જે 32-બીટ મેમરી એડ્રેસિંગ મોડેલને 64-બીટ સિસ્ટમો પર ઉપયોગમાં લેવાની મંજૂરી આપે છે (પ્રોસેસર 64-બીટ મોડમાં કાર્ય કરે છે, પરંતુ 32-બીટ પોઇંટર્સ અને અંકગણિત કામગીરીનો ઉપયોગ કરે છે).
એબીઆઇ એક્સ 32 એપ્લિકેશનને x86_64 આર્કિટેક્ચર, જેમ કે અતિરિક્ત રજિસ્ટર અને ઝડપી સૂચનો, PIC ABI નો સંપૂર્ણ લાભ લેવાની મંજૂરી આપે છે.
તે જ સમયે, એબીઆઈ એક્સ 32 32-બીટ મેમરી પોઇંટર્સને સપોર્ટ કરે છે, જે મેમરીને બચાવે છે, પ્રોસેસર કેશને વધુ કાર્યક્ષમ ભરવામાં ફાળો આપે છે, અને કોડ એક્ઝેક્યુશનની એકંદર ગતિ પર હકારાત્મક અસર કરે છે.
એબીઆઈ એક્સ 32 ની મર્યાદા એ એપ્લિકેશનમાંથી 4 જીબી કરતા વધુ મેમરીને ડાયરેક્ટ કરવાની અશક્યતા છે.
X32 સપોર્ટ, મે 3.4 માં રચાયેલી, તેની 2012 પ્રકાશન પછીથી, લિનક્સ કર્નલનો ભાગ છે.
વિકાસકર્તાઓ ચર્ચા કરશે કે આ આર્કિટેક્ચરની જાળવણી સાથે ચાલુ રાખવું કે નહીં
ડેવલપર અનુસાર x32 ટેકનોલોજીને દૂર કરવાની દરખાસ્ત તે ઉચિત નથી અને આધુનિક .દ્યોગિક લેઆઉટમાં વ્યવહારિક એપ્લિકેશન મળી નથી.
ઉપરાંત, અનેl x32 કોડ સિસ્ટમ ક callsલ્સ સાથે કામ કરવાની તદ્દન વિવાદિત પદ્ધતિનો ઉપયોગ કરે છે, જે સિસ્ટમ ક callલ અમલીકરણોની પ્રક્રિયા કર્યા પછી સામાન્ય કામગીરીમાં વિક્ષેપિત કરવાનું જોખમ બનાવે છે.
લિનસ ટોરવાલ્ડ્સે કહ્યું કે જો કોઈ દલીલો રજૂ નહીં કરવામાં આવે તો તેઓ x32 ને દૂર કરવા માટે સંમત થશે અથવા જો સિસ્ટમો કે જેમાં x32 સબઆર્કિટેક્ચર લાગુ કરવામાં આવી છે તે પ્રસ્તુત નથી.
લીનસ તેમણે એમ પણ નોંધ્યું છે કે એક્સ 32 આર્કિટેક્ચરનો ઉપયોગ દેખીતી રીતે આત્યંતિક પ્રભાવ પરીક્ષણ સુધી મર્યાદિત હતોs, કારણ કે આ સબઅરકીટેક્ચરને ટેકો વિતરણો અને વિકાસના વાતાવરણને જાળવવામાં મોટી મુશ્કેલી સાથે સંકળાયેલ છે.
મેઇલ:
બધા ને નમસ્કાર.
હું લિનક્સથી x32 સપોર્ટને દૂર કરવા માટે પેચ સબમિટ કરવા ગંભીરતાથી વિચારી રહ્યો છું. અહીં આ સાથે કેટલાક મુદ્દાઓ છે:
- તે સંપૂર્ણપણે સ્પષ્ટ નથી કે તેના વપરાશકર્તાઓ છે. જ્યાં સુધી હું જાણું છું, તે જેન્ટૂ અને ડેબિયન પર સપોર્ટેડ છે
- ક callingલિંગ સિસ્ટમ જે રીતે કાર્ય કરે છે તે ખૂબ જ વિચિત્ર છે. X32 પરના મોટાભાગના સિસ્કોલ્સ પ્રવેશ બિંદુ સાથે તેમના * મૂળ * (એટલે કે COMPAT_SYSCALL_DEFINE નથી) દ્વારા દાખલ થાય છે, અને આ હેતુસર છે.
ઉદાહરણ તરીકે, એડજાઇટxક્સ () મૂળ ઇનપુટનો ઉપયોગ કરે છે, કatમ્પેટ ઇનપુટ નહીં, કારણ કે x32 સ્ટ્રક્ટ ટાઇમક્સ, x86_64 લેઆઉટ સાથે મેળ ખાય છે. પરંતુ મુઠ્ઠીભર સિસ્કોલ્સમાં અલગ એન્ટ્રી પોઇન્ટ છે - આ તે સિસ્કોલ્સ છે જે 512 થી શરૂ થાય છે.
આ COMPAT_SYSCALL_DEFINE પ્રવેશ બિંદુઓ દ્વારા દાખલ થાય છે.
32 રેન્જમાં * ન * હોય તેવા X512 સિસ્કોલ્સ કર્નલ સિસ્કોલ સંમેલનના દરેક સિમ્બ્લેન્સનું ઉલ્લંઘન કરે છે.
સિસ્કલ હેન્ડલર્સમાં, in_compat_syscall () સાચી વળતર આપે છે, પરંતુ COMPAT_SYSCALL_DEFINE પ્રવેશની માંગ કરવામાં આવતી નથી આ પાગલ છે અને જ્યારે લોકો તેમના સિસ્કોલ અમલીકરણોને રિએક્ટર કરે છે ત્યારે તમે વસ્તુઓ તોડવાનું જોખમ ચલાવો છો.
અને સૌથી ઉપર, કોઈ પણ આ વસ્તુઓનો પ્રયાસ કરતું નથી.
એક પ્રસંગે X32 નું પરીક્ષણ કરતી વખતે, જેન્ટૂ ડેવલપર્સમાંના એકએ નિષ્કર્ષ કા that્યો કે એબીઆઈ x32 પર સ્વિચ કરતી વખતે કામગીરીમાં સુધારો કૃત્રિમ પરીક્ષણો બતાવે તેટલો મહાન નથી એબીઆઈ x32 ના ઉત્પાદકો તરફથી:
અગાઉના x86 આર્કિટેક્ચરની તુલનામાં નોંધપાત્ર પ્રગતિ ત્યારે જ જોવા મળે છે, પરંતુ જ્યારે હાલના x86-64 આર્કિટેક્ચરની તુલના કરવામાં આવે ત્યારે લાભ નહિવત્ છે (ક્લાસિક એબીઆઇ x32_40 ની તુલનામાં, x86 ના નિર્માતાઓ દ્વારા એસપીઈસી પરીક્ષણો 64% જેટલો એક્સિલરેશન બતાવ્યું H.264 કોડેક સાથે 15-20% ની પ્રવેગકતા બતાવી).