From: Sascha H. <sa...@xm...> - 2009-12-16 17:04:41
|
On Wed, Dec 16, 2009 at 4:44 PM, Arno Puder <ar...@pu...> wrote: > > > On 12/16/09 4:19 PM, Gergely Kis wrote: > > Actually XMLVM already makes a distinction in the code between the > > different types, because you generate the following code: > > _st[_sp++].i - for integers > > _st[_sp++].d - for double > > ... etc. > > The only problem is that in C, you cannot inspect at runtime what is > > stored in a union. > > One idea would be to make a small change in XMLVMElem to also allow the > > storage of the type that was stored in it, and change the generated code > > to something like this: > > > > _st[_sp++].type = 'i'; _st[_sp].i = ...; > > The JVM usually only allocated 32-bits per stack element to save space. > sizeof(XMLVMElem) is 64 bits, that is the core of the problem. Keeping > type information at runtime or doing an offline data flow analysis would > be solutions to this problem. However, both are pretty complex and since > we plan to switch to a register-based machine in the near, mid-term > future it would be unnecessary work. As I pointed out in my previous > post, there is an easy way to avoid the pop2 instruction. > > > Do you have more information regarding the register machine conversion > > that you are doing? Do you have a timeframe? Will it change the > > interface between the hand-written objc code and the generated code? > > Do you use the DEX model which I mentioned earlier, or are you inventing > > something else? > > We make use of the DEX compiler. As a matter of fact, you can already > see dx.jar in our repository and a DEX output process. Sascha is working > on this so I let him talk about timeframe. :-) > > The very important fact is that the name-mangling *will not* change, so > the hand-written code will not need to be changed. > So I think I am quite far already on creating the register-based XML and the next big steps are creating the stylesheets for converting it to code. I plan to start with JavaScript, because speed is more of an issue here than with Objective-C. I will work heavily on this throughout the next 2-3 weeks so expect a lot progress on this. I will update the mailing list as soon as something is actually usable and finished. And as Arno already pointed out, the class structure and method names won't change, so no worries here. // Sascha > Arno > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |