|
From: Nicholas N. <nj...@ca...> - 2004-03-04 10:05:43
|
On Thu, 4 Mar 2004, Paul Mackerras wrote: > > But the "IrKnowledge" and "IrOpinions" pages show some of our > > current thinking; they are a distillation of several failed > > half-attempts to come up with a concrete design. > > Interesting. If we allow skins to extend the ucode then we will > inevitably have architecture-specific code in the skins. We could > import the ucode extensions from memcheck into the core and then not > allow skins to extend the ucode. That shouldn't be too bad since > skins can always use CCALL to do any funky stuff they need to do. > Memcheck is a bit of a special case since it is the "primary" skin and > because it is important that the valid bit computations are reasonably > fast. For that reason I wouldn't like to see all the tag computations > done as CCALLs. Some of them could be done with ordinary ucode > instructions (e.g. AND, OR) but some of them couldn't be done easily > and efficiently that way (e.g. Tag_PCast40). Our idea was to have a platform-independent language that skins in which skins would write their instrumentation. It would presumably look a lot like UCode. As for skin-specific UInstrs, we thought ditching them would be ok; Memcheck is the only one that uses them, and they're not really necessary -- even Tag_PCast40 is just a NEG, SBB, OR which is currently expressible in UCode. We could have a special instruction in this instrumentation language with which a skin can create any (arch-specific) instruction it wants by just specifying the naked bytes, so skins could generate any instruction if they really wanted (ie. make the common case easy, and the uncommon case possible). SIMD instructions and registers are a big complication. It seems that programs will increasingly use them in ways that normal integer registers are currently used, which will require having a sensible way to instrument them. > > So I'm personally not convinced the approach you've taken is the right > > way to go -- it might be acceptable for two architectures, but what > > happens when someone wants a SPARC port, or an ARM port, etc? > > Obviously there must be some architecture-specific bits (eg. asm > > disassembly and code-regeneration), but keeping those bits separate from > > the skins seems, to me, crucial. > > I agree that that is the direction to head. Valgrind is such a useful > tool though that I want to have something that is usable on PPC now, > without having to wait until we have worked out the exact right way to > do things. :) No problem -- I'm sure other PowerPC users will be happy you've done so :) And you've done a massively helpful thing by concretely identifying the x86-specific parts of Valgrind. > Good idea. I have put it at > > http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2 > > This includes a fixes for a couple of bugs I found last night. Thanks. I've linked to this from valgrind.kde.org. Keep updating it if you make improvements (and the patch, too). Paul, are you subscribed to valgrind-developers? N |