Tim said:

'winCE' to appear in the list of options we would need for a winCE platform directory tree to be built since right now the menu is built from the subdirectories of /platforms. Files in common with win32 could be linked to, copied or simply referred to in the makefile

Adding a suitable WinCEVMMaker subclass is a good starting point and I suspect some other code would be needed. Yoshiki is almost certainly the Man For The Job.

Yes, Tim. It is what I have done and all works ok adding the WinCEVMMaker class by hand after seen how VMMaker is been instantiated... The effect of instantiating a VMMaker instance when I have only put the folder for WinCE, was that the new VMMaker instance created remove the files of directories without any notification and it was difficult to know what is happening because the instance created when opening is VMMaker tool was a Win32VMMaker... (I don´t know if you will understand,... the implicit change of the VMMaker to an instance of a more abstract class without notification is not what I expected to happen).

I have searched the web for months for a winCE porting using VMMaker, but not luck. I have built it now and I think that it is working with basic plugin support (B3D,File,JPEG,BMP,Deflate,Misc,Socket). Now I want to add FFI support, because it was what I need. When completed I plan to make it public; but if anyone is interested, I can send the project sources or put them where you think it is convenient to be found in the future. Now, there is some versiones of WinCE implementations but all made by hand and not included with the Win* platforms as required by people that want to start looking at it.

best, Ale.

----- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: Dean_Swan@Mitel.COM Cc: squeak-dev@lists.squeakfoundation.org Sent: Sunday, October 24, 2004 9:22 PM Subject: Re: Gcc dependencies in VMMaker

Dean said:-

...

Is there any easy way to get VMMaker to generate C code that doesn't include all the Gcc dependencies that the latest version does? I'm

trying

...

to build an updated 3.7 VM for WinCE (i.e. my iPaq 2210), and the

current

...

VMMaker output from 3.7-5989 Full makes MS VC++ quite cranky.

I'm puzzled - there's nothing at all that was deliberately put into VMMaker to support gcc. It should produce as vanilla C as we can manage, though I suspect it does tend a little towards C99 standard and one of my wannadoos is to try making use of the __inline__ pragma sometime soon.

WinCE support is likely to be a bit flaky since (to the best of my knowledge) no support for it has been put in either. Since I don't do any development work on either it relies on others submitting code and I simply don't seem to have any. So far as I can remember Yoshiki has done pretty much all the handling of winCE VMs.

Ale. said:-

...

One of the problem is related with instantiation of the VMMaker. The #default message returns an instance for building the image in the

host

...

platform. So, when you open the VMMaker with the menu, all is ok. But IF YOU CHANGE (by hand) the last editbox contents with title "path

to

...

generated sources", a new VMaker can be instantiated and provably if you named the directory for WinCE platform, the wrong instance will be

created

...

(aVMMaker instance).

The intent is that when you open a VMMakerTool UI the default of a VMMaker suitable for the platform you're running on is made. If you choose a different platform from the list ('Find platform') a new instance of the actual VMMaker is built to suit the chosen platform and the configuration copied over (just in case you had setup any plugin config etc). Changing the 'Path to generated sources' should most definitely not rebuild the VMMaker instance attached to the VMMakerTool. I've just tried this and that seems to be correctly working. Note that the name for the generated sources directory has nothing to do at all with the platform name or VMMaker subclass. For 'winCE' to appear in the list of options we would need for a winCE platform directory tree to be built since right now the menu is built from the subdirectories of /platforms. Files in common with win32 could be linked to, copied or simply referred to in the makefile

Adding a suitable WinCEVMMaker subclass is a good starting point and I suspect some other code would be needed. Yoshiki is almost certainly the Man For The Job.

tim

Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Any programming language is at its best before it is implemented and used.

Hi Tim, I will try to explain the problems I have had. :-)

I want to do a port to WinCE capable to have Win32 and WinCE builds in the same machine. There are shared files between Win32 and WinCE builds.

0.- Running in a clean Squeak3.7.1 image (with VMMaker) under windoz... 1.- I created a new folder named WinCE (at the same level of Win32) and copy the files there with the same tree of win32. 2.- I have opened the VMMaker tool (a Win32VMMaker was instantiated because I was running Squeak in a win* machine) 3.- In the pathToPlatforms code i have placed the same directory as usual. 4.- I pressed the "findPlatform" button and select the WinCE option. 5.- The box with title "Path to generated sources" does NOT change to winCE and remain pointing to win32!!! 6.- so I decided to change(edit) the pane contents and change path to existing wince directory. 7.- when running the vm generation without any plugin, I've found that some files has been deleted (don't know which files, but I don't want to try it now :-) 8.- I repeated the procedure restarting from 0 twice... 9.- Then I want to inspect what's going on...

