| __nsstring.rs |
|
4111 |
| bool.rs |
|
9539 |
| define.rs |
# Dynamically creating classes and protocols. |
37012 |
| malloc.rs |
A minimal alternative to crates like `malloc_buf`, `mbox` and `malloced`. |
4030 |
| message_receiver.rs |
|
22626 |
| method_encoding_iter.rs |
Utility for parsing an Objective-C method type encoding.
TODO: Move this to `objc2-encode` when more stable. |
6859 |
| method_implementation.rs |
|
3904 |
| mod.rs |
# Direct runtime bindings.
This module contains safe(r) bindings to common parts of the Objective-C
runtime. See the [`ffi`][crate::ffi] module for details on the raw
bindings.
# Example
Using features of the runtime to query information about `NSObject`.
``` |
66965 |
| nsobject.rs |
|
20379 |
| nsproxy.rs |
Defined here instead of in `objc2-foundation` since it's a root object,
and the `extern_class!` macro doesn't support those (yet). |
2091 |
| nszone.rs |
|
3002 |
| protocol_object.rs |
|
15361 |
| retain_release_fast.rs |
Optimized versions of `objc_retain` and `objc_release`.
On macOS 13.0 / iOS 16.0 / tvOS 16.0 / watchOS 9.0, on ARM64, optimized
versions of these two functions that use a different calling convention
than the usual C calling convention, are available.
Specifically, the expected input register is changed. The output register
is unchanged.
As an example, if the object is stored in the `x19` register and we need
to release it, we usually end up emitting an extra `mov` to get the object
into the `x0` register first, as expected by the C calling convention:
```asm
mov x0, x19
bl _objc_release
```
With this optimization though, since the expected register is encoded in
the name of the function instead, we can avoid the move altogether.
```asm
bl _objc_release_x19
```
Safety of our two uses of the `asm!` macro:
1. We use the register class `reg`, with the modifier `x`, which on
Aarch64 is defined as `x[0-30]`, see [this][asm-reg-cls].
The functions are only available in the variants `x[0-15]` and
`x[19-28]` though, see [this][objc4-source], so if the register
allocator ends up using `x16`, `x17`, `x18`, `x29` or `x30`, we will
emit a call to e.g. `objc_retain_x29`, which will fail at link time.
Of thesee five registers, `x18` is a reserved register on Apple, so the
register allocator won't use it. `x29` is the frame pointer, so that
will also never be used (at least not for storing a pointer to an
object).
Left are `x16`, `x17` and `x30`, which we prevent from being selected
by specifying `out("x16") _`, `out("x17") _` and `out("x30") _`, which
tricks the register allocator into believing that it cannot use those
registers. This may be slightly worse than optimal, since it also
clobbers the registers, but then again, so does `clobber_abi("C")`, so
it probably won't matter.
(NOTE: I'm not _entirely_ sure that the register allocator won't select
one of the clobbered registers, but luckily, it is not a safety
requirement either way, it will "just" lead to a link error).
2. We use the `clobber_abi("C")` since we're effectively calling a C
C function.
[asm-reg-cls]: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#register-operands
[objc4-source]: https://github.com/apple-oss-distributions/objc4/blob/objc4-866.9/runtime/objc-abi.h#L442-L498 |
8185 |