On 23 Aug 2006 at 17:43, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
- Is it possible to have reduced functionality versions of libgpc
(perhaps produced with a switch when building the compiler?)? If so, is it possible to choose which features shall be built into it? (e.g., via a simple text configuration file, of the kind you have when building the linux kernel, or busybox, etc.).
If so, then configure options might be the obvious way to go.
Indeed.
What I mean is something like (please note, this is off the top of my head, and is not properly thought through - it may even be impossible or the necessary features may not be in libgpc at all, but rather in the compiler):
They're in both of them which doesn't help. I.e., if you built an RTS without string support, some operations that don't look like RTS calls (e.g. "+" for strings) would lead to undefined linker references.
Yes, I thought so.
One could add explicit checks in the compiler, but (slightly tangential to the topic) I'm thinking of a different route here: So far, the compiler creates RTS calls based on "magic" linker names ("_p_Set_Union" etc.) and makes implicit declarations for them which have to match the RTS declarations. Now we could instead properly import the RTS declarations from GPI files. (Previously, due to lack of qualified identifiers and selective import, this would have created namespace conflicts, but now that these features are available, it can be done.) The compiler would then call the RTS based on (still "magic") Pascal-level declarations, so when a version of the RTS omits them, the compiler will simply notice the absence of those declarations in the RTS GPI files and could emit somewhat clearer errors.
Sounds good to me.
There would be some strange effects, though. E.g., comparing two strings requires an RTS call, but comparing one string against '' does not because it can be optimized to a comparison of its length against 0. Removing the respective RTS routine would mean that the latter would still work, but the former wouldn't. Of course, one could explicitly forbid the former as well when the RTS routine isn't found (not sure if rather useful or annoying).
Either is fine.
[...]
One idea I have in mind WRT the RTS is to reorganize its units, so we'd have a (clearly visible) core of routines that are interrelated and provide the basic support, and put this in the lowest-level RTS unit. This would include runtime errors, and the necessary amount of string and file capabilities to support them, whereas e.g. additional string and file features not strictly needed here would be one level higher.
This would be excellent.
[...]
- What things can be done in GPC without libgpc - for example, if
one produced an include file of libc exports and doesn't use units or Pascal strings or objects or file I/O at all?
Basically yes, though there isn't an "official" list of which internals require RTS calls (and this might change slightly over time), so one can only try, looking at the linker errors (undefined references).
Producing an empty libgpc.a to compile a simple "begin end." program produced 4 linker errors - rts version, initialize, finalize, and something else which I forget. I wrote simple stubs - functions returning 0 with those names and put them in libgpc.a. That sorted out those problems. I wrote a small include file with a few libc routines (malloc, free, puts, gets, system, printf, functions from string.h, etc) and wrote a little test program to test various things. The program compiled to between 5kb and 9kb, and I was able to read and write strings with it, get and set environment variables, and stuff. My little CGI program doesn't really need more than these routines. But the ensuing program would look more like C than Pascal.
I will have a look again at rts.c.
What would be helpful is a way to specify a particular "libgpc" to the compiler at compile time - e.g., "gpc foo.pas --libgpc=small_libgpc"
So, instead "-lgpc", the compiler will get "-lsmall_libgpc". Can this be done at the moment?
- Would there be any mileage in producing a libc standard unit?
libc is a rather vague term here. Such a unit could be anything from a non-portable interface of the 6 most important libc calls (open, close, read, write, fork, exec, according to Linus ;-) to a fully portable interface to all known libc's on this planet, with interface to all functions supported by any of them plus emulations/errors where not supported ...
"Standard" GNU libc, if such a thing exists.
The RTS's rts.c file (plus rtsc.pas interafaces) is somewhat closer to the latter extreme (though there are still many areas of libc not covered yet). It actually makes available many functions in "C style" (e.g. OpenHandle etc., visible in gpc.pas), besides being used in the RTS to implement the higher-level routines. So to some extent this is such a unit already.
Great. I will have a look at it.
I suppose you're more thinking of a rather minimal unit. A problem is that different programmers (and even different projects by the same programmer) will often disagree just how minimal it should be.
Indeed. Which is why I wondered whether the contents of it could be set by configuration entries.
In the end, a bigger unit may fare better when automatically removing the unused parts. Yes, I know, we need smart linking ...
Indeed. Until now, I hadn't seen the urgency. Now that I know for sure that GPC can be used in embedded system programming, the problem of the size of the generated binaries has become more visible.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/