I have found that when I change the last edit box by hand to winCE, whitout having the WinCEVMMaker subclass defined, a new instance of VMMaker is created!!! Yes, when you open the tool a Win32VMMaker is created (using #default message, and it is ok for Andreas folders shape, and does NOT remove files), but when you change the platform name, the #default message looks for a class named WinCEVMMaker... and when not found... DEFAULTS TO VMMaker! The new instance of VMMaker delete your files without confirmation (as wanted if you are on unix).

The main problem as I saw was the implementation of the stategy for #default (and use of subclasification in this case) but found that it is easy to solve my problem creating WinCEVMMaker as a subclass of Win32VMMaker to follow the win* rules of building.

Please verify the convenience of creating instances of VMMaker (I think that it is not good) and locating behavior for unix on a concrete class, making VMMaker abstract and defining the main rules, but not instantiable... Or making a simple preferences model of VMMaker for known platforms (using configuration instead of subclassification for the little changes of each build preferences).

cheers, Ale.

----- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Sent: Monday, October 25, 2004 4:07 AM Subject: Re: Gcc dependencies in VMMaker

"Alejandro F. Reimondo" aleReimondo@smalltalking.net wrote:

Yes, Tim. It is what I have done and all works ok adding the WinCEVMMaker class by hand after seen how VMMaker is been instantiated...

OK, so you have directory platforms/winCE and a class WinCEVMMaker, which means a) wince should appear in your menu of chioces for the platform (sounds like it works) b) `VMMaker forPlatform: 'winCE'` should result in an instance of WinCEVMMaker with no plugins configured. Sounds like that bit works too.

The effect of instantiating a VMMaker instance when I have only put the folder for WinCE, was that the new VMMaker instance created remove the files of directories without any notification

What? This absolutely shouldn't happen. The only likely cause of file deletion I can see is

a) the method #deleteUnwantedExternalPluginDirectories which is there to make sure that no longer wanted plugins are removed and the makefile will not try to build them. It is only sent by #generateExternalPlugins though, and no way should it happen just from changing the platform name.

b) #deleteEntireGeneratedTree which is used only when you press the 'clean out' button. That is intended to remove all the generated files.

and it was difficult to know what is happening because the instance created when opening is VMMaker tool was a Win32VMMaker... (I don´t know if you will understand,... the implicit change of the VMMaker to an instance of a more abstract class without notification is not what I expected to happen).

When you start the tool it makes an instance of a subclass of VMMaker matched to your platform. So, if you're running on Win32 you'll get a Win32VMMaker as the default. Similarly on unix you get a UnixVMMaker.

Now an important difference between the Win32VMMaker and all the others is that, for whatever reason, Andreas wanted to have the >generated< code placed in the >same< directories as the hand-written platform code. Take a look at the methods #sourceDirectory, pluginsDirectory etc in Win32VMMaker and compare to the other versions. An interesting extra point is that becasue of that the two #delete... methods mentioned above are null and don't actually delete files! By making WinCEVMMaker a subclass of Win32VMMaker you are inheriting these issues and that may be part of the problem.

I've just tried adding a wince platform directory (the menu now has wince as well as the others) and your changeset. I open a VMMakerTool and set the platform to wince - the 'path to generated sources' changes to platforms/wince as expected and no files get deleted or anything like that. It generates what looks like a reasonable set of files; I can't test since I don't have wince tools.

Perhaps if you can explain the file tree you have, _exactly_ how yo used the tool and which files were deleted it might help me visualise the problem. Right now I'm completely baffled.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Money can't buy love. But it CAN rent a very close imitation.

Hi Andreas, all, I have found the current implementation of FFI a little complex, but I think that it is related with some perfomance needs. Trying to make a build under WinCE I have found that currently a piece of assembler code must be implemented for each platform&processor... Please confirm me if it is really required, or if someone knows any standard C code to put for ffiCallAddress: implementation (or any higher level function). I think that it will be hard for me to port the asm code to my winCE host processor (ARM4). I can try to make the effort, but think that we will really need a 100% standard C level compatibility for FFI (as we have in very first versions). The current assembler code implemented for win32 platform follows this email. Thanks for your time! Ale.

