ಇತ್ತೀಚೆಗೆ ಇಮೇಲ್ ಬಿಡುಗಡೆಯಾಗಿದೆ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಮೇಲಿಂಗ್ ಪಟ್ಟಿಯ ಮೂಲಕ ಮತ್ತು ಈ ಇಮೇಲ್ ಅದರ ಮುಖ್ಯ ಉದ್ದೇಶವಾಗಿದೆ x32 ಉಪ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನುಷ್ಠಾನದಿಂದ ಕೋಡ್ ತೆಗೆದುಹಾಕಿ (x86 IA-32 ನೊಂದಿಗೆ ಗೊಂದಲಕ್ಕೀಡಾಗಬಾರದು).
ಇದು 32-ಬಿಟ್ ಮೆಮೊರಿ ವಿಳಾಸ ಮಾದರಿಯನ್ನು ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ಹೈಬ್ರಿಡ್ x86 ಮತ್ತು x86_64) x86 64-ಬಿಟ್ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ.
X32 ವಾಸ್ತುಶಿಲ್ಪ ಎಂದರೇನು?
X32 ಉಪ-ವಾಸ್ತುಶಿಲ್ಪವು ಹೈಬ್ರಿಡ್ x86_64 ಎಬಿಐ ಎಂದು ನಮೂದಿಸುವುದು ಮುಖ್ಯ, ಇದು 32-ಬಿಟ್ ಮೆಮೊರಿ ವಿಳಾಸ ಮಾದರಿಯನ್ನು 64-ಬಿಟ್ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ (ಪ್ರೊಸೆಸರ್ 64-ಬಿಟ್ ಮೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ 32-ಬಿಟ್ ಪಾಯಿಂಟರ್‌ಗಳು ಮತ್ತು ಅಂಕಗಣಿತದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸುತ್ತದೆ).
ಎಬಿಐ ಎಕ್ಸ್ 32 ಹೆಚ್ಚುವರಿ ರೆಜಿಸ್ಟರ್‌ಗಳು ಮತ್ತು ವೇಗವಾದ ಸೂಚನೆಗಳು, ಪಿಐಸಿ ಎಬಿಐನಂತಹ x86_64 ವಾಸ್ತುಶಿಲ್ಪದ ಸಂಪೂರ್ಣ ಲಾಭ ಪಡೆಯಲು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಎಬಿಐ ಎಕ್ಸ್ 32 32-ಬಿಟ್ ಮೆಮೊರಿ ಪಾಯಿಂಟರ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದು ಮೆಮೊರಿಯನ್ನು ಉಳಿಸುತ್ತದೆ, ಪ್ರೊಸೆಸರ್ ಸಂಗ್ರಹವನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ತುಂಬಲು ಕೊಡುಗೆ ನೀಡುತ್ತದೆ ಮತ್ತು ಕೋಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಒಟ್ಟಾರೆ ವೇಗದ ಮೇಲೆ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಎಬಿಐ ಎಕ್ಸ್ 32 ನ ಮಿತಿಯು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ 4 ಜಿಬಿಗಿಂತ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯನ್ನು ನಿರ್ದೇಶಿಸುವ ಅಸಾಧ್ಯತೆಯಾಗಿದೆ.
ಎಕ್ಸ್ 32 ಬೆಂಬಲವು ಲಿನಕ್ಸ್ ಕರ್ನಲ್ನ 3.4 ಬಿಡುಗಡೆಯ ನಂತರ ಮೇ 2012 ರಲ್ಲಿ ರೂಪುಗೊಂಡಿದೆ.
ಈ ವಾಸ್ತುಶಿಲ್ಪದ ನಿರ್ವಹಣೆಯನ್ನು ಮುಂದುವರಿಸಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂದು ಡೆವಲಪರ್‌ಗಳು ಚರ್ಚಿಸುತ್ತಾರೆ
X32 ತಂತ್ರಜ್ಞಾನವನ್ನು ತೆಗೆದುಹಾಕಲು ಡೆವಲಪರ್ ಪ್ರಸ್ತಾಪಿಸುವ ಪ್ರಕಾರ ಇದನ್ನು ಸಮರ್ಥಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಆಧುನಿಕ ಕೈಗಾರಿಕಾ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಪ್ರಾಯೋಗಿಕ ಅಪ್ಲಿಕೇಶನ್ ಕಂಡುಬಂದಿಲ್ಲ.
ಇದಲ್ಲದೆ, ಮತ್ತುl x32 ಕೋಡ್ ಸಿಸ್ಟಮ್ ಕರೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಕಷ್ಟು ವಿವಾದಾತ್ಮಕ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಸಿಸ್ಟಮ್ ಕರೆ ಅನುಷ್ಠಾನಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅಡ್ಡಿಪಡಿಸುವ ಅಪಾಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಯಾವುದೇ ವಾದಗಳನ್ನು ಸಲ್ಲಿಸದಿದ್ದರೆ x32 ಅನ್ನು ತೆಗೆದುಹಾಕಲು ಒಪ್ಪುತ್ತೇನೆ ಎಂದು ಲಿನಸ್ ಟೊರ್ವಾಲ್ಡ್ಸ್ ಹೇಳಿದರು ಅಥವಾ x32 ಉಪ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅನ್ವಯಿಸಿದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸದಿದ್ದರೆ.
ಲಿನಸ್ x32 ವಾಸ್ತುಶಿಲ್ಪದ ಬಳಕೆಯು ತೀವ್ರ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗೆ ಸೀಮಿತವಾಗಿದೆ ಎಂದು ಸಹ ಗಮನಿಸಲಾಗಿದೆರು, ಈ ಉಪ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಬೆಂಬಲವು ವಿತರಣೆಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಪರಿಸರವನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಹೆಚ್ಚಿನ ಜಗಳಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ.
ಅಂಚೆ:
ಎಲ್ಲರಿಗೂ ನಮಸ್ಕಾರ.
ಲಿನಕ್ಸ್‌ನಿಂದ x32 ಬೆಂಬಲವನ್ನು ತೆಗೆದುಹಾಕಲು ಪ್ಯಾಚ್ ಸಲ್ಲಿಸಲು ನಾನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸುತ್ತಿದ್ದೇನೆ. ಇದರೊಂದಿಗೆ ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಇಲ್ಲಿವೆ:
- ಇದು ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದೆ ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ನನಗೆ ತಿಳಿದ ಮಟ್ಟಿಗೆ, ಇದನ್ನು ಜೆಂಟೂ ಮತ್ತು ಡೆಬಿಯನ್‌ನಲ್ಲಿ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ
- ಕರೆ ಮಾಡುವ ವಿಧಾನವು ತುಂಬಾ ವಿಚಿತ್ರವಾಗಿದೆ. X32 ನಲ್ಲಿನ ಹೆಚ್ಚಿನ ಸಿಸ್ಕಾಲ್‌ಗಳು ತಮ್ಮ * ಸ್ಥಳೀಯ * (ಅಂದರೆ COMPAT_SYSCALL_DEFINE ಅಲ್ಲ) ಮೂಲಕ ಪ್ರವೇಶ ಬಿಂದುವಿನೊಂದಿಗೆ ಪ್ರವೇಶಿಸುತ್ತವೆ, ಮತ್ತು ಇದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, adjtimex () ಸ್ಥಳೀಯ ಇನ್ಪುಟ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಕಂಪ್ಯಾಟ್ ಇನ್ಪುಟ್ ಅಲ್ಲ, ಏಕೆಂದರೆ x32 struct ಟೈಮೆಕ್ಸ್ x86_64 ವಿನ್ಯಾಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಆದರೆ ಬೆರಳೆಣಿಕೆಯಷ್ಟು ಸಿಸ್ಕಾಲ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿವೆ - ಇವು 512 ರಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಸಿಸ್ಕಾಲ್‌ಗಳು.
ಇವು COMPAT_SYSCALL_DEFINE ಪ್ರವೇಶ ಬಿಂದುಗಳ ಮೂಲಕ ಪ್ರವೇಶಿಸುತ್ತವೆ.
32 ವ್ಯಾಪ್ತಿಯಲ್ಲಿ * ಇಲ್ಲದ X512 ಸಿಸ್ಕಾಲ್‌ಗಳು ಕರ್ನಲ್ ಸಿಸ್ಕಾಲ್ ಸಮಾವೇಶದ ಪ್ರತಿಯೊಂದು ಹೋಲಿಕೆಯನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ.
ಸಿಸ್ಕಾಲ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳಲ್ಲಿ, in_compat_syscall () ನಿಜವಾಗಿದೆ, ಆದರೆ COMPAT_SYSCALL_DEFINE ನಮೂದನ್ನು ಆಹ್ವಾನಿಸಲಾಗಿಲ್ಲ ಇದು ಹುಚ್ಚುತನದ ಸಂಗತಿಯಾಗಿದೆ ಮತ್ತು ಜನರು ತಮ್ಮ ಸಿಸ್ಕಾಲ್ ಅನುಷ್ಠಾನಗಳನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಿದಾಗ ನೀವು ವಿಷಯಗಳನ್ನು ಮುರಿಯುವ ಅಪಾಯವನ್ನು ಎದುರಿಸುತ್ತೀರಿ.
ಮತ್ತು ಎಲ್ಲಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ, ಯಾರೂ ಈ ವಿಷಯಗಳನ್ನು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ.
ಒಂದು ಸಂದರ್ಭದಲ್ಲಿ X32 ಅನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ, ಜೆಂಟೂ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ಎಬಿಐ x32 ಗೆ ಬದಲಾಯಿಸುವಾಗ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆ ಸಂಶ್ಲೇಷಿತ ಪರೀಕ್ಷೆಗಳು ತೋರಿಸಿದಷ್ಟು ಉತ್ತಮವಾಗಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸಿದರು ಎಬಿಐ x32 ತಯಾರಕರಿಂದ:
ಹಿಂದಿನ x86 ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಹೋಲಿಸಿದಾಗ ಮಾತ್ರ ಗಮನಾರ್ಹ ಪ್ರಗತಿ ಕಂಡುಬರುತ್ತದೆ, ಆದರೆ ಪ್ರಸ್ತುತ x86-64 ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಹೋಲಿಸಿದಾಗ, ಲಾಭವು ನಗಣ್ಯವಾಗಿದೆ (x32 ನ ಸೃಷ್ಟಿಕರ್ತರ SPEC ಪರೀಕ್ಷೆಗಳು ಕ್ಲಾಸಿಕ್ ಎಬಿಐ x40_86, ಪರೀಕ್ಷೆಗಳಿಗೆ ಹೋಲಿಸಿದರೆ 64% ವೇಗವರ್ಧನೆಯನ್ನು ತೋರಿಸಿದೆ H.264 ಕೊಡೆಕ್ 15-20% ರಷ್ಟು ವೇಗವರ್ಧನೆಯನ್ನು ತೋರಿಸಿದೆ).