Just a few comments/observations... On Tue, Sep 3, 2024 at 6:22 PM Ethan C <[email protected]> wrote:
> Hi everyone, > > Our recent discussion about whether we should switch to a newer > compiler has brought up an idea I've been thinking about for a while. > Objective-C was originally implemented as a preprocessor which emitted C > code. This bit is sort of HALF true. Brad Cox has said that it was never a front end. I think this, perhaps, comes from the fact that the NeXT compiler itself is a heaping pile of crap. The FSF originally sued NeXT (yes) to release the code as NeXT had modified gcc in order to create their ObjC compiler. The code was, apparently, unusable. Whether it was written as a front-end, I don't know. > C++ was also originally implemented this way (Cfront), and Qt C++ > is still implemented as a preprocessor which emits C++ code. If we could > make an Objective-C 2.x compiler that emitted C code, we would unlock > many benefits: > > * We could add our own extensions to the Objective-C language rather > easily (think adding syntax support for traits) > I see rust peeking in. ;) This would be outside of scope for an Objective-C compiler as the entire idea was to keep things simple in the first place. > * We could start using Objective-C features which were introduced after > Objective-C 2.0 without hacky stuff, such as blocks, lightweight > generics, etc., and allow GNUstep users on GCC-only platforms to use > these too > Writing our own compiler is a project onto itself. I have written a few compilers in my time, especially during college. One assignment was to write a PASCAL subset called P and another was to write a C subset. Both were very much non-trivial exercises even in the reduced form needed for a 1-semester college course. Handling and maintaining a full blown compiler is a real task and would require a few dedicated individuals. Right now as I see it we have to orthogonal issues: 1) GCC runs on many platforms, but does not support ObjC2.0 the way we need it to or ARC (that's another thing that is HELLA NON TRIVIAL) so it suck in that form. 2) CLANG doesn't include it's own objc library it needs ours (libobjc2) and in spite of libobjc2 being excellent on the architectures it supports it does NOT support as many as GCC. Adding yet a third choice would, to be honest, further complicate things and also it would draw more attention to us when it fails and, I can tell you from experience, tracing compilation issues (that is to say issues with how the compiler composes the assembly or RTL... register transfer language... is NOT a trivial thing). * We could support compiler infrastructures other than GCC or LLVM, > which would mean that it would take less time to get to a working > GNUstep system when bootstrapping from scratch, and would make it easier > for us to do things that require C compiler support beyond what standard > C or GNU C provide > This is true, but as I said above, it is quite a deep thing to get into. :) * Our MSVC support would be much easier > Not sure what you mean here. Are you saying we could get VisualStudio to use the proposed compiler? * We could switch to libobjc2 for everything, which would give us typed > selectors and non-fragile ABI even on GCC-only platforms > Part of the platform support issue cited above is due to libobjc2, not clang. :) > I see a few options to do this: > > * We write our own Objective-C-to-C compiler, perhaps using some code > from autogsdoc and the Objective-S compiler > > * We heavily modify Portable Object Compiler (an Objective-C 1.0 > transpiler to C, with its own runtime library) to deal with Objective-C > 2.0 and libobjc2 > > * We modify clang's `clang -rewrite-objc` to output standard C rather > than MSVC C++ > > Interesting. I didn't know about this feature. > Finally, if we want to support compilers other than GCC, Clang, and > MSVC, I made a list of small C compilers here: > > https://github.com/ethanc8/awesome-small-compilers/blob/master/SmallCCompilers.md. > > These compilers could be useful to make sure that we're not depending on > buggy compiler behavior, and to give us a more hackable toolchain with > which to experiment with. We could also implement C extensions that we > need much easier than implementing them in GCC or LLVM, if it turns out > the abilities of GNU C and MSVC C17 or MSVC C++ aren't enough for us. > > This seems like a lot of effort, but a lot of the work is already done > for us. I'm not sure if it will be worth it, but I think it will be, > since it will make it much easier to evolve the Objective-C language > forward, support other languages (like Objective-S) which run on top of > libobjc2, and more. > > Does anyone have any thoughts or opinions on this? > Just FYI, I am CERTAINLY not saying people shouldn't work on this if they are interested. This seems interesting, but it also seems like a HUGE exercise. If people would like to contribute to a compiler I would suggest looking at GCC and determining how we can extend it's support of ObjC2.0+ or adding support for more architectures in libobjc2. As I understand it the difficulty in adding support for architectures is in the objc_msgSend algorithm and exception handling. Just my $0.02. :) Yours, GC -- Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://www.openhub.net/languages/objective_c https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation
