گذار مک از اینتل به اپل سیلیکون، هستهٔ macOS، مدل درایورها و راهبردهای عملکرد را بازنویسی کرد تا با معماری یکپارچهٔ SoCهای اپل هماهنگ شود.
زمینهٔ تاریخی و انگیزهها
اپل سالها پیش از اعلام رسمی گذار، طراحی SoCهای مبتنی بر ARM را آغاز کرد؛ از Apple A4 در 2010 تا خانوادهٔ M1 در 2020. تسلط بر طراحی تراشه به اپل امکان کنترل عمودی بیشتری روی همتنیدگی سختافزار و نرمافزار داد و وابستگی به تولیدکنندگان CPU را کاهش داد. مشکلات زمانبندی و کیفیت در نقشهٔ راه شرکا و نیاز به مدیریت دقیقتر مصرف انرژی و عملکرد، از انگیزههای اصلی این تصمیم بودند.
تغییر ISA و پیامدهای فنی برای هستهٔ macOS
انتقال از x86-64 به ARM64 محدود به جایگزینی پردازنده نبود؛ ساختارهای بنیادی هسته تحت تأثیر قرار گرفتند. مدیریت استثناءها، ترجمهٔ آدرسها (MMU)، سیاستهای کش و الگوریتمِ تعویض بافت (context switch) نیاز به بازنگری و بهینهسازی داشتند. همزمان، اپل راهحلهایی برای حفظ سازگاری عرضه کرد، از جمله Rosetta 2 و باینریهای Universal، و ABI را به تدریج برای ARM تطبیق داد.
چالشهای معماری هسته
- ABI و فراخوانهای سیستمی: مهاجرت ABI به ARM نیازمند بازتعریف قراردادهای فراخوان سیستم و نحوهٔ ارسال پارامترها بین فضای کاربر و هسته است.
- مدیریت حافظه: طرح ترجمهٔ آدرس و مدهای دسترسی حافظه در ARM با معماری x86 تفاوت دارد و باید با طراحی خاص SoCهای اپل همسو شود تا کارایی و امنیت حفظ گردد.
- تعامل با شتابدهندهها: واحدهای گرافیکی و شتابدهندههای اختصاصی در SoCها به مدلهای جدیدی برای همگامسازی، coherence و حافظهٔ اشتراکی نیاز دارند.
درایورها و مدل سختافزاری SoC
در طراحیهای مرسوم PC مبتنی بر x86، قطعات از تأمینکنندگان متعدد و مستقل تأمین میشدند؛ اما SoCهای اپل مجموعهای از CPU، GPU، کنترلرها و سلسلهمراتب کش را در یک بستهٔ واحد گرد میآورند. این یکپارچگی، نقش درایورها را از سطح قطعهای به سطح سیستمی ارتقا میدهد: درایورها باید از منظر کل سیستم طراحی شوند تا بتوانند از قابلیتهای سختافزاری بهرهٔ کامل ببرند.
مدل یکپارچهٔ SoC مزایای قابلملاحظهای در بهرهوری انرژی و کاهش تاخیر حافظه فراهم میکند، اما توسعهٔ درایورهای ثالث را پیچیدهتر میسازد؛ مستندات داخلی و رفتار سختافزار ممکن است بسته به طراحی SoC متفاوت باشد و دسترسی محدود به مستندات برخی ویژگیها، توسعه را دشوارتر میکند.
سازگاری نرمافزاری و ابزارهای میانی
برای کاهش اختلال در تجربهٔ کاربری، اپل چند مکانیسم همزمان بهکار برد:
- Rosetta 2: لایهٔ ترجمه که باینریهای x86 را بهصورت داینامیک یا استاتیک اجرا یا بازترجمه میکند تا تجربهٔ کاربری حفظ شود (جزئیات).
- Universal Binaries: بستههایی که هم نسخهٔ x86 و هم ARM را شامل میشوند تا برنامهها روی هر دو معماری اجرا شوند.
- ابزارهای توسعه: بهروزرسانی کامپایلرها، دیباگرها و SDKها برای تولید کد ARM64 و بهرهبرداری از ویژگیهای خاص SoC ضروری بود.
ابزارهای توسعه و بهینهسازی
توسعهدهندگان مجبور به بازآموزی و بهکارگیری الگوهای جدید برنامهنویسی و پروفایلینگ شدند تا از مزایای هسته و سختافزار بهینه بهرهمند شوند. بهعلاوه، سیستمهای تست و دیباگ برای بررسی همزمان رفتار نرمافزار روی چند معماری توسعه یافتند.
نقش جامعهٔ متنباز و پروژههای عملی
پروژههایی مثل Asahi Linux نشان دادند که فراهمسازی پشتیبانی از پلتفرمهای جدید اغلب به مشارکت جامعه و گاه مهندسی معکوس نیاز دارد. توسعهدهندگان متنباز تلاش کردند درایورهای سازگار بنویسند و توزیعهای لینوکس را روی سختافزار اپل اجرا کنند؛ این کوششها هم نقاط قوت طراحی اپل را روشن کرد و هم محدودیتها و موانع را نمایان ساخت.
تغییرات قابلمشاهده و چالشهای باقیمانده
از منظر کاربر، مکهای با اپل سیلیکون بهبود کارایی تکهستهای و مصرف انرژی بهتر را نمایش دادند و قابلیت اجرای همزمان برخی ابزارهای iOS/iPadOS روی مک تقویت شد. از منظر مهندسی، تیمهای سیستمعاملی بخشهایی از هسته را بازنویسی و ابزارهای جدید تست و دیباگ پیادهسازی کردند. با این حال، پشتیبانی بلندمدت از باینریهای قدیمی و برنامهریزی مهاجرت برای سازمانها همچنان یک چالش عملی است.
چشمانداز
گذار به اپل سیلیکون تجربهای عملی از همگرایی سختافزار و نرمافزار فراهم کرد و نشان داد کنترل طراحی SoC میتواند سرعت نوآوری و بهبود مصرف انرژی را افزایش دهد. جهات بعدی شامل بهینهسازی بیشتر هسته برای بارهای کاری متنوع، شفافتر شدن مستندات برای توسعهدهندگان خارجی و افزایش نقش نرمافزار متنباز در گسترش پشتیبانی خواهد بود. این مسیر ابزارها و الگوهای جدیدی برای طراحان سیستمعامل و توسعهدهندگان ارائه میدهد و فرصتهای تازهای برای نوآوری پدید میآورد.
