Regarding this partly description of the fxp file format ( http://www.foxpert.com/docs/fxp.en.htm ), compiled foxpro code isn't assembler. That is also true for scx or vcx, there the fxp is just not a seperate file, it's just in the scx/vcx memo field for objectcode. So it's neither 32 bit or 64 bit, it's some kind of byte code like java and it is interpreted from the foxpro runtime, which is why vfp behaves much like an interpreter language.

The thing about a 64 bit version of vfp would change much, 32 bit code can profit from 64 bit cpus without any change. You could also have bigint or higher precision floating point in 32bit code, it would just need to do some things in several steps that a 64 bit cpu can do in one step.

So the answer is you can't put vfp compile output through some 32bit to 64bit code converter or optimizer. You would have to do that with the runtime and then it would still lack from the optimizations a linker/compiler/assembler could do to vfp code if vfp really was a compiler language. But as the vfp code would still remain byte code, the conversion of the runtime to 64 bit would not change much in execution performance.

That is why the .net compiler for vfp is going the right route, to precompile vfp into .net code and let .net compile that promises a better code optimization.

Besides that higher level languages are beyond the point where you would be able to determine a variable to be a cpu register. I last used that with Borland C on Atari ST.

Bye, Olaf.