Good idea but cannot build about silicon HOT 14 CLOSED

OK, if I edit that, the example apps compile and run. Sweet.

from silicon.

Unfortunately, I am not too sure why Clang complains so much about the 'redefinitions' of types and enums despite the C Silicon headers not having any Cocoa includes. Maybe removing '#include <CoreServices/CoreServices.h>' in include/silicon.h and replacing it with some other header would fix the issue, but not only do I doubt that, but I also cannot even test that out, as I am not using MacOS as my primary OS anymore. This also might be a compiler thing, where Apple's Clang auto-includes these headers, but that's going into pure speculation.

However, as an actual alternative to silicon, I recommend trying out a fork of silicon instead. It's more-or-less the same thing but single-header and 100% C, which should get rid of those errors.

from silicon.

Hello @EimaMei,

Thanks for the comment. The failure to compile is odd, I agree. I had found the fork and tried that too. It compiles but all of the examples crash at startup. And there is no issues page on the fork so reporting is a trifle difficult. I will pursue further and see if the cause can be fixed. @ColleagueRiley: do you have any comments? I'm building on M2 silicon/Sonoma using Clang 15.0.0

Thanks!

from silicon.

I believe I used to have a similar issue as you when compiling newer versions of MacOS using [the original] Silicon. I ended up just used per-compiled binaries instead of compiling it by hand.

In terms of Silicon.h crashing, I'm not sure what the problem is.

from silicon.

Hello @EimaMei,

Thanks for the comment. The failure to compile is odd, I agree. I had found the fork and tried that too. It compiles but all of the examples crash at startup. And there is no issues page on the fork so reporting is a trifle difficult. I will pursue further and see if the cause can be fixed. @ColleagueRiley: do you have any comments? I'm building on M2 silicon/Sonoma using Clang 15.0.0

Thanks!

I’ll definitely attempt to look into it either on the following days or the weekend. As for silicon.h crashing, I’ve read awhile back that the way you declare objc_msgSend in x86-64 MacOS would crash in ARM64 MacOS due to ABI differences (sadly I cannot find that source at the moment). Either way I’ll probably have to setup docker and to debug either issue.

from silicon.

Hello @ColleagueRiley

Your comment re objc_msgSend is absolutely on the money. On Apple ARM64 all you need is that, and not the stret/fpret varieties. See https://stackoverflow.com/questions/24003327/objc-msgsend-macro-on-arm64 and (the slightly madcap) https://felixk15.github.io/posts/c_ocoa/

Sadly all of the examples fail in one way or another. I'll investigate further.

Silicon-h % lldb menu    
(lldb) target create "menu"
Current executable set to '/Users/jevans/src/osx/Silicon-h/menu' (arm64).
(lldb) r
Process 4607 launched: '/Users/jevans/src/osx/Silicon-h/menu' (arm64)
Process 4607 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x40)
    frame #0: 0x000000018d8c9578 libobjc.A.dylib`objc_opt_isKindOfClass + 12
libobjc.A.dylib`objc_opt_isKindOfClass:
->  0x18d8c9578 <+12>: ldr    x8, [x0]
    0x18d8c957c <+16>: and    x16, x8, #0x7ffffffffffff8
    0x18d8c9580 <+20>: mov    x17, x0
    0x18d8c9584 <+24>: movk   x17, #0x6ae1, lsl #48
Target 0: (menu) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x40)
  * frame #0: 0x000000018d8c9578 libobjc.A.dylib`objc_opt_isKindOfClass + 12
    frame #1: 0x0000000191524b98 AppKit`-[NSApplication setMainMenu:] + 96
    frame #2: 0x00000001000053cc menu`NSApplication_setMainMenu + 68
    frame #3: 0x0000000100004d80 menu`main + 468
    frame #4: 0x000000018d9010e0 dyld`start + 2360

from silicon.

and a picture to complement the last post (You can invoke the TUI mode by typing 'gui' at the lldb command line):

from silicon.

