| 07/30/05 |
A Preliminary FAQ
Q: Why on Earth ... ?!
A: That question will be answered later. The short version is: it's useful in creating readable code generation and translation, security testing, creating lightweight compiler tools, and most especially centered in the subject of dynamic-linking and memory-management. The original reason was to increase readability, increase organization, and speedup the completion of programming projects in C. From current tests, it seems to work frighteningly well.
Q: How ?
A: Our current set of solutions to attempt include:
1.) Using GCC's nested functions (But then, we'd still need a solution for other compilers... ).
2.) Using GCC's __builtin_apply/return utilities, but we'd still run into the same problem described above.
3.) Using shared memory to provide 'function-mappings', emulated page tables, and emulated interrupt vectors (but without swapping to disk: we'll let the system handle that... )
4.) Attaching Extended C's backend to CORBA and the like, (thus completing a vicious circle, using language-level objects to wrap functions that wrap objects at runtime)
5.) Run multiple tests on multiple systems to see if the calling object's address can be found close to the stack in a predictable place (via asm calls), even if it means #if statements for each architecture. Note that this would also be the best of all worlds, since we would then not ever have need to keep track of an object registry. However, it'll also be the most time-consuming ... and it certainly isn't guaranteed to actually work.
Q: Is it ready?
A: Yes and no. The proof-of-concept works. This was necessary "to prove that it can be done." However, it has many shortcomings, none of which actually threaten your use of Extended C except ONE big one (that I know of. If anyone else finds any, please let me know. Just remember there is a big difference between a shortcoming and a condition that the end-user developer already needed to worry about without Extended C). Mainly, if someone tries to use it when temporarily locking all other threads and one of those locked threads is just about to call a function (on the same line, and thus has a registry mutex-lock (Do a search in your browser for phase1.h's alias(func) macro for details)), then the program will hang if the one thread still-running tries to call a member-function. This will not be a problem in later versions.
Q: Hey, don't you know about C++'s extern "C" feature or Objective-C ?!
A: Yes. Yes we know. We love C++, and Objective-C looks fascinating ... almost akin to O-Caml at a first glance. However, there will always be times when you're forced to use a particular language, and according to the Great Language Shootout, C is simply one of the two fastest languages available to-date. (OCaml gets the record for fastest from The Great Language Shootout.) C is also still used in many situations, including embedded systems, Java, *nix, real-time applications, and many, many research projects. The goal of this project is not only object-oriented programming in C, but object-oriented programming with nearly any standard C compiler, and with straight C code. Anything else is just a cool and unexpected bonus, as far as this project is concerned.
Q: Why are you worrying about processes when process-memory is almost never shared?
A: Good question. It was part of an earlier design. In fact, after the next redesign, there will only be one case where mutexes are necessary. The registry will be re-written in terms of shared memory rather than process/thread space, but that will be done later.
Q: I saw Project XYZ already did what you're doing!
A: That's not a question. And why didn't you send us a link earlier? We're collecting and linking these sites, you know!
Q: Will there be support for mmap/MapViewOfFile/etc?
A:
Yes, mapping will be an available switch to speed up existing features (the goal is to eliminate linear-searching) and to provide many of the advanced features. Furthermore, we hope to gain insight on using memory-mapping to simulate non-i/o paging and setup an abstraction layer with which to create/load/save 'custom' functions and objects ... think of them as 'template' DLLs and linked libraries - mostly for use within an active program, but there are obvious benefits in persistent use as well -- we also realize that much of this has been done before, in bits and pieces, and rarely as a primary focus. The examples we can think of (Win32 is the most glaringly obvious) also have far too-specialized purposes and designs to be of any realistic use to us (well, that's not completely true with such projects as CORBA, which as mentioned above, we will want to read-up on), which is why we will implement our own wrapper (or our own version, depending on how much support there is at user level for these system calls), but as a separate sub-project, and emphasize a more open-ended portable-toolkit design.
Q: Will there be a version optimized for use in private-memory threads/processes, threadless programs, embedded systems, and the like?
A:
Oh yes we plan for the registry to activate only if it detects a need for its assistance. (Think of it as an insurance policy system for shared-memory.) If shared-memory wasn't an issue, this extension would be a snap to complete, and with no slow-down! (This is because there would not be a need for any extra functionality aside from a member-access pointer.)
Q: Don't tell me you're planning on mucking around in address spaces on different architectures?!
A:
One of these years ... but that year is not this one. (It might be next year, though.) The hope is that one day, the registry (a searching mechanism restricted to linear search-times) will no longer be necessary for use with shared-memory, and the object-information look-up will be done through dynamic libraries and function pointers at constant time, rather than linear - There are many other ideas that can benefit from such information (info in a plainly-understood format, that is), such as stronger system/process protection, variants on dynamic function/object passing through pipes and sockets like RPC or setting a VM up on demand (obviously security and ssh port-forwarding would be absolutely essential in this case), and many more ideas!
Q: What about Windows support?!
A:
Yes, there will be Windows support.
Q: I read the source code. It looks like you don't know what you're doing...
A: Was it that hard to figure out?
That code is a combination of old and new. This isn't a two-day stint. A lot of research has gone into this project, and a lot more awaits, including Windows and *nix processes/ threads /virtual memory layouts. We keep on saying this is a work in progress, a proof of concept, and is intended, but not yet ready for development (unless you, like us can't stand to pretend to use C in an object-oriented fashion unless it's got object-oriented features. After the redundancy and non-intuitive gotchas are taken out, it'll also be quite suitable for academic work) The point of creating and displaying the original source code version 0.0.1 (as opposed to what we'll be deriving from it on SourceForge.net) is to show that it can be done, and from this little bit, you can get a better picture of all the interesting applications and extensions waiting for development.
Furthermore, when we first considered this idea two years ago we had even less knowledge, but we were also looking for support from a teacher who was knowledgeable in compilers -
So we went to several outstanding teachers for help. To be fair, these teachers are very busy with many of their own research projects, and there were many, many student projects two years ago -- we got referred, blown-off, grilled for information and names,
and one teacher even decided to practice sleight-of-hand and diversion-tactics in showing us how much we didn't know! In retrospect, we know he gave us some awesome ideas. Since we plan on using many of those ideas, we will reference him and his work later. (But we won't point out which reference name is associated with this story!)
The main point for this final question is that the temporary backend was originally slated for the trash, and thus no task exists for optimizing it too much since it's temporary and will be replaced, but since we don't have much time (not until August 10th) to devote to the new backend,
we will alter the old one somewhat - mainly by removing the counterproductive bit shift in the t_hash function: a bitshift by two is useful in hashing when memory addresses are input but not when the least significant bits of the input are actually part of a thread id. (Most structures are greater than four bytes, and thus the addresses of such structures always differ by at least four bytes.) We will also choose a better hash size.
~Jtoxification
|