The article directories

  • Apple Arm Chip Adapter Development (Apple Silicon)

  • Apple Silicon

  • 1. Porting macOS applications to Apple chips

  • 1.1 Create a migration plan

  • 1.2 Obtaining a generic version of the link Library

  • 1.3 Update the plug-in to the generic binary

  • 1.4 Addressing architecture differences

  • 1.5 Update gPU-Specific code

  • 1.6 Updating drivers, system extensions, and kernel extensions

  • 1.7 Stay away from specific technologies

  • 1.8 Debugging and testing code

  • 1.9 Tuning the performance of your application

  • Build a generic macOS binary

  • Resolve architectural differences in macOS code

  • Port your audio code to the Apple chip

  • Porting the just-in-time compiler to Apple Silicon

  • Port your Metal code to Apple Silicon

  • Tune the performance of your code for the Apple chip

  • About the Rosetta translation environment

  • Run iOS apps on macOS

  • Implement drivers, system extensions, and Kext

  • Install custom kernel extensions

  • Debug custom kernel extensions

Apple Arm Chip Adapter Development (Apple Silicon)

Apple Silicon

Build applications, libraries, frameworks, plug-ins, and other executable code that run natively on Apple Silicon. When you build the executable on top of the Apple framework and technology, the only important step you may need to take is to recompile the code for the ARM64 architecture. If you rely on the details of specific hardware, or assume underlying features, modify your code as needed to support Apple Silicon.



If you want to inApple siliconSometimes you need to adjust the way you use hardware resources to get the best performance. Use advanced technology whenever possible to reduce dependency on hardware. For example, use Grand Central Dispatch instead of creating and managing your own threads. inApple siliconTest your changes to verify that your code is behaving optimally.

1. Porting macOS applications to Apple chips

Create a version of the macOS application that runs on Mac computers based on Apple silicon and Intel.

Porting existing macOS applications to Apple Silicon by creating generic binaries and modifying the code to handle architectural differences. A generic binary file looks no different than a normal application, but its executable file contains two versions of the compiled code. One version runs on Apple chips and the other on Intel-based Macs. At runtime, the system automatically selects the version to run on the current platform.

To build generic binaries, you need Xcode 12 or later, which adds ARM64 to the list of standard build architectures for macOS binaries. When you open your project and do a clean build, Xcode will automatically create a generic binary if your project uses a standard architecture. If you are using a custom makefile or build script, add the ARM64 architecture to your build system.

After you create the generic binary, test it on both architectures and determine if additional changes are needed. The macOS framework protects applications from architectural differences between platforms, but some differences may still require you to change your code. In addition, architectural differences may affect the performance of the application and require further changes.

On Apple Silicon, applications built for the X86_64 architecture run under the Rosetta translation environment. For more information, see About the Rosetta Translation Environment. To learn how to build a generic binary, see Building a generic macOS binary.

1.1 Create a migration plan

Early in the migration process, identify the workflow that you will use to build and test the code. Xcode runs on all Macs, so you can build the code on a Mac based on Apple’s silicon or Intel chips and do initial testing there. However, always test, tune, and validate your code on both computer types to find architecture-specific problems.

In addition to workflow planning, identify potential areas that need to be studied during the migration process. Porting to arm64 depends on how much you depend on specific hardware features. If you rely heavily on Apple frameworks and technology, your migration effort may be small. If you have tuned your code specifically for the X86_64 architecture and hardware capabilities, porting to ARM64 may require additional work.

To begin your investigation, write down any code that does:

  • Interact with third-party libraries that you do not own.

  • Interact with the kernel or hardware.

  • Depends on specific GPU behavior.

  • Contains assembly instructions.

  • Manage threads or optimize the multithreaded behavior of your application.

  • Contains hardware specific assumptions or performance optimizations.

The list above is not exhaustive, but it provides a starting point for your investigation. Differences in hardware and architecture can cause bugs or performance problems in your code. Identifying potential problem areas early will save you time later.

Always have a well-defined test plan and ideally a set of automated test suites that can be run at build time. In addition to testing the correctness of your code, you can also collect performance metrics for your application. Check your app’s memory usage and measure how long it takes to perform specific tasks on Apple Silicon and Intel-based Macs. Use this information to identify additional areas for investigation.

1.2 Obtaining a generic version of the link Library

If your project relies on any third-party libraries, contact the original vendor and ask them to provide you with a generic version of those libraries. All code running in the same process must support the same architecture. Without a common version of all linked libraries, you cannot generate a common version of the binaries. If one or more libraries are not generic, the linker reports an error.

To learn how to create your own generic binaries, see Building generic macOS binaries.

1.3 Update the plug-in to the generic binary

A universal plug-in can run on any Mac. If your application supports the plug-in model, create a generic version of the plug-in you manage. If your company allows external developers to contribute plug-ins, encourage those developers to create generic versions of their plug-ins.

Generic plug-ins are essential if your application loads them directly into process space. Code running in the same process must support the same architecture. If your application tries to load a plug-in with an incompatible architecture, the system reports an error at load time.

Plugins running out of process with XPC services may run in a different architecture than the application itself. To give developers time to update plug-ins, two non-generic XPC services are provided – one running the ARM64 plug-in and one running the X86_64 plug-in. A single XPC service can manage either a native plug-in or a transformation plug-in, but not both. When creating services, provide a unique bundle identifier for each service so that they can run simultaneously.

