is converting Lua to spir-v possible? [closed] - c++

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I want to write shader code in Lua but it needs to be covered to spir-v. I have not come across a non-glsl compiler for it yet. Is this possible to do?


It certainly is possible (to make a converter from Lua to SPIR-V), but it is a lot of work (certainly several years, if you want the generated SPIR-V code to be efficient). You'll need to write a Lua to SPIR-V compiler.
If you want to go on that route, read several books about compilation, starting with the Dragon Book. Of course, optimization (in your Lua -> SPIR-V compiler) is really important
You have tagged your question as C++. If you want something related to C++ about SPIR-V consider using OpenACC
My recommendation is to stay reasonable: if you want to code for a GPGPU, use a dedicated low-level GPGPU language like OpenCL (or CUDA). You are likely to need to write only short routines (compute kernels) in that (OpenCL or CUDA) language (and more glue code, e.g. to be able to use them from a Lua program, or even a C++ or a C one).


Lua, as a high-level scripting language, has a number of features that SPIR-V, as a low-level shading language, either 1) cannot handle at all, 2) can only handle inefficiently, or 3) cannot handle transparently (ie: the code invoking the shader operation needs to do different stuff).
For example, Lua makes functions first-class objects with lexical scoping. That might be possible in SPIR-V, but it would require memory allocation. And SPIR-V can't do that; it can only work with the memory objects that the external system provides. So this means that the code invoking the shader operation needs to provide storage of some sort to the shader process. How much would depend on what the script does.
Also, SPIR-V has no concept of strings, yet pretty much everything in Lua relies on that. So you'll have to manufacture strings out of whole cloth. And since it cannot allocate memory, the external system would again be required to provide storage for strings.
Lua tables would also be incredibly expensive to implement. Not only do they require dynamic allocation, they also require lots of memory access indirection. Accessing a table with a runtime string value would hurt shader performance. And since Vulkan-flavored SPIR-V require logical addressing, implementing tables will require not having actual pointers. So you'll have to use some sort of array with an index.
Oh, and Lua has none of the data structures or syntax that SPIR-V and shaders work with. SPIR-V needs to communicate with the outside world through a very well defined interface, consisting of typed and decorated variable declarations. Lua has no way of explicitly defining the type of variables, let along decorating them, so you'll have to invent such grammar.
Lua (pre-5.3) also lacks a formal notion of the distinction between a float and an integer. This decision is very important for SPIR-V, as it helps define the interface between a shader stage and the outside world.
Oh, and SPIR-V outright forbids recursion. So even if you managed to make all of the above work, there's no way to guarantee that all Lua shaders could work as a SPIR-V shader.
Is it possible? Probably. Is it at all reasonable? No.

Related

c++ Writing a cosole application from which you can call functions defined in it self [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Hi I'm new to c++ and I want to write a program witch allows me to test different Functions witch are defined in it when it is compiled and running.
I could do a simple switch that receives the case from a cin but then I would have to maintain that for every function i write, plus I'm not sure how to pass on the arguments through that (like I said I'm new)
I come from haskell in wich you can just call whatever funktion you like with custome parameters...(makes testing edge cases and single "Parts" really easy)
How would I do that in c++?
Thx

