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.
Permalink for comment 497019
To read all comments associated with this story, please click here.
RE[6]: binary for windows....
by Alfman on Sat 12th Nov 2011 04:59 UTC in reply to "RE[5]: binary for windows.... "
Member since:


"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