使用XC32编译Objective-C代码需要多少努力？

不是那么大吗？Objto-C有很多功能。它们通过对象之间发送的消息系统来组织对象创建、通信等。例如，“O.ObjsMsGEnter”函数调用对象上的方法或属性。系统的一部分是哈希数据库，它将所有字符串转换为称为UID的唯一实体。有一个叫做“SysLeGuuID”的函数，它将字符串转换为这些数字。比如说，当你调用诸如“ObjuttAtgult:”之类的无辜的东西时，目标C首先调用“SoelSelgGuuID”来获取“ObjuttAtdio:”的UID，然后它将这个UID传递给对象，使用“OxObjsMsGeStand”，然后解密对象响应来确定返回的内容。你必须实现所有这些——所有这些目标C辅助函数和所有对象的所有行为。更不用说对象需要堆和OS X特定的垃圾收集机制来支持自动恢复等等。这项工作需要相当长的时间。然后，你需要实现所有的服务，而不是OSX提供的。编译器可能能够将Objtovi-C转换成C—你会调用底层函数而不是Objy-C语句，尽管我从来没有尝试过这样做。



      以下为原文

   


Not so huge?
 
Objective-C has lots of functions. These organize object creation, communication etc. through a system of messages sent between the objects. For example "_obj_msgSend" function invokes a method or property on an object. A part of the system is a hash database which converts all the strings to unique entities called Uids. There's a function called "_sel_getUid" which converts strings to these numbers. Say, when you call something innocent such as "objectAtIndex:", Objective C first call "_sel_getUid" to get the Uid for "objectAtIndex:", then it passes this Uid to the object using "_obj_msgSend" and then decipher the object response to figure out what was returned. You will have to implement all of these - all these Objective C helper function and all the behaviour of all the objects.
 
Not to mention the objects will need a heap and OS X specific garbage collection mechanisms to support autorelease and such. Making this work will take quite a while.
 
And then you will need to implement all the services than OS X provides.
 
The compiler might be able to convert Objective-C to C - you'll get the calls to underlying functions instead of Objective-C statements, although I've never tried to do this.

对象C通过运行消息（不在编译时作为C或C++）将对象绑定在一起，这样就需要所有的运行时，而这不需要COCOA（或您使用的任何）函数，这是您必须实现的。



      以下为原文

    Objective C binds the objects in run-time through the messages (not at compile time as C or C++), so you will need all of the runtime.
 
And this not counting Cocoa (or whatever you use) functions, which you will have to implement.

那么，“运行时”代码和前面提到的一样，“yObjsMggsEnter（）”-类型函数吗？或者，这是一个相同的东西，比如，基础（或可可）框架，它包含对象定义和结构等等？因此，这些材料的足迹在将其装配到微控制器中是很重要的。还有什么？



      以下为原文

    Hmmm.  So is the "runtime" code the same thing that you were speaking of earlier, the "_obj_msg_send()"-type functions?  Or is that the same thing as, say, the Foundation (or Cocoa) framework which houses the object definitions and structures, etc.?  So the footprint of that stuff will be important in fitting it into a micro controller.  What else?

我看到了COCOTRON.ORG项目，其中“COCORTRON是一个开源项目，其目标是实现与苹果公司的COCOA文档描述的跨平台Obji-C API。这包括AppKIT、Foundation、ObjuleC运行库和支持API（如Core图形和CopeFoundation）。



      以下为原文

    I see the Cocotron.org project, of which the "Cocotron is an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation."
 
I suppose the link to the MIPS assembly code is missing from that effort.
 

您总是可以编写自己的运行时：



      以下为原文

    You always can write your own runtime :)

它比运行时更重要。操作系统API和主板BIOS上的低级驱动程序呢？考虑到一个努力填补所有的小块，并为Objul-C程序提供足够的环境。PIC处理有多少外部存储器？是否有足够的MIPS消化所有可以接受的方式，或者是一个“推一个按钮”，午饭后回来看结果？只是一些疯狂的锻炼……最好的



      以下为原文

    Hi
 

 
