Linked by Thom Holwerda on Wed 9th Nov 2011 21:26 UTC, submitted by edwin
General Unix Way back in 2002, MIT decided it needed to start teaching a course in operating system engineering. As part of this course, students would write an exokernel on x86, using Sixth Edition Unix (V6) and John Lions' commentary as course material. This, however, posed problems.
Thread beginning with comment 497010
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: binary for windows....
by Alfman on Sat 12th Nov 2011 00:08 UTC in reply to "RE[3]: binary for windows.... "
Alfman
Member since:
2011-01-28

Vanders,

"The glue code is either needed, or it is not needed. If it's needed, then you can't simply "optimize it away". If it's not needed, then you can just remove it from the syscall shim."


I agree with most of your post, but the problem with shared libraries is that often times they just add a layer of indirection to the syscall without adding much value. If you use a shared library to perform a function, then you cannot optimize away the glue code used to call the shared library.

On the other hand if we're willing to internalize the code into a static binary, the glue code becomes unnecessary (I'm not sure that GCC/LD will do this kind of optimization, but the potential is certainly there).

Reply Parent Score: 2

Vanders Member since:
2005-07-06

If you use a shared library to perform a function, then you cannot optimize away the glue code used to call the shared library.


That's not how shared libraries work. There is no more code required (at run time) to call a function in a shared library than there is in calling a function within the executable.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

Vanders,

"That's not how shared libraries work. There is no more code required (at run time) to call a function in a shared library than there is in calling a function within the executable."

You're kind of missing my point, though. I know that shared library functions are mapped into the same address space as static functions, and can be called the same way. But the fact that a function belongs to a shared library implies that it must abide by a well defined calling convention, and subsequently translate it's internal variables to and from this interface. There are optimizations that can take place in a static binary that cannot take place with a shared library.

For example, we obviously cannot do inter-procedural analysis and optimization against a shared library function (since the shared library function is undefined at compile time). Theoretically, using static binaries, an optimizing compiler could analyze the call paths and eliminate all the glue code. Trivial functions could be inlined. Calling conventions could be ignored since there is no need to remain compatible with external dependencies.

In the ideal world, object files would be an intermediate representation like java class files, or .net assemblies. Not only would the run time compilation optimize for the current platform, but it could also perform inter-procedural optimization that might eliminate all costs currently associated with glue code.

Reply Parent Score: 2