6 ms·

I wasn't aware that there was something wrong with the old compilers. Reading the page, I'm still not aware of the motivations behind this. What does this comp

by ori_b 10y ago

I wasn't aware that there was something wrong with the old compilers. Reading the page, I'm still not aware of the motivations behind this. What does this compiler do better/different than clang or gcc?

timnic 10y ago
There is some more information available here: https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_a_new_objective_c_.html https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_a_ne...
deleted 10y ago
[deleted]
rweichler 10y ago
Apple's objective C runtime is not portable. There's a lot of assembly code and platform specific code. This is trying to fix that.
- eridius 10y ago
  Doesn't at least objc_msgSend have to be assembly?
  - pjmlp 10y ago
    You can do it in plain C, but it will be quite slow. It isn't only written in Assembly, it is written in clever optimised Assembly fine tuned across several compiler releases, to minimise as much as possible the impact of dynamic dispatch.
    - sdegutis 10y ago
      I don't remember why, but years ago I remember coming to the firm conclusion that it was impossible to write it in anything but assembly.
      - pjmlp 10y ago
        I don't see why the naive approach to a possible implementation cannot be done in C, even if using extensions to ANSI C.
      - ksherlock 10y ago
        Don't tell that to the GCC Objective C runtime. With the NeXT/Apple runtime, [object selector: arguments...] is syntactic sugar for objc_msgSend(object, @selector(selector:), arguments) With the GCC runtime, that's syntactic sugar for: IMP tmp = objc_msg_lookup(object, @selector(selector:)); tmp(object, @selector(selector:), arguments...) No assembly necessary. I believe there are also compiler flags to assume the function won't be replaced behind your back so objc_msg_lookup can be hoisted out of a loop, etc.
        DHowett 10y ago
        objc_msg_lookup is very emphatically not objc_msgSend. Lookup operates differently from the nominally tail-calling msgSend in that it cannot support transparent forwarding (where the receiver is switched to another object before dispatch.) Since objc_msgSend is given control over the final call, the destination can be swapped if necessary. It's not possible[1] to implement objc_msgSend in plain (portable) C, as it needs to pass on an unknowable number of arguments without damaging the ones passed in registers, the stack frame, or the optional hidden return value pointer. Any methods attempting to do so using, say, naked functions and the method's type encoding will be more fragile than a perfect argument forwarding stub written in assembly. [1]: __builtin_apply_args, __builtin_apply and __builtin_return (https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Constructing-Calls.html https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Constructing-Ca...) notwithstanding.
        groovy2shoes 10y ago
        GCC's C is emphatically not "plain" (ANSI/ISO) C, but that does not mean it isn't "portable" C, given that GCC itself targets many platforms, and other compilers (clang, at least) do attempt to support GCC's dialect.
  - chrisseaton 10y ago
    No. Why? What's magic about assembly code that means you couldn't do the same thing in C?
    - jamessu 10y ago
      While in this case I can't think of any specific reasons beyond performance to need to implement objc_msgSend in assembly, there are absolutely instances where assembly is the only option. Example: when performing a context switch in a kernel, assembly is required since C abstracts away architecture-specific details necessary to swap out the register set, swap the page directory pointer, etc.
      - david-given 10y ago
        My ObjC-fu is pretty old --- the last time I looked at it seriously was when poc was still a thing --- but my understanding is: Traditionally objc_msgSend is in assembly because it doesn't know how many and what types the message parameters are. So it can't portably preserve them while it does the computations to find out where to send the message to. This project's alternative obj_msgSend always passes parameters in a structure. That helps, because now you know that all message calls have three parameters; the destination object, the selector, and the parameter block. However... they don't always pass the return value in the message block; instead it coerces any integer types to void* and returns them in the usual way, only using an extra field in the parameter block for those values which aren't coerceable to void. This does make me kinda unhappy. I don't think* it'll be a problem, but... it's definitely pushing the limits of what C allows; round-tripping arbitrary integers through pointers is one of those things that's not technically allowed but all real-world compilers support, so, um. I'd much rather they just pass everything through the parameter block. But yeah, it's a decent enough idea, which simplifies things considerably at not a lot of performance hit. I'm kind of surprised that ObjC doesn't already do that. My main disappointment is that this is a clang variant and not a standalone preprocessor. Since poc died there isn't a working ObjC preprocessor, which means if you want to use ObjC you're limited to gcc or clang. An ObjC->C preprocessor would solve that.
        10y ago