There is much more to it than just the runtime.
What about the operating system API and the low-level drivers on the motherboard BIOS?
 
Considering that one takes the effort of filling all the bits and pieces and produce an adequate environment for an Objective-C program.
How much external memory can the PIC handle?
Are there enough MIPS to digest all that in acceptable fashion, or is it going to be a “push a button” and get back after lunch to see the result?
 
Just some wild toughts...
 
 
Best regards
Jorge
 

要获得代码“编译”：也许不是那么多。实际上复制它的功能：比听起来像你期望的多。（这是我在线程标题中问的问题的简洁答案。）



      以下为原文

    To get the code to "just compile": Perhaps not all that much.
 
To actually duplicate itsfunctionality: A lot more than it sounds like you expect.
 
(That's my concise answer to the question he asked in the thread's title.)

和/或SnARKY-CopyFutter & Gt；ObjuleC的完整运行时是开源的C代码，位于ApopServCE.Apple .COM/TARBARS/Objc4/。它是嵌入式系统所需的10倍，但也可以让编译器剔除不必要的东西。编译它的方向是StAccOfFuff.com /Quass/9833636/WORD到编译和USE-Obj-RunTimeFROM应用程序源代码。



      以下为原文

   

 
Apple's complete runtime for objective-C is open source plain C code and is located at opensource.apple.com/tarballs/objc4/ .  It's 10 times as much stuff as is needed for an embedded system, but maybe one could let the compiler weed out the unnecessary stuff.
 
Directions to compile it are at stackoverflow.com/questions/29383436/how-to-compile-and-use-objc-runtime-from-apples-source-code .

正如前面提到的，运行时仍然假定所有的操作系统API都存在，它们将不在PIC32裸露的金属上。您的代码究竟做了什么事情？我的猜测是简单地用其他语言（也许是C）来重写功能更容易。苏珊



      以下为原文

    As has been mentioned before, that runtime still assumes that all of the operating system APIs are present which they will not be on the PIC32 bare metal.
What sort of thing does your code do anyway?
My guess would be that it is much easier to simply rework the functionality in some other language (perhaps C).
Susan

好吧，我不太确定，苏珊。你有直接的经验吗？我将尝试编译运行时代码，看看我需要添加什么。哦，还有另一个开源运行时，可能是更可配置的，我想，我的应用程序，在一个嵌入式机器上，既需要在MAC上运行，也需要以裸露的形式（减去显示）运行。拥有相同的通用代码库将是一个很大的优势。我的时间真的很短。这就是为什么我在考虑这个奇怪的想法。



      以下为原文

   
Well, I'm not so sure about that, Susan.  Do you have direct experience with this?  I'll try compiling just the runtime code and see what I have to add to it.  Oh, and there is also another open source runtime that may be more configurable, I think.
 
My application, interestingly enough, needs to run on both a mac and, in bare bones form (minus even a display), on an embedded machine.  To have the same general code base would be a great advantage.  And I'm really short of time.  This is why I'm considering this outlandish idea.

您需要了解如何构建XC32，但GNU文档可以帮助您解决问题。下面是GCC的构建选项；您可能关心“启用语言”选项。这个链接是针对当前的GCC（6.3，我想？）但是大多数选项仍然适用于GCC 4.83.这是XC32基于HTTPS://GC.GNU/Orth/Casulux.HTML的基础。



      以下为原文

    You'll need to figure out how to build XC32, but the GNU docs can help you out.  Here are the build options for GCC; you probably care about the "--enable-languages" option.  This link is for the current GCC (6.3, I think?), but most of the options should still apply to GCC 4.8.3, which is what XC32 is based on.
 
https://gcc.gnu.org/install/configure.html 

