VMMaker-sig.70
Exupery-sig.262 - removed numerous xxxxAddress methods from Interpreter, ExuperyPlugin, MachineX86. - added 4 new methods to Interpreter: exuperyPrimitiveGlobalPtrCount -- returns number of pointers stored in table exuperyPrimitiveGlobalPtrByName -- by giving a name of pointer (string or symbol) returns an array (pointer name proto) , or nil if not found exuperyPrimitiveGlobalPtrByIndex -- same as above but uses index as parameter exuperyGetGlobalPtrInfo: -- helper function to generate Array (pointer name proto) To see all VM global pointers use Exupery vmGlobalPtrs will return dictionary name -> info. where info is array of 4 elements: - pointer value - name - prototype for functions or '<var>' for variables a function prototype can be useful to see argument types and names e.t.c., so, it can be parsed in smalltalk to generate a cdecl callout to it. - index in global table ( left for later use , when i add support for replacing pointer in table :) ) also, note, the function names are stored as smalltalk selectors, not their corresponding C equivalents. so, you have names like 'commonVariableInternal:at:cacheIndex:' instead of 'commonVariableInternalatcacheIndex' in table so its easier to get to its implementation in Interpreter class. To see, how globals table generated look at CCodeGenerator>>emitGlobalTablesOn:methodList: i'm using struct instead of array, to preserve function names and type info. so later i can substitute calls like: foo(bar) with VMPointers->foo(bar) and then be able to replace given function with anything i want. All tests is passed fine except 3 cases, simply because i don't have following classes in image: GraphVizBaseTests CommandShell FloatMathPluginTests i don't think something will change if they will be. :) _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
sig writes:
> VMMaker-sig.70 > Exupery-sig.262 > > To see, how globals table generated look at > CCodeGenerator>>emitGlobalTablesOn:methodList: Unfortunately as it stands it will only work on Windows. The major problem is the "foo" structure on other platforms that's used to hold most of the interpreter's variables. That's why the accessor methods used to call addressOf: rather than just being "self cCode: '&foo->activeContext'" which is what I originally did until Andreas tried to do a quick Windows port. He created addressOf: to provide a platform neutral way of getting the address of an interpreter structure. #returnPrefixFromVariable: will return the right form for a variable on any platform. Unfortunately, you can't dereference foo in another structure's initialiser. Andreas created #generateAddressOf:on:indent: to translate the sender #addressOf: into the appropriate C expression. I'm not sure about your change to Win32VMMaker>>sourceDirectory. If I add that to Exupery's VMMaker what will it do to people with existing Windows build environments? I like the changes to Exupery itself, it makes the names much more consistant between the image and the VM but until it will run on all plaforms I can not accept it. Bryce _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
On 14/07/07, [hidden email] <[hidden email]> wrote:
> sig writes: > > VMMaker-sig.70 > > Exupery-sig.262 > > > > To see, how globals table generated look at > > CCodeGenerator>>emitGlobalTablesOn:methodList: > > Unfortunately as it stands it will only work on Windows. > > The major problem is the "foo" structure on other platforms that's > used to hold most of the interpreter's variables. > > That's why the accessor methods used to call addressOf: rather than > just being "self cCode: '&foo->activeContext'" which is what I > originally did until Andreas tried to do a quick Windows port. He > created addressOf: to provide a platform neutral way of getting the > address of an interpreter structure. > > #returnPrefixFromVariable: will return the right form for a variable > on any platform. Unfortunately, you can't dereference foo in another > structure's initialiser. > > Andreas created #generateAddressOf:on:indent: to translate > the sender #addressOf: into the appropriate C expression. > > > I'm not sure about your change to Win32VMMaker>>sourceDirectory. > If I add that to Exupery's VMMaker what will it do to people with > existing Windows build environments? Ah.. its better to remove this method. i just left it to call super. Originally (w/o my change) you are unable to change target dir, and i found this annoying. And.. i don't know how other people build squeak in windows, but all my tries to build it from freshly unpacked gnutools and vm sources failed. Only after i did some changes in make files i did manage to build squeak from freshly generated source tree. Btw, i can provide my makefiles if someone interested. > > > I like the changes to Exupery itself, it makes the names much more > consistant between the image and the VM but until it will run on > all plaforms I can not accept it. > > Bryce > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Bryce Kampjes
Concerning foo struct, as we discussed on IRC:
-first, i'll try to see how fast i can modify Win32 source to use foo struct. If this is easy task, then i'll do this, and then we'll have to deal with foo struct for all platforms. And then i will make use of foo for getting pointers. _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Ok, i made some changes to make VMPointers work with foo struct.
Since foo always pointing to fum, there's no harm by initializing pointer to var 'bar' as '&fum.bar', which compiles perfectly :) Until people deciding using foo struct in windows or not, i left an option there - if you don't want to use it, simply don't accept Win32VMMaker>>createCodeGenerator method. If you do, then don't forget to copy patched platform source code, which you can find on mantis http://bugs.squeak.org/view.php?id=6561. Code works in both cases, so this does not really matter. Also, i made some changes, to be able generate code with indirect calls. I think you may be interested to play with. There is single method in TSendNode, and couple #emitFunctionCallFor: , #useIndirectCalls in CCodeGenerator. If you don't want them - simply do not accept these changes , or change 'true' to 'false' in CCodeGenerator>>useIndirectCalls ^ true and: [ self isGeneratingPluginCode not] A cool trick to test, is current code ready for using indirect calls everywhere in VM/plugins is to change generated function names by prepending them with '_'. I really don't care at current stage, how many places in VM/plugins will require changes, first, i need to finish with compiler integration for my asm-generator :) _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
sig writes:
> Ok, i made some changes to make VMPointers work with foo struct. > Since foo always pointing to fum, there's no harm by initializing > pointer to var 'bar' as '&fum.bar', which compiles perfectly :) I've got this building on Linux. I'll try to do a final review soon. Bryce _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Free forum by Nabble | Edit this page |