A possible approach might be to embed some interpreter (like Lua, Guile, etc...) in your C++ application. Then your advanced user would code some script in that language and can call whatever routine you have embedded into (i.e. interfaced or glued with) that interpreter.
(alternatively, write your own interpreter, but that is a lot more work)
Another approach might be to use dynamic loading facilities, but these are operating system specific. On Linux (and POSIX) you would use dlopen(3) and dlsym(3). Be aware of name mangling, so use extern "C" for those C++ functions you want to load at runtime with dlsym (see C++ dlopen mini howto).
A variant could be to generate (with your C++ code) dynamically some C++ source in a temporary file (perhaps from some user input; you want some intermediate AST), fork a compilation of that code into a temporary plugin, and dynamically load that with dlopen, then run it (using raw function pointers obtained with dlsym)
But (in contrast to Haskell or Scheme or Ocaml) there is no REPL in C++, so you need to make one (using the tricks I considered above) if you want some, and that is a difficult task for a C++ newbie. C++ is practically a programming language which should be compiled (practically with a compiler such as GCC or Clang started by some build automation tool like GNU make or ninja). And C++ is a very complex language, difficult to learn and to compile, so all its compilers are rather slow.
BTW, be sure to learn at least C++11.
Perhaps you want some unit testing. There are tools and libraries to help on that (see this answer, and also that list)
I could do a simple switch that recieves the case from a cin
You should consider more fancy stuff. For example, you could at least have some std::map with std::string-s keys and values of some common std::function type then use lambda expressions to fill it.
You could read the latest Dragon Book; it is helpful to learn parsing, interpreting and compiling techniques from it (and they are more relevant to your wish than what you might imagine).
Read also SICP (freely downloadable introduction to programming, using Scheme); it is not about C++ but will help you to relate Haskell with C++ and will improve your thinking about programming.

The correct Answer for myself would be:
I can't do it because the names of the functions dont even exsist anymore. After compiling only their Logic with all nessesary information remains.
--> so you can't call functions by their names in compiled Code unless you want to write your own User Interface / keyword interpreter
thx

Is C++ suited for tiny embedded targets? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
We are currently redesigning our embedded software and are going from 8 bit to 32 bit Cortex-M microcontrollers. Memory is pretty limited (128 kByte Flash and 32 kByte RAM).
In another thread an embedded software library (www.redblocks.de) was recommended. It seems to cover my needs very well, but requires the use of C++.
Does anybody have experience with C++ on embedded platforms like ours? I am wondering what kind of overhead I am dealing with, compared to C.

Depending on the C++ features you are using, there is little to no overhead compared to C.
Here are some features compared:
Using classes without virtual methods results in the same binary code
as C functions working on a data structure that is passed along as a
pointer
When classes with virtual methods are used, a vptr is added to the object’s data section and a vtable introduced in the text memory segment. Similar functionality can be implemented in C with function pointers (that occupy memory as well). As soon as you have more than one virtual method in a class, you typically end up with more efficient binary code when using C++ instead of manually introducing multiple function pointers per object with C.
The efficiency of exception handling differs from compiler to compiler.
RTTI adds overhead and should not be used on tiny embedded targets.
Non-deterministic dynamic memory usage (malloc / free in C and new / delete in C++) should be avoided with both programming languages on platforms without virtual memory management.
Templates have much in common with C preprocessor macros as they are evaluated during compile time and are a kind of compile time source code generation. Thus, they do not add any runtime overhead. However, using them non-deliberately will result in bloated code. If used in the right places, they can even help reducing runtime overhead.
I think the most challenging issue is the developers’ knowledge. C++, especially when using templates a lot, is a much more sophisticated language than C. So you need a bunch of pretty good developers.
However, if you want to go for a clean and reusable object oriented design, C++ is certainly the better choice than C.

I am not an embedded developer myself but I have several colleagues using c++ on the kind of microcontrollers you are targeting.
The language by itself does not add a lot of overhead but the use of the standard library (containers, algorithms...) is not recommended if you are limited in Flash/RAM.
If the performances are an issue you might also want to avoid RTTI and exception.
More information on this paper or on this page.
The book Effective C++ in an Embedded Environment form Scott Meyers is also a very good source of information.