/*************************************************************************** **/ /*************************************************************************** **/ int oldSP; int oldBP; int newSP; int newBP;

/* ffiCallAddress: Perform the actual function call. */ int ffiCallAddress(int fn) { #if 0 { FILE *f = fopen("ffi.log","at"); fprintf(f, "%x",fn); fflush(f); fclose(f); } #endif #ifdef _MSC_VER __asm { push ebx mov ebx, fn push ecx push edx push edi push esi push ebp /* mark the frame */ mov ebp, esp /* alloca() ffiStackIndex size bytes */ mov ecx, ffiArgIndex shl ecx, 2 sub esp, ecx /* copy stack */ mov edi, esp lea esi, ffiArgs shr ecx, 2 cld rep movsd /* go calling */ call ebx /* restore frame */ mov esp, ebp /* store the return values */ mov intReturnValue, eax mov intReturnValue2, edx fstp floatReturnValue /* restore register values */ pop ebp pop esi pop edi pop edx pop ecx pop ebx /* done */ } #endif #ifdef __GNUC__ asm(" movl %%ebp, _oldBP movl %%esp, _oldSP pushl %%ebx; pushl %%ecx; pushl %%edx; pushl %%edi; pushl %%esi; pushl %%ebp; /* mark the frame */ movl %%esp, %%ebp /* alloca() ffiStackIndex size bytes */ movl _ffiArgIndex, %%ecx; shll $2, %%ecx; subl %%ecx, %%esp /* copy stack */ movl %%esp, %%edi; leal _ffiArgs, %%esi; shrl $2, %%ecx; cld; rep movsl; /* go calling */ call *%%ebx /* restore frame */ movl %%ebp, %%esp /* store the return values */ movl %%eax, _intReturnValue movl %%edx, _intReturnValue2 fstpl _floatReturnValue /* restore register values */ popl %%ebp popl %%esi popl %%edi popl %%edx popl %%ecx popl %%ebx movl %%ebp, _newBP movl %%esp, _newSP ": /* no outputs */ : "ebx" (fn) : "eax" /* clobbered registers */); /* done */ #endif #if 0 { FILE *f = fopen("ffi.log","at"); fprintf(f, "...ok\n"); if(oldBP != newBP || oldSP != newSP) { fprintf(f,"oldSP=%x, oldBP=%x\nnewSP=%x, newBP=%x\n",oldSP, oldBP,newSP,newBP); } fprintf(f,"SP=%x, BP=%x\n",newSP,newBP); fflush(f); fclose(f); } #endif return intReturnValue; }

int ffiCallAddressOfWithPointerReturn(int fn, int callType) { return ffiCallAddress(fn); } int ffiCallAddressOfWithStructReturn(int fn, int callType, int* structSpec, int specSize) { return ffiCallAddress(fn); }

int ffiCallAddressOfWithReturnType(int fn, int callType, int typeSpec) { return ffiCallAddress(fn); }

"Alejandro F. Reimondo" aleReimondo@smalltalking.net wrote:

Hi Tim, I will try to explain the problems I have had. :-)

[snip]

4.- I pressed the "findPlatform" button and select the WinCE option. 5.- The box with title "Path to generated sources" does NOT change to winCE and remain pointing to win32!!!

This is certainly a bit of a surprise and I'l see if I can fix it. What is happening here depends upon not having a VMMaker subclass for wince installed.

6.- so I decided to change(edit) the pane contents and change path to existing wince directory. 7.- when running the vm generation without any plugin, I've found that some files has been deleted (don't know which files, but I don't want to try it now :-)

Yup - the 'normal' behaviour when generating the external plugins is to delete any directories for which we are not going to make code, to avoid stale code confusing the makefile on unix. With the confused setup caused by no WinCEVMMaker class we can get to deleting all the code... not very good.

8.- I repeated the procedure restarting from 0 twice... 9.- Then I want to inspect what's going on...

I have found that when I change the last edit box by hand to winCE, whitout having the WinCEVMMaker subclass defined, a new instance of VMMaker is created!!!

Absolutely. The default is always a plain VMMaker _unless_ a suitable subclass is found when choosing the platform. A plain VMMaker is (should be) perfectly able to build a VM.

With a WinCEVMMaker subclass installed it should all be ok. I'll see what I can do to make it a bit safer anyway.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Hex dump: Where witches put used curses...