Porting Squeak?
John M McIntosh
johnmci at smalltalkconsulting.com
Sat Mar 27 04:26:24 UTC 2004
On Mar 26, 2004, at 6:44 PM, vze26m98 wrote:
>> Building a custom configuration of VM is pretty simple from the
>> VMMaker end but you'll need to get very friendly with your
>> platforms's make and compiler. Being on good terms with a
>> debugger is useful as well.
>
> VMMAkerTool produced an "interp.c" that seems to compile very easily. I
> get a bunch of Warnings on functions that are declared as "int," but do
> not return a value. Not sure whether this is an issue yet or not.
>
> . . . . . . .
Ignore that, I've a change set that fixes that, but that then exposes
issues with the
VM api where routines say they return int in the headers, but they
return void.
>
> I've been trying to compile MacMinimal.c, as a simple wrapper to base
> my
> work on, and am getting a few (16) errors because functions are being
> redeclared, sometimes as many as three times. Here's the source tree:
>
>
> sqConfig.h _________
> (2001/12/18) |
> |_ sq.h
> | (2003/12/02)__________
> sqVirtualMachine.h__| |
> (2002/5/5) |
> |
> filePlugIn.h__________|__macMinimal.c
> (2002/1/29) | (2002/8/6)
> |
> |
> sqPlatformSpecific.h__|
> (2003/6/6)
>
> So it seems that, for example, a function like ioMsecs() is being
> defined in sq.h and sqPlatformSpecific.h as well macMinimal.c. Is there
> any strategy you could suggest for resolving these declarations? Should
> I use the most recent definition? The most Mac specific? Any
> suggestions
> would be appreciated!
I'd have to look, but I think the macMinimal.c hasn't been compiled in
many many years
perhaps 8 or more... Also the routines aren't current and should be
cross-check with
the current version. An example follows at the end of the message
The clocks
int ioMSecs(void); //A millisecond clock
int ioLowResMSecs(void); //A low res cheap clock
int ioMicroMSecs(void); //A very accurate millisecond clock.
All the defines you see allow the platform specific code to override
the default. Typically I see 1 clock call a millisecond, others
say more. From a historical viewpoint thump the clock 100 times a
second did make a difference, say what if your high res clock was
a slow to access clock chip somewhere.
On os-x ioLowResMSecs gets millisecond data from a pthread that updates
every 16ms. This does make a difference
in performance. On os-x the ioMSec and ioMicroMSecs resolve to the same
thing, a hardware cpu counter that is nano-second
accurate, that gets turned into a millisecond value...
I of course would delighted if you get the macMinimal.c to compile,
please email for solutions to issues you find.
Note the new
int ioSeconds(void) {
#if defined ( __APPLE__ ) && defined ( __MACH__ )
time_t unixTime;
// THE CORRECT TIME IN UNIX
unixTime = time(0);
unixTime += localtime(&unixTime)->tm_gmtoff;
/* Squeak epoch is Jan 1, 1901. Unix epoch is Jan 1, 1970: 17 leap
years
and 52 non-leap years later than Squeak. */
return unixTime + ((52*365UL + 17*366UL) * 24*60*60UL);
#else
struct tm timeRec;
time_t time1904, timeNow;
//THE UNIX CODE FOR CODE WARRIOR, PRODUCES THE WRONG TIME ZONE
CORRECTIONS IN EUROPE ON BSD/OS-X
/* start of ANSI epoch is midnight of Jan 1, 1904 */
timeRec.tm_sec = 0;
timeRec.tm_min = 0;
timeRec.tm_hour = 0;
timeRec.tm_mday = 1;
timeRec.tm_mon = 0;
timeRec.tm_year = 4;
timeRec.tm_wday = 0;
timeRec.tm_yday = 0;
timeRec.tm_isdst = 0;
time1904 = mktime(&timeRec);
timeNow = time(NULL);
/* Squeak epoch is Jan 1, 1901, 3 non-leap years earlier than ANSI one
*/
return (timeNow - time1904) + (3 * 365 * 24 * 60 * 60);
#endif
}
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Squeak-dev
mailing list
|