For information on how to use XPC to communicate with out-of-process plug-ins, see XPC.

1.4 Addressing architecture differences

In addition to the massive changes in processors and graphics hardware, there are subtle architectural differences between Apple’s silicon chips and Intel-based Macs. During migration, audit your code to determine fixes for any potential architectural issues. For example, where the lookup code depends on a particular hardware feature or configuration.

The following list lists several known architectural differences between Apple’s silicon chips and Intel-based Macs. Update the code to depend on anything below:

  • Virtual memory page size

  • Cache line size

  • Variable function

  • Memory that is both writable and executable

  • Just-in-time compiler

  • Real-time thread

  • Explicit thread priority

  • Hardware specific details

  • Assembly language instructions or built-in functions

  • Unit vector instruction

  • Details of the c++ ABI

Both the Apple Silicon and Intel-based Macs use data in little endians, so you don’t need to do the END conversion in your code. However, continue to minimize the need for end-transformations in the custom data formats that you create.

For additional information about schema differences, see Dealing with Schema Differences in macOS Code.

1.5 Update gPU-Specific code

Metal on Apple supports features on Intel-based Macs and iOS devices. If your application uses Metal features found only on Intel-based Macs, consider incorporating ios-specific features into your ARM64 code. Adopting these features can improve the performance of many applications.

If your application uses Metal, OpenGL, or OpenCL, please note the following differences:

  • The GPU and CPU on the Apple chip share memory.

  • OpenGL is not recommended, but is available on apple cores.

  • OpenCL is not recommended, but it is available for gpus. The OpenCL CPU device is not available for ARM64 applications.

For information on how to update the graphics code, see Porting Metal Code to Apple Silicon.

1.6 Updating drivers, system extensions, and kernel extensions

When porting code to macOS 11, be aware of the following requirements for code that interacts with the kernel:

  • Hardware drivers are implemented using DriverKit. MacOS 11 requires that you use a driver suite extension when support is available. Most driver types now support DriverKit, and only a few still need to create kernel extensions.

  • Kernel extensions must support the native architecture. Kernel extensions run in the kernel, and the kernel always runs as a native process. Kernel extensions cannot be run using Rosetta translation.

  • The installation and uninstallation of kernel extensions requires a reboot. When you install kernel extensions, the system does not load the extensions until after a reboot.

For more information about kernel extensions and driver changes, see Implementing Drivers, System Extensions, and Kext.

1.7 Stay away from specific technologies

MacOS includes some technologies that are not currently recommended or actively developed. If your application uses one of the following techniques, migrate to the appropriate replacement as soon as possible:

  • OpenGL- Use Metal instead.

  • OpenCL- Use Metal instead.

  • Addressbook – Use the contacts framework instead.

  • Carbon API — Migrate to AppKit, Foundation, and other modern apis.

  • IOKit Kernel extension – Migrate to the driver suite using the DriverKit framework where appropriate.

Apple Silicon still provides support for these technologies, and you can continue to use them in macOS 11. However, this support may be removed in future versions of macOS, so migrating to newer technologies is recommended.

1.8 Debugging and testing code

Apple Silicon supports all the debugging and testing tools found on Intel-based Macs. Use the Xcode IDE to set and monitor breakpoints, as well as to monitor the behavior of other aspects of the application. Use LLDB on the command line to perform similar tasks outside of the Xcode interface.

For more information on how to debug and test code, see Xcode.

1.9 Tuning the performance of your application

Apple Silicon can run all the performance tools found on Intel-based Macs. Use tools and other performance tools to collect different types of metrics for your application, including memory usage, speed, energy usage, and more. You can also use command line tools such as Leaks, heap, top, fs_Usage, SC_usage, vm_stat, otool, sample, malloc_history, and VMmap to identify potential performance issues.

The architectural differences between ARM64 and X86_64 mean that technologies that work well on one system may not work well on another. Such as:

  • Don’t assume that an independent GPU means better performance. The Apple processor’s integrated GPU is optimized for high-performance graphics tasks. See porting your Metal code to the Apple core.

  • Don’t assume that all processor cores are the same. Processors on Apple Silicon are a mix of performance cores (P-core) and efficiency cores (E-core), which perform tasks with different performance characteristics. Use ** Quality of Service (QoS)** classes to help the system schedule tasks on the right core types.

During porting, measure the performance of your application on Macintosh and Intel-based Macs and investigate any differences. Tasks that take longer to run on a platform may require additional tuning.

For specific tips on tuning generic binaries, see Tuning your Code performance for Apple Silicon.

Build a generic macOS binary

Resolve architectural differences in macOS code

Port your audio code to the Apple chip

Porting the just-in-time compiler to Apple Silicon

Port your Metal code to Apple Silicon

Tune the performance of your code for the Apple chip

About the Rosetta translation environment

Run iOS apps on macOS

Implement drivers, system extensions, and Kext

Install custom kernel extensions

Debug custom kernel extensions

Have want the interview data or other data can go to see my home page and add me, welcome to consult!

The article will continue to be updated, and you can also send me a personal message to get the interview information in time. If you have any comments and suggestions, please leave me a message. Please pay attention to iOS friends! Like words to a like it! Thank you very much! Thank you very much! Thank you very much!

The original link: blog.csdn.net/kyl28288954…