Fix scons build on Windows about python-on-a-chip

[GoogleCodeExporter]

Expand the definition of this ticket to include all the VM changes needed for 
Tyler 
to add his port to windows (from emails 04/22, 04/23):

- Updated the SCons build to work on Windows. Note there are two small
changes needed to the src/vm/SConstruct file:

Change 1:

img_sources = env.Command(["pmstdlib_img.c", "pmstdlib_nat.c"],
[PMSTDLIB_SOURCES],
   "%s src/tools/pmImgCreator.py -c -s -o src/vm/pmstdlib_img.c" \
   " --native-file=src/vm/pmstdlib_nat.c $SOURCES" %
(sys.executable))

Note that I need to explicitly use the path to the Python exe to use,
since we cannot use the #!/usr/bin/python bash trick. This should also
work on Linux - at least it works under cygwin.

Change 2:
if sys.platform != "win32":
    env['ARFLAGS'] = "rcs"

lib = env.Library("pmvm_%s" % vars.args["PLATFORM"], SOURCES +
img_sources)

Note that the MS 'librarian' does not understand the 'rcs' flags, so
we only add those in the non-Windows case.


- I changed the timer from a standard Windows timer to a Windows
'multi-media' timer. This obviates the need to have the message queue
called all the time. thus it also does not need the custom plat_tick
function that was added.


- I created a stdint.h and placed it in the src\platform\windows
folder. This allows us to use the core vm source unchanged. Though I
suspect this could cause issues doen the road with mingw or some other
compiler.

- I used the pmfeatures.h to place some compiler-specific defines,
also to eliminate the need to change any of the core source files.
Fortunately, Dean uses a model where all code includes pm.h, which
then includes pmfeatures.h - this reall simplifies things.

==================================

Sorry, there is one more small change needed to the core source code
to make it compatible with the Microsoft C/C++ compiler. The MS
compiler does not fully support the C99 standard, and so some features
that are accepted with GCC are not accepted my MSC.

The only issue I have found thus far is in interp.c, line 707, when
__DEBUG__ is set: the paddr variable is declared after executable
statements in the case block. It adds a few lines, but this is what I
did:

           case RETURN_VALUE:
               {
#if __DEBUG__
               uint8_t const *paddr = 0;
#endif
               /* Get expiring frame's TOS */
               pobj2 = PM_POP();

#if __DEBUG__
               /* #109: Check that stack should now be empty */
               /* Get the number of local variables for this code obj
*/
               paddr = FP->fo_func->f_co->co_codeimgaddr
                   + CI_STACKSIZE_FIELD + 1;
               t8 = mem_getByte(FP->fo_func->f_co->co_memspace,
&paddr);

               /* SP should point to one past the end of the locals
*/
/*                C_ASSERT(SP == &(FP->fo_locals[t8]));*/
#endif
     ...
     }

Note the two changes:

1. Adding braces to make a local block scope.
2. Moving the paddr declaration to the beginning of the block.

Also note that if you wish, the '-Wdeclaration-after-statement' flag
can be added to the GCC build, and it will error if this usage occurs
again. I tested this with the cygwin desktop build, and it finds the
issue.

I know you wanted to keep the number of changes to support Windows at
a minimum, and this is quite inconvenient to work around a 'broken'
compiler, but I still (currently) think it is worthwhile.

Original comment by [email protected] on 17 May 2009 at 9:51

[GoogleCodeExporter]

Made changes listed above as well as those in the README of the 
windows_08_a.zip file 
that Tyler posted in the python-on-a-chip files section.

No new tests.  make check passes.

Mainlined directly, see r365

Original comment by [email protected] on 18 May 2009 at 8:09

• Changed state: Started

[GoogleCodeExporter]

Don't know why this wasn't marked "Fixed" back in May.

Original comment by [email protected] on 25 Feb 2010 at 9:35

• Changed state: Fixed
• Added labels: Milestone-r10

[GoogleCodeExporter]

Changing Milestone-r10 to Milestone-r09

Original comment by [email protected] on 7 Mar 2010 at 6:26

• Added labels: Milestone-r09

[GoogleCodeExporter]

Changed r09 to R09

Original comment by [email protected] on 12 Mar 2010 at 8:22

[GoogleCodeExporter]

Original comment by [email protected] on 13 Mar 2010 at 1:30

• Added labels: Milestone-09