C vs C++ - advantages with c-language [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
C++, as the name suggests, is a superset of C. As a matter of fact, C++ can run most of C code while C cannot run C++ code.
There are several advantages with c++ compared with c - for instance
data can not be hidden in c language
c is more low level (which mean harder to understand and code - and that means more bugs)
c does not allow function overloading
c does not support exception handling
you can use functions inside structures in C++ but not in C
This list could certainly be much longer - but here comes my question: Is there ANY advantage with c-langauge compared with c++? Is there anything whatsoever that is better with c than with c++? Does c have anything that c++ lacks?
I do not know about this at all - but could c possibly be slighty faster than c++ due to fewer instruction-sets? A low-level language would possibly require fewer instructions by the processor.

In simple, C and C++ are two different languages.
C++, as the name suggests, is a superset of C
No. This is not true. C++ is not a superset of C..
Is there ANY advantage with c-language compared with c++? Is there anything whatsoever that is better with c than with c++?
Static initialize is safe in C but not in C++, because in C++ static initialization can cause code to run, which depends on other variables having been statically initialized. It can also cause cleanup code to run at shutdown which you can't control sequence of (destructors).
C gives you better control over what happens when your code is executed. When reading seek out it is fairly straightforward to decipher one code is getting executed and when memory is just restart or primitive operations are performed.
C supports variable sized arrays on the stack. Which is much faster to allocate than on the heap. (C99 feature)
No name mangling. If you intend to read generated assembly code, this makes that much easier. It can be useful when trying to optimize code.
De facto standard application binary interface (ABI). Code produced by different compilers can easily be combined.
Much easier to interface with other languages. A lot of languages will let you call C functions directly. Binding to a C++ library is usually a much more elaborate job.
Compiling C programs is faster than compiling C++ programs, because parsing C is much easier than parsing C++.
Varargs cannot safely be used in C++. They're not entirely safe in in C either. However they're much more so in the C++, to the point that they are prohibited in the C++ coding standards (Sutter, Alexandrescu).
C requires less runtime support. Makes it more suitable for low-level environments such as embedded systems or OS components.
Standard way in C to do encapsulation is to forward declare a struct and only allow access to its data through functions. This method also creates compile time encapsulation. Compile time encapsulation allows us to change the data structures members without recompilation of client code (other code using our interface). The standard way of doing encapsulation C++ on the other hand (using classes) requires recompilation of client code when adding or removing private member variables.

Kernel development and C++ [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
From what I know, even though the common OS have parts written in other languages, the kernel is entirely written in C.
I want to know if it's feasible to write a Kernel in C++ and if not, what would be the drawbacks.

There are plenty of examples of well-used operating systems (or parts of them) implemented in C++ - IOKit - the device driver subsystem of MacOSX and IOS is implemented in EC++. Then there's the eCOS RTOS - where the kernel is implemented in C++, even making use of templates.
Operating systems are traditionally awash with examples of OO concepts implemented the hard way in C. In the linux device model kobject is effectively the base-class for driver and device objects, complete with DIY v-tables and some funky arrangements implemented in macros for up and down-casting.
The Windows NT kernel has an even more deeply rooted inheritance hierarchy of kernel objects. And for all of the neigh-sayers complaining about the suitability of exception handling in kernel code, exactly such a mechanism is provided.
Traditionally, the arguments against using C++ in kernel code have been:
Portability: availability of C++ compilers for all intended target platforms. This is not really an issue any more
Cost of C++ language mechanisms such as RTTI and exceptions. Clearly if they were to be used, the standard implementation isn't suitable and a kernel-specific variant needs using. This is generally the driver behind the use of EC++
Robustness of C++ APIs, and particularly the Fragile base-class problem
Undoubtedly, the use of exceptions and RAII paradigm would vastly improve kernel code quality - you only have to look at source code for BSD or linux to see the alternative - enormous amounts of error handling code implemented with gotos.

This is covered explicitly in the OSDev Wiki.
Basically, you either have to implement runtime support for certain things (like RTTI, exceptions), or refrain from using them (leaving only a subset of C++ to be used).
Other than that, C++ is the more complex language, so you need to have a bit more competent developers that won't screw it up. Linus Torvalds hating C++ being purely coincidental, of course.

To address Torvalds' concerns and others mentioned elsewhere here:
In hard-RT systems written in C++, STL/RTTI/exceptions are not used and that same principal can be applied to the much more lenient Linux kernel. Other concerns about "OOP memory model" or "polymorphism overhead" basically show programmers that never really checked what happens at the assembly level or the memory structure. C++ is as efficient, and due to optimized compilers many times more efficient than a C programmer writing lookup tables badly since he doesn't have virtual functions at hand.
In the hands of an average programmer C++ doesn't add any additional assembly code vs a C written piece of code. Having read the asm translation of most C++ constructs and mechanisms, I'd say that the compiler even has more room to optimize vs C and can create even leaner code at times. So as far as performance it's pretty easy to use C++ as efficiently as C, while still utilizing the power of OOP in C++.
So the answer is that it's not related to facts, and basically revolves around prejudice and not really knowing what code CPP creates. I personally enjoy C almost as much as C++ and I don't mind it, but there is no rational against layering an object oriented design above Linux, or in the Kernel itself, it would've done Linux a lot of good.

You can write an OS kernel in more or less any language you like.
There are a few reasons to prefer C, however.
It is a simple language! There's very little magic. You can reason about the machinecode the compiler will generate from your source code without too much difficulty.
It tends to be quite fast.
There's not much of a required runtime; there's minimal effort needed to port that to a new system.
There are lots of decent compilers available that target many many different CPU and system architectures.
By contrast, C++ is potentially a very complex language which involves an awful lot of magic being done to translate your increasingly high-level OOP code into machine code. It is harder to reason about the generated machine code, and when you need to start debugging your panicky kernel or flaky device driver the complexities of your OOP abstractions will start becoming extremely irritating... especially if you have to do it via user-unfriendly debug ports into the target system.
Incidentally, Linus is not the only OS developer to have strong opinions on systems programming languages; Theo de Raadt of OpenBSD has made a few choice quotes on the matter too.

The feasibility of writing a kernel in C++ can be easily established: it has already been done. EKA2 is the kernel of Symbian OS, which has been written in C++.
However, some restrictions to the usage of certain C++ features apply in the Symbian environment.

While there is something "honest" about (ANSI) C, there is also something "honest", in a different way, about C++.
C++'s syntactic support for abstracting objects is very worthwhile, no matter what the application space. The more tools available for misnomer mitigation, the better ... and classes are such a tool.
If some part of an existing C++ compiler does not play well with kernel-level realities, then whittle up a modified version of the compiler that does it the "right" way, and use that.
As far as programmer caliber and code quality, one can write either hideous or sublime code in either C or C++. I don't think it is right to discriminate against people who can actually code OOP well by disallowing it at the kernel level.
That said, and even as a seasoned programmer, I miss the old days of writing in assembler. I like 'em both ... C++ and ASM ... as long as I can use Emacs and source level debuggers (:-).

Revision after many years:
Looking back, I'd say the biggest problem is actually with the tons of high level features in C++, that are either hidden or outside the control of the programmer. The standard doesn't enforce any particular way of implementing things, even if most implementations follow common sanity, there are many good reasons to be 100% explicit and have full control over how things are implemented in a OS kernel.
This allows (as long as you know what you are doing) to reduce memory footprint, optimize data layout based on access patterns rather than OOP paradigms, thus improve cache-friendliness and performance, and avoid potential bugs that might come hidden in the tons of high level features of C++.
Note that even tho far more simple, even C is too unpredictable in some cases, which is one of the reasons there is also a lot of platform specific assembly in the kernel code.

Google's new-coming operating system Fuchsia is based on the kernel called Zircon, which is written mostly in C++, with some parts in assembly language[1] [2]. Plus, the rest of the OS is also written mostly in C++[3]. I think modern C++ gives programmers many reasons to use it as a general programming environment for huge codebases. It has lots of great features, and new features are added regularly. I think this is the main motive behind Google's decision. I think C++ could easily be the future of system programming.

One of the big benefits of C is it's readability. If you have a lot of code, which is more readable:
foo.do_something();
or:
my_class_do_something(&foo);
The C version is explicit about which type foo is every time foo is used. In C++ you have lots and lots of ambiguous "magic" going on behind the scenes. So readability is much worse if you are just looking at some small piece of code.

How to design a C / C++ library to be usable in many client languages? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm planning to code a library that should be usable by a large number of people in on a wide spectrum of platforms. What do I have to consider to design it right? To make this questions more specific, there are four "subquestions" at the end.
Choice of language
Considering all the known requirements and details, I concluded that a library written in C or C++ was the way to go. I think the primary usage of my library will be in programs written in C, C++ and Java SE, but I can also think of reasons to use it from Java ME, PHP, .NET, Objective C, Python, Ruby, bash scrips, etc... Maybe I cannot target all of them, but if it's possible, I'll do it.
Requirements
It would be to much to describe the full purpose of my library here, but there are some aspects that might be important to this question:
The library itself will start out small, but definitely will grow to enormous complexity, so it is not an option to maintain several versions in parallel.
Most of the complexity will be hidden inside the library, though
The library will construct an object graph that is used heavily inside. Some clients of the library will only be interested in specific attributes of specific objects, while other clients must traverse the object graph in some way
Clients may change the objects, and the library must be notified thereof
The library may change the objects, and the client must be notified thereof, if it already has a handle to that object
The library must be multi-threaded, because it will maintain network connections to several other hosts
While some requests to the library may be handled synchronously, many of them will take too long and must be processed in the background, and notify the client on success (or failure)
Of course, answers are welcome no matter if they address my specific requirements, or if they answer the question in a general way that matters to a wider audience!
My assumptions, so far
So here are some of my assumptions and conclusions, which I gathered in the past months:
Internally I can use whatever I want, e.g. C++ with operator overloading, multiple inheritance, template meta programming... as long as there is a portable compiler which handles it (think of gcc / g++)
But my interface has to be a clean C interface that does not involve name mangling
Also, I think my interface should only consist of functions, with basic/primitive data types (and maybe pointers) passed as parameters and return values
If I use pointers, I think I should only use them to pass them back to the library, not to operate directly on the referenced memory
For usage in a C++ application, I might also offer an object oriented interface (Which is also prone to name mangling, so the App must either use the same compiler, or include the library in source form)
Is this also true for usage in C# ?
For usage in Java SE / Java EE, the Java native interface (JNI) applies. I have some basic knowledge about it, but I should definitely double check it.
Not all client languages handle multithreading well, so there should be a single thread talking to the client
For usage on Java ME, there is no such thing as JNI, but I might go with Nested VM
For usage in Bash scripts, there must be an executable with a command line interface
For the other client languages, I have no idea
For most client languages, it would be nice to have kind of an adapter interface written in that language. I think there are tools to automatically generate this for Java and some others
For object oriented languages, it might be possible to create an object oriented adapter which hides the fact that the interface to the library is function based - but I don't know if its worth the effort
Possible subquestions
is this possible with manageable effort, or is it just too much portability?
are there any good books / websites about this kind of design criteria?
are any of my assumptions wrong?
which open source libraries are worth studying to learn from their design / interface / souce?
meta: This question is rather long, do you see any way to split it into several smaller ones? (If you reply to this, do it as a comment, not as an answer)

Mostly correct. Straight procedural interface is the best. (which is not entirely the same as C btw(**), but close enough)
I interface DLLs a lot(*), both open source and commercial, so here are some points that I remember from daily practice, note that these are more recommended areas to research, and not cardinal truths:
Watch out for decoration and similar "minor" mangling schemes, specially if you use a MS compiler. Most notably the stdcall convention sometimes leads to decoration generation for VB's sake (decoration is stuff like #6 after the function symbol name)
Not all compilers can actually layout all kinds of structures:
so avoid overusing unions.
avoid bitpacking
and preferably pack the records for 32-bit x86. While theoretically slower, at least all compilers can access packed records afaik, and the official alignment requirements have changed over time as the architecture evolved
On Windows use stdcall. This is the default for Windows DLLs. Avoid fastcall, it is not entirely standarized (specially how small records are passed)
Some tips to make automated header translation easier:
macros are hard to autoconvert due to their untypeness. Avoid them, use functions
Define separate types for each pointer types, and don't use composite types (xtype **) in function declarations.
follow the "define before use" mantra as much as possible, this will avoid users that translate headers to rearrange them if their language in general requires defining before use, and makes it easier for one-pass parsers to translate them. Or if they need context info to auto translate.
Don't expose more than necessary. Leave handle types opague if possible. It will only cause versioning troubles later.
Do not return structured types like records/structs or arrays as returntype of functions.
always have a version check function (easier to make a distinction).
be careful with enums and boolean. Other languages might have slightly different assumptions. You can use them, but document well how they behave and how large they are. Also think ahead, and make sure that enums don't become larger if you add a few fields, break the interface. (e.g. on Delphi/pascal by default booleans are 0 or 1, and other values are undefined. There are special types for C-like booleans (byte,16-bit or 32-bit word size, though they were originally introduced for COM, not C interfacing))
I prefer stringtypes that are pointer to char + length as separate field (COM also does this). Preferably not having to rely on zero terminated. This is not just because of security (overflow) reasons, but also because it is easier/cheaper to interface them to Delphi native types that way.
Memory always create the API in a way that encourages a total separation of memory management. IOW don't assume anything about memory management. This means that all structures in your lib are allocated via your own memory manager, and if a function passes a struct to you, copy it instead of storing a pointer made with the "clients" memory management. Because you will sooner or later accidentally call free or realloc on it :-)
(implementation language, not interface), be reluctant to change the coprocessor exception mask. Some languages change this as part of conforming to their standards floating point error(exception-)handling.
Always pair a callbacks with an user configurable context. This can be used by the user to give the the callback state without defining global variables. (like e.g. an object instance)
be careful with the coprocessor status word. It might be changed by others and break your code, and if you change it, other code might stop working. The status word is generally not saved/restored as part of calling conventions. At least not in practice.
don't use C style varargs parameters. Not all languages allow variable number of parameters in an unsafe way
(*) Delphi programmer by day, a job that involves interfacing a lot of hardware and thus translating vendor SDK headers. By night Free Pascal developer, in charge of, among others, the Windows headers.
(**)
This is because what "C" means binary is still dependant on the used C compiler, specially if there is no real universal system ABI. Think of stuff like:
C adding an underscore prefix on some binary formats (a.out, Coff?)
sometimes different C compilers have different opinions on what to do with small structures passed by value. Officially they shouldn't support it at all afaik, but most do.
structure packing sometimes varies, as do details of calling conventions (like skipping
integer registers or not if a parameter is registerable in a FPU register)
===== automated header conversions ====
While I don't know SWIG that well, I know and use some delphi specific header tools( h2pas, Darth/headconv etc).
However I never use them in fully automatic mode, since more often then not the output sucks. Comments change line or are stripped, and formatting is not retained.
I usually make a small script (in Pascal, but you can use anything with decent string support) that splits a header up, and then try a tool on relatively homogeneous parts (e.g. only structures, or only defines etc).
Then I check if I like the automated conversion output, and either use it, or try to make a specific converter myself. Since it is for a subset (like only structures) it is often way easier than making a complete header converter. Of course it depends a bit what my target is. (nice, readable headers or quick and dirty). At each step I might do a few substitutions (with sed or an editor).
The most complicated scheme I did for Winapi commctrl and ActiveX/comctl headers. There I combined IDL and the C header (IDL for the interfaces, which are a bunch of unparsable macros in C, the C header for the rest), and managed to get the macros typed for about 80% (by propogating the typecasts in sendmessage macros back to the macro declaration, with reasonable (wparam,lparam,lresult) defaults)
The semi automated way has the disadvantage that the order of declarations is different (e.g. first constants, then structures then function declarations), which sometimes makes maintenance a pain. I therefore always keep the original headers/sdk to compare with.
The Jedi winapi conversion project might have more info, they translated about half of the windows headers to Delphi, and thus have enormous experience.

I don't know but if it's for Windows then you might try either a straight C-like API (similar to the WINAPI), or packaging your code as a COM component: because I'd guess that programming languages might want to be able to invoke the Windows API, and/or use COM objects.

Regarding automatic wrapper generation, consider using SWIG. For Java, it will do all the JNI work. Also, it is able to translate complex OO-C++-interfaces properly (provided you follow some basic guidelines, i.e. no nested classes, no over-use of templates, plus the ones mentioned by Marco van de Voort).

Think C, nothing else. C is one of the most popular programming languages. It is widely used on many different software platforms, and there are few computer architectures for which a C compiler does not exist. All popular high-level languages provide an interface to C. That makes your library accessible from almost all platforms in existence. Don't worry too much about providing an Object Oriented interface. Once you have the library done in C, OOP, functional or any other style interface can be created in appropriate client languages. No other systems programming language will give you C's flexibility and potability.

NestedVM I think is going to be slower than pure Java because of the array bounds checking on the int[][] that represents the MIPS virtual machine memory. It is such a good concept but might not perform well enough right now (until phone manufacturers add NestedVM support (if they do!), most stuff is going to be SLOW for now, n'est-ce pas)? Whilst it may be able to unpack JPEGs without error, speed is of no small concern! :)
Nothing else in what you've written sticks out, which isn't to say that it's right or wrong! The principles sound (mainly just listening to choice of words and language to be honest) like roughly standard best practice but I haven't thought through the details of everything you've said. As you said yourself, this really ought to be several questions. But of course doing this kind of thing is not automatically easy just because you're fixed on perhaps a slightly different architecture to the last code base you've worked on...! ;)
My thoughts:
All your comments on C interface compatibility sound sensible to me, pretty much best practice except you don't seem to properly address memory management policy - some sentences a bit ambiguous/vague/wrong-sounding. The design of the memory management will be to a large extent determined by the access patterns made in your application, rather than the functionality per se. I suiggest you study others' attempts at making portable interfaces like the standard ANSI C API, Unix API, Win32 API, Cocoa, J2SE, etc carefully.
If it was me, I'd write the library in a carefully chosen subset of the common elements of regular Java and Davlik virtual machine Java and also write my own custom parser that translates the code to C for platforms that support C, which would of course be most of them. I would suggest that if you restrict yourself to data types of various size ints, bools, Strings, Dictionaries and Arrays and make careful use of them that will help in cross-platform issues without affecting performance much most of the time.

your assumptions seem ok, but i see trouble ahead, much of which you have already spotted in your assumptions.
As you said, you can't really export c++ classes and methods, you will need to provide a function based c interface. What ever facade you build around that, it will remain a function based interface at heart.
The basic problem i see with that is that people choose a specific language and its runtime because their way of thinking (functional or object oriented) or the problem they address (web programming, database,...) corresponds to that language in some way or other.
A library implemented in c will probably never feel like the libraries they are used to, unless they program in c themselves.
Personally, I would always prefer a library that "feels like python" when I use python, and one that feels like java when I do Java EE, even though I know c and c++.
So your effort might be of little actual use (other than your gain in experience), because people will probably want to stick with their mindset, and rather re-implement the functionality than use a library that does the job, but does not fit.
I also fear the desired portability will seriously hamper development. Just think of the infinite build settings needed, and tests for that. I have worked on a project that tried to maintain compatibility for 5 operating systems (all posix-like, but still) and about 10 compilers, the builds were a nightmare to test and maintain.

Give it an XML interface, whether passed as a parameter and return value or as files through a command-line invocation. This may not seem as direct as a normal function interface, but is the most practical way to access an executable from, e.g., Java.