Re: Where to look for dynamic code loading
Re: Where to look for dynamic code loading
- Subject: Re: Where to look for dynamic code loading
- From: Jeff DuMonthier <email@hidden>
- Date: Thu, 2 Mar 2006 09:51:21 -0500
On Mar 1, 2006, at 11:53 PM, Eric Albert wrote:
I'm a bit surprised at that -- I'd expect CFBundle to work fine for
loading C++ code. Do you have a reference for that?
It looks like I was a bit confused there. I was looking at ADC
Home->Reference Library->Documentation->Core Foundation->Resource
Management->Bundles, and the section on loading executable code. It
does say CFBundle works for C, C++ or objective C. It's NSModule that
works for Objective-C but not C++. I must have been jumping back and
forth between sections. There are only examples for loading function
pointers, not classes, from a CFBundle, but it's only an overview at
that point. I'll have to look at the more detailed reference.
Does XCode 1.5 under 10.3 support something like that?
Probably, but I'm afraid I don't remember how. Can you use Xcode 2
and Tiger? That'll make things easier for you.
I was hoping to skip 10.4 entirely unless I bought a new machine. That
seems unlikely now that I'd have to choose between the end of the line
PPC and first generation Intel, and the first generation pro Intel's
aren't even out yet.
The problem with a single binary is that if you build with the
-faltivec flag the code will crash on G3 machines even if you don't
call any Altivec functions.
I'm pretty sure that's not supposed to be the case, but I might be
thinking of -maltivec rather than -faltivec. I'm sure there's a way
to make this work, since the OS does this all over the place.
What is -maltivec? When I check the 'Enable Altivec Extensions' option
under C/C++ compiler options, it adds the -faltivec flag. As I
understood it, that causes the Altivec unit state to be saved on the
stack on function calls whether you use the Altivec unit in the
function or not, and those instructions are illegal on a G3. The way
around that was to have a module compiled for any processor dynamically
load the Altivec or non-Altivec code at run time. Using a factory
class that instantiated the right version and adding the -faltivec flag
on a per-file basis to only the Altivec specific classes might work as
well, as long as there was no alignment or stack mismatches in calling
between the optimized and non-optimized code.
On Mar 2, 2006, at 12:35 AM, Shaun Wexler wrote:
You could use a class cluster. Place all unoptimized C methods (ie
non-unrolled, processor-agnostic) in your "abstract" base class, then
create subclasses for each optimized CPU type and cacheline size.
This allows a fallback path, as well as being helpful for profiling
your optimization by allowing you to switch it on/off.
MyPlugIn::initDSPEngine()
{
switch (getCPUType()) {
case CPU_G3:
dspEngine = new DSPEngineG3; // fp,32
break;
case CPU_G4:
dspEngine = new DSPEngineG4; // AltiVec,32
break;
case CPU_G5:
dspEngine = new DSPEngineG5; // AltiVec,128
break;
case CPU_Intel:
dspEngine = new DSPEngineIntel; // SSE3,64
break;
default:
dspEngine = new DSPEngine; // base class
}
dspEngine->initWithPlugIn(this);
}
Is this implemented in one target by adding the processor specific
options on a per file basis to the processor specific classes or do you
have to build them separately and load them from libraries at run time?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden