Tom Vijlbrief wrote:
>
> Hmmm, I promised myself not to enter further C/C++
> discussions and I think the discussions should stop
> but I'd like measured data.
Sure. Bochs used to be C. Then I upgraded it to C++
with no other real changes, other than to classify stuff.
Emulation got about 15% slower. When I then hacked all
the static jazz to make the generated code effectively
C, it was back to near C speed.
BTW, direct class variable addresses can be cached in
registers/local stack across multiple accesses, by the
compiler. And since you can load a register with an immediate
(an offset) which is a real pipe-line friendly thing to
do, you get no benefit from your stack locality argument.
Actually, you loose because of the extra push.
Programs like bochs suffer drastically from this kind of hit,
since some parts are operating at millions of times per second.
This is just an inherent weakness in using C++ for a high
cycle-rate piece of code. Of course, it can be eliminated
with some really nasty #define hacks, like I did. But would
have been better handled by a real C++ directive which
bound a particular instance to the member functions, so the
this pointer would be loaded with an immediate value (the
instance address) rather than from the implicit 1st arg on
the stack.
Not that any of this matters. Before using C++, we'd have
to make sure all the host kernels (Linux, *BSD, etc) could
handle C++, since some of our user code might have to
operate there in the future.
In order to make C++ work, we would have a compiler option
that would flip it into a "glorified C" mode, which was
talked about recently:
- remove any kind of virtual function reference and fancy C++ features.
- make all member functions static.
- remove name mangling
This would make the generated code effectively C, and let it interoperate
with real C code, linker/loaders, etc in the kernel space. But allow
functions to be class'ified. And even better, let us use C++ comments.
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