ianai 10y ago
The author says to be able to write objective-C in the future. I can get that. I did like objc. He also lists some good technological goals like speed, portability, and the rest on the page.

by ori_b 10y ago

timnic 10y ago

There is some more information available here: https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_a_new_objective_c_.html https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_a_ne...

deleted 10y ago

[deleted]

rweichler 10y ago

Apple's objective C runtime is not portable. There's a lot of assembly code and platform specific code. This is trying to fix that.

eridius 10y ago
Doesn't at least objc_msgSend have to be assembly?
- pjmlp 10y ago
  You can do it in plain C, but it will be quite slow. It isn't only written in Assembly, it is written in clever optimised Assembly fine tuned across several compiler releases, to minimise as much as possible the impact of dynamic dispatch.
  - sdegutis 10y ago
    I don't remember why, but years ago I remember coming to the firm conclusion that it was impossible to write it in anything but assembly.
    - pjmlp 10y ago
      I don't see why the naive approach to a possible implementation cannot be done in C, even if using extensions to ANSI C.
    - ksherlock 10y ago
      Don't tell that to the GCC Objective C runtime. With the NeXT/Apple runtime, [object selector: arguments...] is syntactic sugar for objc_msgSend(object, @selector(selector:), arguments) With the GCC runtime, that's syntactic sugar for: IMP tmp = objc_msg_lookup(object, @selector(selector:)); tmp(object, @selector(selector:), arguments...) No assembly necessary. I believe there are also compiler flags to assume the function won't be replaced behind your back so objc_msg_lookup can be hoisted out of a loop, etc.
      - DHowett 10y ago
        objc_msg_lookup is very emphatically not objc_msgSend. Lookup operates differently from the nominally tail-calling msgSend in that it cannot support transparent forwarding (where the receiver is switched to another object before dispatch.) Since objc_msgSend is given control over the final call, the destination can be swapped if necessary. It's not possible[1] to implement objc_msgSend in plain (portable) C, as it needs to pass on an unknowable number of arguments without damaging the ones passed in registers, the stack frame, or the optional hidden return value pointer. Any methods attempting to do so using, say, naked functions and the method's type encoding will be more fragile than a perfect argument forwarding stub written in assembly. [1]: __builtin_apply_args, __builtin_apply and __builtin_return (https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Constructing-Calls.html https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Constructing-Ca...) notwithstanding.
        groovy2shoes 10y ago
        GCC's C is emphatically not "plain" (ANSI/ISO) C, but that does not mean it isn't "portable" C, given that GCC itself targets many platforms, and other compilers (clang, at least) do attempt to support GCC's dialect.
- chrisseaton 10y ago
  No. Why? What's magic about assembly code that means you couldn't do the same thing in C?
  - jamessu 10y ago
    While in this case I can't think of any specific reasons beyond performance to need to implement objc_msgSend in assembly, there are absolutely instances where assembly is the only option. Example: when performing a context switch in a kernel, assembly is required since C abstracts away architecture-specific details necessary to swap out the register set, swap the page directory pointer, etc.
    - david-given 10y ago
      My ObjC-fu is pretty old --- the last time I looked at it seriously was when poc was still a thing --- but my understanding is: Traditionally objc_msgSend is in assembly because it doesn't know how many and what types the message parameters are. So it can't portably preserve them while it does the computations to find out where to send the message to. This project's alternative obj_msgSend always passes parameters in a structure. That helps, because now you know that all message calls have three parameters; the destination object, the selector, and the parameter block. However... they don't always pass the return value in the message block; instead it coerces any integer types to void* and returns them in the usual way, only using an extra field in the parameter block for those values which aren't coerceable to void. This does make me kinda unhappy. I don't think* it'll be a problem, but... it's definitely pushing the limits of what C allows; round-tripping arbitrary integers through pointers is one of those things that's not technically allowed but all real-world compilers support, so, um. I'd much rather they just pass everything through the parameter block. But yeah, it's a decent enough idea, which simplifies things considerably at not a lot of performance hit. I'm kind of surprised that ObjC doesn't already do that. My main disappointment is that this is a clang variant and not a standalone preprocessor. Since poc died there isn't a working ObjC preprocessor, which means if you want to use ObjC you're limited to gcc or clang. An ObjC->C preprocessor would solve that.
      - 10y ago

ianai 10y ago

The author says to be able to write objective-C in the future. I can get that. I did like objc. He also lists some good technological goals like speed, portability, and the rest on the page.