谢谢，杰德奎尔。因此，我认为XC32中尚未启用Objc，并且我需要重建GCC 4.83.与XC32 V1.42中完全相同，但启用了“启用语言”选项。在某些未指定的环境中使用XCODE或命令行构建。然后将新重建的GCC放回某处的XC32目录中。对吗？不幸的是，我很不熟悉重建GCC所需要的过程。你知道如何做这方面的基本例子的文件吗？我只是查看了/Microchip／XC32／V1.42/BIN／BIN／GCC，发现了一堆UNIX可执行文件。这就是重建的海湾合作委员会的去向吗？从您的链接到GCC文档“启用语言”选项：“指定只有编译器的特定子集和它们的运行库应该被构建。”我从这里收集到GCC已经有了他们自己的GCC运行库，用于MIPS（ObjcMsgsEnter（）等），它们已经内置到GCC中了，还是我必须G？打别人的开源版本？我还看到垃圾收集可以用-BoeldObjc GC命令构建到编译器中，如果需要一个不同于缺省版本的版本。将用这个新重建的Gcc/XC32组合构建的Obj-C代码被构建到MIPS体系结构中，并以相同的方式运行（来自偶然代码）。开发者观点）作为正常的C代码？换句话说，如果我使用Obj-C所做的一切都是使用最基本的NSObjor类，那么我需要其他任何重要的低级操作系统API吗？（没有图形或其他系统调用）。我知道，在构建应用程序代码时，基础对象库或子集将需要作为一个框架库。如果这样做没有很大的麻烦，它将节省我大量重写我现有的Obj-C代码的工作。谢谢你，保罗



      以下为原文

    Thanks, jdeguire.  
 
So I gather that objc is NOT yet enabled in XC32, and that I would need to rebuild gcc 4.8.3 exactly the same as it is now in XC32 v1.42, but with the "--enable-languages" option enabled.  Build with Xcode or perhaps a command line in some unspecified environment.  And then place the new rebuilt gcc back into the XC32 directory somewhere.  Is that correct?  Unfortunately, I am pretty unfamiliar with processes needed for rebuilding gcc.  Do you know of documentation of any basic examples of how to do this?  I just looked in /microchip/xc32/v1.42/bin/bin/gcc and found a whole bunch of unix executables on that level.  Is that where the rebuilt gcc would go?
 
From your link to the the gcc docs "--enable-languages" option: "Specify that only a particular subset of compilers and their runtime libraries should be built."  Do I gather from this that gcc has their own gcc runtime library for MIPS (objc_msgSend(), etc.) built into gcc already, or do I have to grab someone else open source version?  
 
I also see that garbage collection can be built in to the compiler with the --enable-objc-gc command, if a different version than the default is desired.
 
Will obj-c code built with this new rebuilt gcc/XC32 combination be built into the MIPS architecture and run in the same way (from the casual code developer viewpoint) as normal C-code?  In other words, do I need any other significant low-level operating system APIs if all I'm doing with Obj-C is using the most basic NSObject classes?  (No graphics or other system calls at all).  I understand that the Foundation object library or a subset will be needed as a framework library as I build the application code.
 
If this can be done without a great deal of hassle, it will save me a whole lot of work rewriting my existing Obj-C code.  Thank you,
 
Paul
 
 

没有这样的事。可可下面有一层一层。即使你得到所有的源代码，只要对应的POSIX函数，它将超过2MB，你在PIC32上，将需要兆字节的RAM。这只是一个更有效的限制版本，如果你很努力的话，它可能适合PIC32。你的程序不会有太多的余地。你可能看不出PIC32和你的MAC之间有多大的不同。Mac有8GB的RAM，比PIC32中的512KB有16000倍。MORIMAC有500 GB HDD，比PIC32中的2MB的ROM要多250000倍。相比于PIC32—60＋次数的200兆赫，在PIC32上没有太多的资源浪费在目标C和可可上。



      以下为原文

   


There's no such thing. There are layers upon layers beneath Cocoa. Even if you get the source code for all of them, as long as corresponding Posix functions, it'll be many times over 2Mb which you has on PIC32 and will require megabytes of RAM. And this not counting Objective C runtime.
 
You only bet is to create a more efficient/limit version, which might fit into PIC32 if you try very hard. There will be not much left for your program.
 
You probably do not see how much difference there's between PIC32 and your Mac.
 
