There is a program that utilizes APIs written in Java, C++, and C. Do you need to describe an ABI for these to function effectively?
From what I understand, an ABI acts as an API at a lower level for an API. (ABI is used to define how different components of binary code can interface for a given operating
system on a given architecture)
I am not too sure about this. Correct me if I am wrong and please provide details on whether an ABI is required for an API to function.
There is a program that utilizes APIs written in Java, C++, and C. Do you need to describe an ABI for these to function effectively?
An ABI only covers the low level mechanics - things like how parameters are passed (in CPU registers, on the stack) and a few other details (stack alignment requirements, which registers are "callee saved" and which are trashed by callee, etc). The ABI doesn't care about things like what functions do.
An API is the opposite - it only cares about things like what functions do (how programmers use the API from high level languages), and doesn't care about the low level mechanics (how parameters are passed, etc).
Examples are any of the portable open source libraries (zlibc, SDL, OpenSSL, GMP) or any of the standardized APIs (OpenGL, MPI, the standard library/libraries that are part of the language you're using); where the API is the same regardless of which ABI the compiler happens to be using.
A counter-example is firmware interfaces (e.g. UEFI) where the same specification describes both the API and the ABI (primarily because you can't just recompile and reinstall firmware when you feel like installing a different OS with a different "preferred" ABI).
Note: Because Java primarily uses JIT, it doesn't have a concept of "ABI" (or, the "ABI" is an internal implementation detail that nothing outside the JVM knows about) and code written in Java can't be called by code written in other languages. There are special allowances (the Java Native Interface) to allow Java software to call native code via. whatever ABI the native code uses.
Correct me if I am wrong and please provide details on whether an ABI is required for an API to function.
Technically, some sort of ABI would be needed for the API to function it's just that normally you don't care which ABI it is (in a similar way, some sort of machine code would be needed for high level language source code to be executed, but you rarely have a reason to care which CPU's machine code it is).
Related
Is there a statically compiled programming language that is both stackless and heapless?
For data, such a language would not have a concept of memory allocation. Instead, the memory requirements of the program would be known completely at compile-time.
For code, there would not be a concept of call stack. There could be functions, but they'd be inlined at every call site.
I am specifically interested by portable languages with some form of implementation or a compiler that produces native binaries.
Pure x86 machine language fits your stackless and heapless constraints(within real mode constraints). Portability is not possible, unless the compiler has access to every memory location for all hardware IO(memory locations) that are Fixed for all supported platforms(this condition excludes all dynamic interfaces including PlugandPlay, USB, and PCI/PCIE busses)
It is completely possible to create such a structure within severe hardware limits(every device must be compiled in and allocated at boot, as in older computers like the c64 or Apple II) but all functionality must be pre-compiled into the OS, as in every program possible that is to run on the platform.
This is not a general computing platform anymore. Program a micro-controller, GPU, or ASIC to solve the task instead.
I saw the two projects are quite related, but what are the differences between them? The official webpage doesn't tell much about it.
I know that ABI (Application Binary Interface) is used to provide low-level binary interface among different platforms. So is libc++abi used to provide different implementations for different platforms, and general interface for libc++?
Would be better go give some specific example, e.g. what are included in libc++abi and what in libc++.
Thanks.
The Application Binary Interface, or ABI for short, is intended to provide certain low level functions from which to build the C++ standard library. It is a supporting library that is a separate component from the actual standard library. Along with libcxxabi, you may also come across Pathscale's libcxxrt or GCC's libsupcxx.
On the other hand, libc++ is an implementation of the C++ standard library that can be built using either of the 3 mentioned ABIs.
We'd like to offer a compiled library that implement a protocol layer to be imported into C/C++ source code project for microcontrollers. And eventually expose a sort of compiled function to the source code project. let's say a sort of "dll". Is there any know technique to realize something of similar?
While it is possible to provide functions via a library, generally in the microcontroller/embedded realm it quickly becomes impractical.
Each microcontroller core will have a unique instruction set. Further, micros from the same family may have a variety of extensions which are either supported or not... So you're left with providing a library file for each individual microcontroller (from each vendor) that you'd like to support.
But...
In my experience, calling conventions between compilers are not the same. So a library compiled by one toolchain will not be able to be linked to object files created by another toolchain.
That leads you to then provide a library for each individual micro from each vendor for each toolchain someone might use. Ick. Oh, and don't rely on an OS calls either, as you don't know what you'll be linked with...
A more conventional approach is to use the same approach RTOS vendors tend to use: provide the source, and protect your IP with licensing terms. The reality is that if your end users want to, they can step through the assembly and figure out exactly what is happening, so you're not hiding your implementation that carefully anyway.
I'd like to ask if gnustep's toolchain is appropriate for netbsd development where one'd normally use plain C. I'm interested in the benefits of Obj-C only with basic APIs like NSObject's reference counting and dynamic stuff.
My question is twofold:
is gcc's Obj-C ABI compatible with gcc's C ABI? so that I can use regular C libraries
is Obj-C's runtime layer good to go where netbsd targets embedded?
Thank you in advance!
is gcc's Obj-C ABI compatible with gcc's C ABI? so that I can use regular C libraries?
This has nothing to do with the ABI at first glance. Objective-C is a strict superset of C, so it's true on every platform that you can use C code with Objective-C code. You can even call Objective-C methods from plain C code using the Objective-C runtime library.
is Obj-C's runtime layer good to go where netbsd targets embedded?
I don't exactly see what the question is here. Are you asking whether it is possible to port GNUstep to embedded platforms? If so, I'd say yes, it should normally be possible (with the appropriate constraints of an embedded system), but in my opinion, it's too heavyweight for embedded development.
If you aren't interested by AppKit, you may also take a look at https://webkeks.org/objfw/.
Runtimes may contain assembly bits that you will want to verify that they will actually work on specific CPU type. Old Foundation library like libFoundation may also suite your needs. If you want to use thing like Objective-C++ or Objective-C 2.0, I'd recommend clang instead of gcc.
What are the programming features that are missing in C++ and Java ?
For eg. You can't do recursive programming in QBasic ? You can't dynamically allocate memory in QBasic.
What would be the good to have features in C++, Java.
I think Lisp Programmers will be able to add a few.
I miss lambda expressions.
This answer deals only with C++
Things I miss from the syntax, or the standard library:
RegExp as part of the standard library
Threads as part of the standard library
Pointer to member methods (not objects!)
Properties would be nice (I have seen codes that emulate this via C++ preprocessor... note an nice looking code).
Some lower level networking API (sockets!), and higher level API (give me this file from this ftp, submit "this" to this site via POST).
This is the list of things I would like to see, but I assume other people will disagree with me.
Memory garbage collector is nice.
A n interface for a GUI toolkit - let MSVC map it to win32, and on Linux... (good question!)
A stable ABI. In C it's a standard - but on C++ we are still missing a few decades. I want also stable ABI between compilers - I want to compile one library in MinGW, the other with CL and all should work.
This is the list of things I want to see, but I know they will not get away:
Compatibility with C. Really, it's a myth right now. using namespace std killed it.
Include, headers. Most of the information is already available in the DLL/so/a/"library", do we really need to keep this bad decision from 30 years ago? If needed the compilers should keep information in the binaries.
The need for Makefiles - the compiler should be smart enough to know what to do with this code, from the code itself. Pascal is doing it quite good. I think also D.
(I might be wrong, please correct me) The official standard openly and freely available for viewing. Why should I pay for the official papers? Do I need to do it for HTTP? UTF8? Unicode?
I think this is a very subjective question. From a theoretical point of view there's nothing "missing" in Java because you can do everything you want to from the perspective of the outcome as an application.
As with QBasic - recursion may not be possible but that doesn't prevent you from changing your recursive algorithm to an iterative algorithm. Programming language theory tells us that you can do this with every recursive problem. So there's also nothing missing here.
I think what you mean are features that are "nice to have" - and here everyone has to decide for himself. I'd even say there are features in the language which would have been "nice not to have" such as static imports - but again this is my subjective opinion...