@areusch looking at the design of export_library, it seems it is designed to generate a shared object. Thus, the difference in uTVM (w.r.t. TVM) would be that we would want to statically link it with the runtime in the compile time itself. What are your thoughts of re-using the export_library to produce the static archive (.a) for uTVM builds ? (by providing the fcompile function to the export library)
Moreover, my understanding of the tvm.micro.Compiler instance is providing an abstract class to compile library (using library method) and use that (along with external libs) to re-compile and link with the runtime (using binary method). Therefore, I was thinking whether we can re-use export library to create the archive for the libary part ? -- It would just need the fcompile function which could be provided by the user and could be an attribute in the tvm.micro.Compiler class. In this way, the export_library already knows how to deal with import_trees of modules. We are inclined to go for producing c-source module approach for the external module but for a different reason. However, if we can use the export_library (via using micro-friendly fcompile function), it will create this additional source through PackImportsToC which deals with serialization format. Essentially, the additional source (devc.cc) will have binary blobs that serialized via SaveToBinary interface and I believe the runtime module will also know how to reconstruct itself if the runtime module is linked into the runtime. Having said that, the reason we might want to go with c-source module would be that it would be easier for the fcompile function to put the constants in the c-source module to the flash. If not, if we are to re-construct the runtime module via LoadFromBinary interface, it will do so in the stack/heap forcing a mandatory copy from the flash to volatile memory, I suppose. --- [Visit Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/6) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/ec0e0ffffae7189c11f47d8b3805ef370785be88d36173ff4f214f6a8f6ae891).