Mac has 8Gb of RAM compared to 512kb in PIC32 - 16000 times more
Mac has 500Gb HDD compared to 2Mb of ROM in PIC32 - 250000 times more
Mac has Quad-core multi-threading 3GHz CPU compared to 200MHz in PIC32 - 60+ times faster
 
There's not much resources to waste on Objective C and Cocoa on PIC32.

诺斯盖尔，我可能在这里天真，虽然我不知道MAC和微控制器之间的巨大差异。但是，我试图说明我在看基金会，而不是可可，这是基础之上的大量GUI的东西。从DOCS：“基础框架定义ObjuleC类的基础层。除了提供一组有用的原始对象类之外，它还介绍了几种定义Objy-C语言未覆盖的功能的范例。基础框架的设计考虑了这些目标：提供一组基本的实用工具类。我敢打赌，正如你所说的，在开源版本基金会中，这些基本实用程序类可以被分离出来。除了最基本的NSObjt类型定义之外，我真的需要什么吗？垃圾收集已经内置到运行时了？如果没有太多的努力，那么这是可能的。也许这里没有人真正知道从开源基础类中提取最小窍门可能有多难。



      以下为原文

   
 
NorthGuy, I'm probably naiive here, though I'm not unaware of the huge differences between a mac and a micro controller.  However, I've tried to specify that I'm looking at Foundation, not Cocoa, which is the huge set of GUI stuff on top of Foundation.  From the docs:
 
"The Foundation framework defines a base layer of Objective-C classes. In addition to providing a set of useful primitive object classes, it introduces several paradigms that define functionality not covered by the Objective-C language. The Foundation framework is designed with these goals in mind:

• Provide a small set of basic utility classes. " etc.   
  

I'm betting, as you say, that in the open source version of Foundation that these basic utility classes can be separated out.  Do I really need anything beside the most basic NSObject-type definitions?  Garbage collection, built into the runtime already?  And if it's not too much effort, then this may be possible.  
 
Perhaps no one here really knows how difficult it may be to extract the minimal essentials from the open source foundation classes.

HII不知道苏珊，但我已经从开发操作系统、设备驱动程序、BIOS和提供非常具体的硬件的“C”库。此外，我有一些编写目标特定语言编译器的经验，从语法到可执行文件。你真的认为Objc运行时处理键盘、鼠标、图形卡、WiFi、NIC、声音硬件、HARDISK、USB端口的所有硬件细节。等等（这是一个很长的清单）？回到“打开的问题”。使用XC32编译ObjuleC代码需要花费多少努力？问题本身并不具备。线程演化表明，它不仅是生成代码的问题，还需要支持在桌面环境中生成的应用程序。因此，它不仅编译到PIC32程序集，还需要支持/模拟运行时环境的生态系统。考虑到它是可以做到的，我不相信。这将花费巨大的努力，当然不仅仅是用不同的，但类似的编程语言将你现有的应用程序改造成不同的平台。我还包括两个版本的维护工作，使它们保持同步。所以，最好的办法就是



      以下为原文

    Hi

I don't know about Susan, but I have enought of it, from developing parts of operating systems, device drivers, BIOSes, and providing 'C' libraries for very specific hardware. Also I have some experience in writing compilers for target specific languages, all the way from the grammar to the executable.
 
Do you really think that the objc runtime is handling all the hardware details of the keyboard, mouse, graphics card, wifi, nic, sound hardware, hardisks, USB ports, ..... and so on (its a very long list)?
 

Getting back to the 'opening question'.
How much effort would it take to use XC32 to compile Objective-C code?

The question itself doesn't have it all.
The thread evolution shows that its not only a question of generating code, you also want to support an application born on a desktop environment.
So its not only compile to PIC32 assembly, you will need an ecosystem that supports/mimics the runtime environment.
 
 
Considering it can be done, what I don't believe.
It will take a huge effort, for sure much more than reworking your existing application for a differemnt platform in a different, but similar, programming language.
And I'm including the maintenace effort for both versions, keeping them in synch and so on.
 
 
Best regards
Jorge