[Vm-dev] [commit][3348] CogVM source as per VMMaker.oscog-eem.1311

[Eliot Miranda]

Hi David,

On Sun, May 17, 2015 at 8:03 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Mon, May 18, 2015 at 01:46:36AM +0200, Levente Uzonyi wrote:
> >
> > On Sun, 17 May 2015, commits at squeakvm.org wrote:
> >
> > >
> > >Revision: 3348
> > >Author:   eliot
> > >Date:     2015-05-17 16:03:01 -0700 (Sun, 17 May 2015)
> > >Log Message:
> > >-----------
> > >CogVM source as per VMMaker.oscog-eem.1311
> > >
> > >General:
> > >Make the bounds check in primitiveObject:perform:...
> > >more restrictive and fix bugs in the commentary.
> > >
> > >Make stack pages a reasonable size.  My math was
> > >wrong and the size was half as big as intended.
> > >
> > >Extend the fastPrimTrace scheme to trace stack overflow, prim failure
> and
> > >prim
> > >retry to help debug the phantom stack frame bug in Cog Spur.
> > >
> > >Cogit:
> > >Revamp icache flushing in the Cogit for ARM.  Move icache flush for
> > >generated
> > >methods/pics to the fillIn*Header: routines.  Make sure the cache is
> > >flushed
> > >in generateCaptureCStackPointers:.  Flush the entire PIC when extending
> it.
> > >
> > >Spur:
> > >Fix ceActivateFailingPrimitiveMethod: to return properly after retrying
> > >a primitive after checkForAndFollowForwardedPrimitiveState. e.g. fixes
> > > | s | 1 to: 5 do: [:i| s := 'bar'. s becomeForward: 'bzzt' copy. 'foo'
> <=
> > > s]
> > >
> > >Fix bug in followForwardedFrameContents:stackPointer: so that arguments
> are
> > >actually followed.  N.B. drives the above bug underground ;-).
> > >so that named constants (defines) are not elided.
> > >
> > >Newspeak:
> > >Remove landmine left from restructing implicit receiver and outer sends
> as
> > >clean sends.
> > >
> > >Slang:
> > >Fix constant elimination on arithmetic generation.
> > >
> > >Plugins:
> > >Regenerated because of changes in accessorDepth calculation,
> > >constant elimination, and read-before-use initialization.
> >
> > My compiler is unhappy about assigning integers to various structs. I
> > guess a few type declarations are missing. See below.
> >
>
> This looks like a change to the code generator, possibly to force
> initialization of variables. The variable declarations are in the
> Smalltalk source for OSProcessPlugin. There is no explicit assignment
> of zero to those structure variables in OSPP. I am guessing this was
> added to the C code generator (slang). Maybe that is not a good thing
> to do.
>

But in CogVM source as per VMMaker.oscog-eem.1313

Make accessor depth calculation more accurate by not considering
fetchInteger:ofObject: and arraySize: et al as object accessors.

Make the read-before-written initializer safer, only initialzing simple
types.


The point is that Smalltalk initializes all temporaries to nil, so for
faithful translation Slang should initialize those variables
read-before-written with 0.  But there is plugin code for which a naive
approach won't work.  Still, the changes made to Slang have settled down
and no longer is Slang generating erroneous initializations.  So, IMO, this
/is/ a good idea, it just needed polishing.


>
> Dave
>
>
>
> > >Modified:
> > >branches/Cog/nsspursrc/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c
> > >===================================================================
> > >---
> > >branches/Cog/nsspursrc/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c
> > >2015-05-17 20:13:47 UTC (rev 3347)
> > >+++
> > >branches/Cog/nsspursrc/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c
> > >2015-05-17 23:03:01 UTC (rev 3348)
> > >@@ -1,5 +1,5 @@
> > >/* Automatically generated by
> > >-    VMPluginCodeGenerator VMMaker.oscog-eem.1113 uuid:
> > >9b08eea7-d3db-440f-ba64-16abc799fcf8
> > >+    VMPluginCodeGenerator VMMaker.oscog-eem.1311 uuid:
> > >61f8144b-089d-4ca4-9e81-4ccfa6de0fc3
> > >   from
> > >     UnixOSProcessPlugin
> > >     VMConstruction-Plugins-OSProcessPlugin.oscog-eem.50 uuid:
> > >     67b1e805-4efd-476c-8cf3-b4a5e14e22a9
> > > */
> > >@@ -1221,6 +1221,7 @@
> > >    sqInt SigStackSize;
> > >    stack_t sigstack;
> > >
> > >+    sigstack = 0;
> >
> > sigstack is of type stack_t
> >
> > >     if (useSignalStack >= 0) {
> > >             return useSignalStack != 0;
> > >     }
> > >@@ -1456,6 +1457,8 @@
> > >    FILEHANDLETYPE *writerIOStreamPtr;
> > >    SQFile *writerPtr;
> > >
> > >+    readerIOStream = 0;
> > >+    writerIOStream = 0;
> > >
> > >     /* Create the anonymous OS pipe */
> > >
> > >@@ -1517,6 +1520,8 @@
> > >    FILEHANDLETYPE *writerIOStreamPtr;
> > >    SQFile *writerPtr;
> > >
> > >+    readerIOStream = 0;
> > >+    writerIOStream = 0;
> > >
> > >     /* Create the anonymous OS pipe */
> > >
> > >@@ -1945,6 +1950,7 @@
> > >    sqInt semaphoreIndex;
> > >    sqInt sigNum;
> > >
> > >+    semaphoreIndex = 0;
> > >     index = stackValue(0);
> > >     if (index == (nilObject())) {
> > >             semaphoreIndex = 0;
> > >@@ -2440,6 +2446,8 @@
> > >    FILEHANDLETYPE *writerIOStreamPtr;
> > >    SQFile *writerPtr;
> > >
> > >+    readerIOStream = 0;
> > >+    writerIOStream = 0;
> > >
> > >     /* Create the anonymous OS pipe */
> > >
> > >@@ -2502,6 +2510,8 @@
> > >    FILEHANDLETYPE *writerIOStreamPtr;
> > >    SQFile *writerPtr;
> > >
> > >+    readerIOStream = 0;
> > >+    writerIOStream = 0;
> > >
> > >     /* Create the anonymous OS pipe */
> > >
> > >@@ -4147,6 +4157,7 @@
> > >{
> > >    struct sigaction sigchldHandlerAction;
> > >
> > >+    sigchldHandlerAction = 0;
> > >
> > >#  if defined(SA_NOCLDSTOP)
> > >     sigchldHandlerAction.sa_sigaction = reapChildProcess;
> > >@@ -4192,6 +4203,8 @@
> > >    struct sigaction oldHandlerAction;
> > >    struct sigaction sigHandlerAction;
> > >
> > >+    oldHandlerAction = 0;
> > >+    sigHandlerAction = 0;
> >
> > The above two have the type struct sigaction.
> >
> >
> > Levente
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150517/0d27ca66/attachment.htm