I'm not too sure what the problem is, it seems like ARM likes to use objc_msgSend and not the fpret or stret varieties. But Silicon only uses objc_msgSend anyway, so I don't know how it would be causing a crash.

Silicon.h works well on x86 systems, so it's 100% something to do with ARM.
It'll be kind of hard for me to figure out the problem because I don't have an computer with an ARM processor.

I think the problem could be with how I cast objc_msgSend but that's just a guess.

from silicon.

A couple of things worth mentioning, though perhaps not so interesting if you are only interested in a C API. Apple have a very clever C++ wrapper for Metal: https://developer.apple.com/metal/cpp/.

Some of the (many) nice features useful in this context are wrappers for SEL and ownership. So, using their string construction, the code below returns the expected result: i.e. the objc_msgSend invocation returns true, and the receiving buffer will contain "Hello World".

It is essential to cast to the correct form of function pointer prior to calling.

{
        // source string 
        NS::String* s = MTLSTR("Hello World");
        // receiving buffer    
        char buffer[512] = {0};
        //-----------------------------
        const char* sel = "getCString:maxLength:encoding:";
    	SEL methodSelector = sel_registerName( sel);
        // note typedef and cast. *must* match ObjC signature.
        typedef bool (*pfn)(id,SEL,char*,unsigned long long,unsigned long long);
        // set up function pointer
        pfn p = (pfn)objc_msgSend;
        // call it. note use of metal string as argument.
        bool b = p(s,methodSelector,buffer,512,NS::UTF8StringEncoding);
        //-----------------------------
        printf("%s => %s (%s)\n",sel,(b?"true":"false"),buffer);
    }

from silicon.

It looks interesting I guess, but I'd be worried about any extra performance issues that C++ brings. Cocoa already isn't that great of a API in terms of performance issues. I really wish apple would stop being weird with their products.

As for Silicon.h's crash issue, I should have a commit in the next few hours that fixes any potential casting issues. Would you be willing to test it? I'm not 100% sure if @EimaMei has an ARM device or not.

from silicon.

I suspect the c++ overhead is absolutely minimal. This is basically for games!

in terms of testing, yes absolutely. Let me know.

Thanks for listening.

from silicon.

@g40 I believe the C++ overhead has a little bit of extra OOP to it. It seems relatively minimal though, yes.

Also, the update with the fixed casting has been committed if you want to test it.

from silicon.

@ColleagueRiley. Latest fails to compile. AIUI, there is no need for the fpret flavour on Apple ARM64.

Silicon-h % make
make opengl
gcc examples/graphics/opengl.c -I./ -framework Cocoa -framework OpenGL -framework CoreVideo -o opengl
In file included from examples/graphics/opengl.c:3:
./silicon.h:2151:21: error: use of undeclared identifier 'objc_msgSend_fpret'
    return (CGFloat)objc_msgSend_float(window, func);
                    ^
./silicon.h:1187:53: note: expanded from macro 'objc_msgSend_float'
#define objc_msgSend_float                      ((CGFloat (*)(id, SEL))objc_msgSend_fpret)
                                                                       ^
1 error generated.
make[1]: *** [opengl] Error 1
make: *** [example] Error 2

from silicon.

@ColleagueRiley. Latest fails to compile. AIUI, there is no need for the fpret flavour on Apple ARM64.

Silicon-h % make

make opengl

gcc examples/graphics/opengl.c -I./ -framework Cocoa -framework OpenGL -framework CoreVideo -o opengl

In file included from examples/graphics/opengl.c:3:

./silicon.h:2151:21: error: use of undeclared identifier 'objc_msgSend_fpret'

    return (CGFloat)objc_msgSend_float(window, func);

                    ^

./silicon.h:1187:53: note: expanded from macro 'objc_msgSend_float'

#define objc_msgSend_float                      ((CGFloat (*)(id, SEL))objc_msgSend_fpret)

                                                                       ^

1 error generated.

make[1]: *** [opengl] Error 1

make: *** [example] Error 2

This is because I accidentally put objc_msgSend_fpret instead of abi_objc_msgSend_fpret. It's fixed now though.

from silicon.