Kevin Lawton wrote:
> So how do you code this, so that in one high-performance
> case you don't have the 'this' pointer pushed. But perhaps
> in a lower performance case, you have more than one
> instance (like cosimulation in bochs where you have 2 CPU
> simulations running head-to-head), in which case the 'this'
> pointer is necessary and not so much of a problem.
>
> // high performance case: all static member functions
> void
> some_class:some_function(unsigned a)
> {
> some_instance.xyz = a;
> }
>
> // low performance case: this pointer available
> void
> some_class:some_function(unsigned a)
> xyz = a;
> -or-
> this->xyz = a;
> }
>
> Had the C++ designers thought of this, they could have easily
> added a directive that would let you bind a specific instance
> name to the class for the static case. The address of that
> instance would then effectively be the 'this' pointer. And
> no nasty #define hacks would be necessary.
>
> Handling high performance callbacks suffers similar problems.
These FEW things are *exactly* the cases where using C makes sense. Maybe
even hand-tuned assembler, if it is really going to be called that often and
overhead is really that critical. Special cases warrant special solutions.
That's, what, 0.01% of the code base? Literally a few calls, right? Does
that warrant tossing out an entire language because it fails to handle one
specific case?
Hell, no!
> I remember from my days of reading through the Stroustrup book
> and even taking a C++ class, there were some real _major_
> f*#! ups in the design, but they were all in features you talk
> about eliminating.
>
> But, rather than go into a rant about C++, I leave off with the
> following quote"
>
> "C makes it easy to shoot yourself in the foot. C++ makes it harder,
> but when you do, it blows away your whole leg." - Bjarne Stroustrup
Which is why I STRONGLY recommend using only the lightest-weight parts of
C++ that offer the greatest benefits. I haven't looked at ObjectiveC that
closely, but remember that Next did write nearly an entire OS in that
language, and it ran quite well. Something to look at as an example of
high-performance system-level OO.
Let's allow for the POSSIBILITY that a diluted form of C++ can help Plex86.
And those of us that want to bang our heads against it can do so without
forking the project!
To tell you the truth, I have yet to find ANY case where full C++ is the
"best" language to use. For very high-level OO stuff, I find scripting
languages to be superior (Python and Ruby). I have written several
application-specific Python extensions in lightweight C++ to implement the
high-speed stuff, then kick back and let the script do the rest. There is a
huge productivity boost when doing R&D and rapid prototyping without a
compiler in the develop-test loop.
Since Python doesn't fit in a ROM either, I have used py2c to get some quick
and dirty C code generated, then massage that (in a Hannibal Lecter sort of
way - the generated code ain't all that purty) to become my final app. Or
(more often) I sue the Python code as the design document for my C code.
Either way, the productivity is astounding. I have also used the route of
moving more and more of the app into Python callable modules, then finally
write a C skeleton to tie the modules together and eliminate the last Python
code. Both ways work, and are hair-on-fire fast.
Does Plex86 allow for a tightly integrated modeling/scripting environment to
be used for prototyping? It would be great to be able to quickly gen up an
algorithm in Python or Ruby, debug it at a high level and make sure it works
before taking it to low-level code. It would allow multiple alternatives to
be tested quickly and easily, and help avoid pursuing dead-ends in low-level
code.
If Plex86 were "g++ compatible", it would be possible to make the whole thing
a Python module (set of modules?), with all required data structures
exposed. Python has at least two ways of making C++ code accessible to
Python scripting.
While I have never personally tried to merge an existing project with Python
(I've always started with a clean slate and proceeded incrementally), it is
at least a tantalizing possibility that would exist if Plex86 were to become
"g++ compatible".
Your current hashing problem is EXACTLY the kind of problem best solved in an
environment that supports rapid prototyping and even some simple simulation
(of the CPU caches, in this case). There are enough knobs to twist that the
"best" algorithm is far from obvious. It would help if there were a way to
quickly and easily test and weed out the losers, before committing the one or
two finalists to low-level code and "real world" testing (always the final
arbiter). It is a straightforward task to instrument Python code to the
level of providing full simulation capabilities (actually, I tend to use
co-simulation, but that's just my preference).
Not that glomming a Python interface onto Plex86 would be practical or
useful! But it is a real possibility, one of many.
-BobC
