VM Maker: VMMaker.oscog-eem.2347.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

VM Maker: VMMaker.oscog-eem.2347.mcz

commits-2
 
Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz

==================== Summary ====================

Name: VMMaker.oscog-eem.2347
Author: eem
Time: 7 March 2018, 2:46:20.98144 pm
UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
Ancestors: VMMaker.oscog-akg.2346

Review of Alistair's recent FilePlugin changes:

Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.

With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
        bytesWritten := self
                                                sqFile: file
                                                Write: count * elementSize
                                                From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
                                                At: startIndex - 1 * elementSize.
instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:

In primitiveConnectToFile[Descriptor] you write

        interpreterProxy failed ifFalse:
                [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
                                                        thenPush: filePointer].
        ^interpreterProxy primitiveFail.

but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write

        interpreterProxy failed ifFalse:
                [interpreterProxy pop: 3 "rcvr, name, writeFlag"
                                                        thenPush: filePointer]

=============== Diff against VMMaker.oscog-akg.2346 ===============

Item was changed:
  ----- Method: FilePlugin>>connectToFd:write: (in category 'private') -----
  connectToFd: fd write: writeFlag
  "Connect to the supplied file descriptor. Answer the file oop.
  On POSIX platforms this translates to fdopen().
  writeFlag must be compatible with the existing file access."
  | file fileOop |
+ <var: 'file' type: #'SQFile *'>
+ <var: 'fd' type: #int>
- <var: #file type: 'SQFile *'>
- <var: 'fd' type: 'int'>
- <export: true>
  fileOop := interpreterProxy instantiateClass: interpreterProxy classByteArray indexableSize: self fileRecordSize.
  file := self fileValueOf: fileOop.
+ interpreterProxy failed ifFalse:
+ [self sqConnect: file ToFile: fd Descriptor: writeFlag].
+ ^fileOop!
- interpreterProxy failed
- ifFalse: [self cCode: 'sqConnectToFileDescriptor(file, fd, writeFlag)' inSmalltalk: [file]].
- ^ fileOop!

Item was changed:
  ----- Method: FilePlugin>>connectToFile:write: (in category 'private') -----
  connectToFile: cfile write: writeFlag
  "Open the FILE* as file. Answer the file oop.
  writeFlag must be compatible with the existing file access."
  | file fileOop |
+ <var: 'file' type: #'SQFile *'>
+ <var: 'cfile' type: #'void *'>
- <var: 'file' type: 'SQFile *'>
- <var: 'cfile' type: 'void *'>
- <export: true>
  fileOop := interpreterProxy instantiateClass: interpreterProxy classByteArray indexableSize: self fileRecordSize.
  file := self fileValueOf: fileOop.
+ interpreterProxy failed ifFalse:
+ [self sqConnect: file To: cfile File: writeFlag].
+ ^fileOop!
- interpreterProxy failed
- ifFalse: [self cCode: 'sqConnectToFile(file, cfile, writeFlag)' inSmalltalk: [file]].
- ^ fileOop!

Item was changed:
  ----- Method: FilePlugin>>primitiveConnectToFile (in category 'file primitives') -----
  primitiveConnectToFile
  "Connect to the file with the supplied FILE* and writeFlag.
  FILE* must be supplied in a byte object (ByteArray) with the platform address size.
  writeFlag must be a boolean and compatible with the existing file access."
  | writeFlag cfileOop cfile filePointer |
+ <var: 'cfile' type: #'void *'>
- <var: 'cfile' type: 'void* '>
  <export: true>
+ writeFlag := interpreterProxy booleanValueOf: (interpreterProxy stackValue: 0).
- writeFlag := interpreterProxy
- booleanValueOf: (interpreterProxy stackValue: 0).
  cfileOop := interpreterProxy stackValue: 1.
  cfile := self pointerFrom: cfileOop.
  cfile ifNil:
  [^interpreterProxy primitiveFailFor: PrimErrBadArgument].
  filePointer := self connectToFile: cfile write: writeFlag.
  interpreterProxy failed ifFalse:
+ [interpreterProxy pop: 3 "rcvr, name, writeFlag"
+ thenPush: filePointer]!
- [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
- thenPush: filePointer].
- ^interpreterProxy primitiveFail.!

Item was changed:
  ----- Method: FilePlugin>>primitiveConnectToFileDescriptor (in category 'file primitives') -----
  primitiveConnectToFileDescriptor
  "Connect to the existing file identified by fileDescriptor.
  fileDescriptor must be an integer.
  writeFlag is aboolean indicating whether to open in read or write mode and must be compatible with the existing file access."
  | writeFlag fdPointer fd filePointer |
+ <var: 'fd' type: #int>
- <var: 'fd' type: 'int'>
  <export: true>
  writeFlag := interpreterProxy
  booleanValueOf: (interpreterProxy stackValue: 0).
  fdPointer := interpreterProxy stackValue: 1.
  (interpreterProxy isIntegerObject: fdPointer)
  ifFalse: [^ interpreterProxy primitiveFailFor: PrimErrBadArgument].
  fd := interpreterProxy integerValueOf: fdPointer.
  filePointer := self connectToFd: fd write: writeFlag.
+ interpreterProxy failed ifFalse:
+ [interpreterProxy pop: 3 "rcvr, name, writeFlag"
+ thenPush: filePointer]!
- interpreterProxy failed
- ifFalse: [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
- thenPush: filePointer].
- ^interpreterProxy primitiveFail.!

Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Levente Uzonyi
 
On Wed, 7 Mar 2018, [hidden email] wrote:

>
> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>

snip

> Item was changed:
>  ----- Method: FilePlugin>>primitiveConnectToFile (in category 'file primitives') -----
>  primitiveConnectToFile
>   "Connect to the file with the supplied FILE* and writeFlag.
>   FILE* must be supplied in a byte object (ByteArray) with the platform address size.
>   writeFlag must be a boolean and compatible with the existing file access."
>   | writeFlag cfileOop cfile filePointer |
> + <var: 'cfile' type: #'void *'>
> - <var: 'cfile' type: 'void* '>
>   <export: true>
> + writeFlag := interpreterProxy booleanValueOf: (interpreterProxy stackValue: 0).
> - writeFlag := interpreterProxy
> - booleanValueOf: (interpreterProxy stackValue: 0).

It should be checked here if the primitive has failed or not, shouldn't
it?

>   cfileOop := interpreterProxy stackValue: 1.
>   cfile := self pointerFrom: cfileOop.
>   cfile ifNil:
>   [^interpreterProxy primitiveFailFor: PrimErrBadArgument].
>   filePointer := self connectToFile: cfile write: writeFlag.
>   interpreterProxy failed ifFalse:
> + [interpreterProxy pop: 3 "rcvr, name, writeFlag"
> + thenPush: filePointer]!
> - [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
> - thenPush: filePointer].
> - ^interpreterProxy primitiveFail.!
>
> Item was changed:
>  ----- Method: FilePlugin>>primitiveConnectToFileDescriptor (in category 'file primitives') -----
>  primitiveConnectToFileDescriptor
>   "Connect to the existing file identified by fileDescriptor.
>   fileDescriptor must be an integer.
>   writeFlag is aboolean indicating whether to open in read or write mode and must be compatible with the existing file access."
>   | writeFlag fdPointer fd filePointer |
> + <var: 'fd' type: #int>
> - <var: 'fd' type: 'int'>
>   <export: true>
>   writeFlag := interpreterProxy
>   booleanValueOf: (interpreterProxy stackValue: 0).

Same as above.

Levente

>   fdPointer := interpreterProxy stackValue: 1.
>   (interpreterProxy isIntegerObject: fdPointer)
>   ifFalse: [^ interpreterProxy primitiveFailFor: PrimErrBadArgument].
>   fd := interpreterProxy integerValueOf: fdPointer.
>   filePointer := self connectToFd: fd write: writeFlag.
> + interpreterProxy failed ifFalse:
> + [interpreterProxy pop: 3 "rcvr, name, writeFlag"
> + thenPush: filePointer]!
> - interpreterProxy failed
> - ifFalse: [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
> - thenPush: filePointer].
> - ^interpreterProxy primitiveFail.!
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Alistair Grant
In reply to this post by commits-2
 
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Alistair Grant
In reply to this post by Levente Uzonyi
 
Hi Levente,


On 8 March 2018 at 00:44, Levente Uzonyi <[hidden email]> wrote:

>
> On Wed, 7 Mar 2018, [hidden email] wrote:
>
>>
>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>>
>
> snip
>
>> Item was changed:
>>  ----- Method: FilePlugin>>primitiveConnectToFile (in category 'file
>> primitives') -----
>>  primitiveConnectToFile
>>         "Connect to the file with the supplied FILE* and writeFlag.
>>         FILE* must be supplied in a byte object (ByteArray) with the
>> platform address size.
>>         writeFlag must be a boolean and compatible with the existing file
>> access."
>>         | writeFlag cfileOop cfile filePointer |
>> +       <var: 'cfile' type: #'void *'>
>> -       <var: 'cfile' type: 'void* '>
>>         <export: true>
>> +       writeFlag := interpreterProxy booleanValueOf: (interpreterProxy
>> stackValue: 0).
>> -       writeFlag := interpreterProxy
>> -                               booleanValueOf: (interpreterProxy
>> stackValue: 0).
>
>
> It should be checked here if the primitive has failed or not, shouldn't it?

Yes.  I thought I'd taken care of this, but obviously not.


>>         cfileOop := interpreterProxy stackValue: 1.
>>         cfile := self pointerFrom: cfileOop.
>>         cfile ifNil:
>>                 [^interpreterProxy primitiveFailFor: PrimErrBadArgument].
>>         filePointer := self connectToFile: cfile write: writeFlag.
>>         interpreterProxy failed ifFalse: +              [interpreterProxy
>> pop: 3 "rcvr, name, writeFlag"
>> +                                                       thenPush:
>> filePointer]!
>> -               [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> -                                                       thenPush:
>> filePointer].
>> -       ^interpreterProxy primitiveFail.!
>>
>> Item was changed:
>>  ----- Method: FilePlugin>>primitiveConnectToFileDescriptor (in category
>> 'file primitives') -----
>>  primitiveConnectToFileDescriptor
>>         "Connect to the existing file identified by fileDescriptor.
>>         fileDescriptor must be an integer.
>>         writeFlag is aboolean indicating whether to open in read or write
>> mode and must be compatible with the existing file access."
>>         | writeFlag fdPointer fd filePointer |
>> +       <var: 'fd' type: #int>
>> -       <var: 'fd' type: 'int'>
>>         <export: true>
>>         writeFlag := interpreterProxy
>>                                 booleanValueOf: (interpreterProxy
>> stackValue: 0).
>
>
> Same as above.

I'll change both of these.


Thanks,
Alistair


> Levente
>
>
>>         fdPointer := interpreterProxy stackValue: 1.
>>         (interpreterProxy isIntegerObject: fdPointer)
>>                 ifFalse: [^ interpreterProxy primitiveFailFor:
>> PrimErrBadArgument].
>>         fd := interpreterProxy integerValueOf: fdPointer.
>>         filePointer := self connectToFd: fd write: writeFlag.
>> +       interpreterProxy failed ifFalse:
>> +               [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> +                                                       thenPush:
>> filePointer]!
>> -       interpreterProxy failed
>> -               ifFalse: [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> -                       thenPush: filePointer].
>> -       ^interpreterProxy primitiveFail.!
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Eliot Miranda-2
In reply to this post by Levente Uzonyi
 
Hi Levente,

> On Mar 7, 2018, at 3:44 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Wed, 7 Mar 2018, [hidden email] wrote:
>>
>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>>
>
> snip
>
>> Item was changed:
>> ----- Method: FilePlugin>>primitiveConnectToFile (in category 'file primitives') -----
>> primitiveConnectToFile
>>    "Connect to the file with the supplied FILE* and writeFlag.
>>    FILE* must be supplied in a byte object (ByteArray) with the platform address size.
>>    writeFlag must be a boolean and compatible with the existing file access."
>>    | writeFlag cfileOop cfile filePointer |
>> +    <var: 'cfile' type: #'void *'>
>> -    <var: 'cfile' type: 'void* '>
>>    <export: true>
>> +    writeFlag := interpreterProxy booleanValueOf: (interpreterProxy stackValue: 0).
>> -    writeFlag := interpreterProxy
>> -                booleanValueOf: (interpreterProxy stackValue: 0).
>
> It should be checked here if the primitive has failed or not, shouldn't it?

Not necessarily.  All failures only set the failure code; they don't reset it.  So it is acceptable to gather a sequence of parameters and perform a single failure check.  The important thing is to check for failure before doing anything with the parameters.


>
>>    cfileOop := interpreterProxy stackValue: 1.
>>    cfile := self pointerFrom: cfileOop.
>>    cfile ifNil:
>>        [^interpreterProxy primitiveFailFor: PrimErrBadArgument].
>>    filePointer := self connectToFile: cfile write: writeFlag.
>>    interpreterProxy failed ifFalse: +        [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> +                            thenPush: filePointer]!
>> -        [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> -                            thenPush: filePointer].
>> -    ^interpreterProxy primitiveFail.!
>>
>> Item was changed:
>> ----- Method: FilePlugin>>primitiveConnectToFileDescriptor (in category 'file primitives') -----
>> primitiveConnectToFileDescriptor
>>    "Connect to the existing file identified by fileDescriptor.
>>    fileDescriptor must be an integer.
>>    writeFlag is aboolean indicating whether to open in read or write mode and must be compatible with the existing file access."
>>    | writeFlag fdPointer fd filePointer |
>> +    <var: 'fd' type: #int>
>> -    <var: 'fd' type: 'int'>
>>    <export: true>
>>    writeFlag := interpreterProxy
>>                booleanValueOf: (interpreterProxy stackValue: 0).
>
> Same as above.
>
> Levente
>
>>    fdPointer := interpreterProxy stackValue: 1.
>>    (interpreterProxy isIntegerObject: fdPointer)
>>        ifFalse: [^ interpreterProxy primitiveFailFor: PrimErrBadArgument].
>>    fd := interpreterProxy integerValueOf: fdPointer.
>>    filePointer := self connectToFd: fd write: writeFlag.
>> +    interpreterProxy failed ifFalse:
>> +        [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> +                            thenPush: filePointer]!
>> -    interpreterProxy failed
>> -        ifFalse: [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> -            thenPush: filePointer].
>> -    ^interpreterProxy primitiveFail.!
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Eliot Miranda-2
In reply to this post by Alistair Grant
 
Hi Alistair,



_,,,^..^,,,_ (phone)
On Mar 8, 2018, at 6:59 AM, Alistair Grant <[hidden email]> wrote:

Hi Eliot,

On Wed, Mar 07, 2018 at 10:46:41PM +0000, [hidden email] wrote:

Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz

==================== Summary ====================

Name: VMMaker.oscog-eem.2347
Author: eem
Time: 7 March 2018, 2:46:20.98144 pm
UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
Ancestors: VMMaker.oscog-akg.2346

Review of Alistair's recent FilePlugin changes:

Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.

In my defense, the slang code I was looking at used strings.  But this
makes sense and I'll change.


With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
   bytesWritten := self
                       sqFile: file
                       Write: count * elementSize
                       From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
                       At: startIndex - 1 * elementSize.
instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:

It looks like it's at the point where I need to understand
the simulator (which I haven't looked at yet).

I haven't seen it yet, but I'll definitely watch Clémnt's video.
Where else should I look to get started with the simulator?

It should be as simple as following the instructions on http://www.mirandabanda.org/cogblog/build-image/
but since we no longer include the processor simulator plugins in the standard vm builds, the VM obtained by
    image/getGoodSpur[64]VM.sh
won't allow simulating the CoInterpreter (the JIT), only the StackInterpreter.  So this needs to be fixed.

I could build the processor simulator plugins and put them on my website or we could set up a build on the CI infrastructure.  But with the latter I could do with some help.



In primitiveConnectToFile[Descriptor] you write

   interpreterProxy failed ifFalse:
       [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
                           thenPush: filePointer].
   ^interpreterProxy primitiveFail.

but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write

   interpreterProxy failed ifFalse:
       [interpreterProxy pop: 3 "rcvr, name, writeFlag"
                           thenPush: filePointer]

OK.

Thanks for the feedback,
Alistair
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Eliot Miranda-2
In reply to this post by Alistair Grant
 
Hi Alistair,

> On Mar 8, 2018, at 7:12 AM, Alistair Grant <[hidden email]> wrote:
>
>
> Hi Levente,
>
>
>> On 8 March 2018 at 00:44, Levente Uzonyi <[hidden email]> wrote:
>>
>>> On Wed, 7 Mar 2018, [hidden email] wrote:
>>>
>>>
>>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>>>
>>
>> snip
>>
>>> Item was changed:
>>> ----- Method: FilePlugin>>primitiveConnectToFile (in category 'file
>>> primitives') -----
>>> primitiveConnectToFile
>>>        "Connect to the file with the supplied FILE* and writeFlag.
>>>        FILE* must be supplied in a byte object (ByteArray) with the
>>> platform address size.
>>>        writeFlag must be a boolean and compatible with the existing file
>>> access."
>>>        | writeFlag cfileOop cfile filePointer |
>>> +       <var: 'cfile' type: #'void *'>
>>> -       <var: 'cfile' type: 'void* '>
>>>        <export: true>
>>> +       writeFlag := interpreterProxy booleanValueOf: (interpreterProxy
>>> stackValue: 0).
>>> -       writeFlag := interpreterProxy
>>> -                               booleanValueOf: (interpreterProxy
>>> stackValue: 0).
>>
>>
>> It should be checked here if the primitive has failed or not, shouldn't it?
>
> Yes.  I thought I'd taken care of this, but obviously not.
>
>
>>>        cfileOop := interpreterProxy stackValue: 1.
>>>        cfile := self pointerFrom: cfileOop.
>>>        cfile ifNil:
>>>                [^interpreterProxy primitiveFailFor: PrimErrBadArgument].
>>>        filePointer := self connectToFile: cfile write: writeFlag.
>>>        interpreterProxy failed ifFalse: +              [interpreterProxy
>>> pop: 3 "rcvr, name, writeFlag"
>>> +                                                       thenPush:
>>> filePointer]!
>>> -               [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> -                                                       thenPush:
>>> filePointer].
>>> -       ^interpreterProxy primitiveFail.!
>>>
>>> Item was changed:
>>> ----- Method: FilePlugin>>primitiveConnectToFileDescriptor (in category
>>> 'file primitives') -----
>>> primitiveConnectToFileDescriptor
>>>        "Connect to the existing file identified by fileDescriptor.
>>>        fileDescriptor must be an integer.
>>>        writeFlag is aboolean indicating whether to open in read or write
>>> mode and must be compatible with the existing file access."
>>>        | writeFlag fdPointer fd filePointer |
>>> +       <var: 'fd' type: #int>
>>> -       <var: 'fd' type: 'int'>
>>>        <export: true>
>>>        writeFlag := interpreterProxy
>>>                                booleanValueOf: (interpreterProxy
>>> stackValue: 0).
>>
>>
>> Same as above.
>
> I'll change both of these.

Go easy.  One only needs to check for failure before anything is done with the parameters.  So a sequence of load calls followed by a single failure check is to be preferred to a sequence of load, failure check pairs.  It's more concise and more efficient.

>
>
> Thanks,
> Alistair
>
>
>> Levente
>>
>>
>>>        fdPointer := interpreterProxy stackValue: 1.
>>>        (interpreterProxy isIntegerObject: fdPointer)
>>>                ifFalse: [^ interpreterProxy primitiveFailFor:
>>> PrimErrBadArgument].
>>>        fd := interpreterProxy integerValueOf: fdPointer.
>>>        filePointer := self connectToFd: fd write: writeFlag.
>>> +       interpreterProxy failed ifFalse:
>>> +               [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> +                                                       thenPush:
>>> filePointer]!
>>> -       interpreterProxy failed
>>> -               ifFalse: [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> -                       thenPush: filePointer].
>>> -       ^interpreterProxy primitiveFail.!
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Clément Bera-4
In reply to this post by Eliot Miranda-2
 


On Thu, Mar 8, 2018 at 4:57 PM, Eliot Miranda <[hidden email]> wrote:
 
Hi Alistair,



_,,,^..^,,,_ (phone)
On Mar 8, 2018, at 6:59 AM, Alistair Grant <[hidden email]> wrote:

Hi Eliot,

On Wed, Mar 07, 2018 at 10:46:41PM +0000, [hidden email] wrote:

Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz

==================== Summary ====================

Name: VMMaker.oscog-eem.2347
Author: eem
Time: 7 March 2018, 2:46:20.98144 pm
UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
Ancestors: VMMaker.oscog-akg.2346

Review of Alistair's recent FilePlugin changes:

Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.

In my defense, the slang code I was looking at used strings.  But this
makes sense and I'll change.


With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
   bytesWritten := self
                       sqFile: file
                       Write: count * elementSize
                       From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
                       At: startIndex - 1 * elementSize.
instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:

It looks like it's at the point where I need to understand
the simulator (which I haven't looked at yet).

I haven't seen it yet, but I'll definitely watch Clémnt's video.
Where else should I look to get started with the simulator?

Here is a description with some warm-up exercises to get started with the VM simulator:
(Note that now the does not feature any more the processor simulators by default that post is 2y old)

My video deals with machine code stepping. I'm happy if you watch it, but that's different from what you want to do with the simulator. I would use the StackVMSimulator to debug a plugin like yours unless there's a specific bug with a JIT interaction. 



It should be as simple as following the instructions on http://www.mirandabanda.org/cogblog/build-image/
but since we no longer include the processor simulator plugins in the standard vm builds, the VM obtained by
    image/getGoodSpur[64]VM.sh
won't allow simulating the CoInterpreter (the JIT), only the StackInterpreter.  So this needs to be fixed.

I could build the processor simulator plugins and put them on my website or we could set up a build on the CI infrastructure.  But with the latter I could do with some help.



In primitiveConnectToFile[Descriptor] you write

   interpreterProxy failed ifFalse:
       [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
                           thenPush: filePointer].
   ^interpreterProxy primitiveFail.

but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write

   interpreterProxy failed ifFalse:
       [interpreterProxy pop: 3 "rcvr, name, writeFlag"
                           thenPush: filePointer]

OK.

Thanks for the feedback,
Alistair




--
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Ben Coman
In reply to this post by Alistair Grant
 


On 8 March 2018 at 22:59, Alistair Grant <[hidden email]> wrote:
 
Hi Eliot,

On Wed, Mar 07, 2018 at 10:46:41PM +0000, [hidden email] wrote:
>
> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>
> ==================== Summary ====================
>
> Name: VMMaker.oscog-eem.2347
> Author: eem
> Time: 7 March 2018, 2:46:20.98144 pm
> UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
> Ancestors: VMMaker.oscog-akg.2346
>
> Review of Alistair's recent FilePlugin changes:
>
> Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.

In my defense, the slang code I was looking at used strings.  But this
makes sense and I'll change.


> With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
>       bytesWritten := self
>                                               sqFile: file
>                                               Write: count * elementSize
>                                               From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
>                                               At: startIndex - 1 * elementSize.
> instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:

It looks like it's at the point where I need to understand
the simulator (which I haven't looked at yet).

I haven't seen it yet, but I'll definitely watch Clémnt's video.
Where else should I look to get started with the simulator?

Here is a beginner picking the brains of the experts...

which Clement summarised here...

cheers -ben
 


> In primitiveConnectToFile[Descriptor] you write
>
>       interpreterProxy failed ifFalse:
>               [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>                                                       thenPush: filePointer].
>       ^interpreterProxy primitiveFail.
>
> but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write
>
>       interpreterProxy failed ifFalse:
>               [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>                                                       thenPush: filePointer]

OK.

Thanks for the feedback,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

timrowledge
In reply to this post by Eliot Miranda-2
 


> On 08-03-2018, at 7:57 AM, Eliot Miranda <[hidden email]> wrote:
>
> but since we no longer include the processor simulator plugins in the standard vm builds, the VM obtained by
>     image/getGoodSpur[64]VM.sh
> won't allow simulating the CoInterpreter (the JIT), only the StackInterpreter.  So this needs to be fixed.
>
> I could build the processor simulator plugins and put them on my website or we could set up a build on the CI infrastructure.

I'd urge having them built by the autobuild stuff for consistency. It must surely be possible to have the built external plugins moved off to one side as part of that build? Then we'd 'merely' need a suitable link in the download page(s) to point to them for manual fetching and a stable address so that Eliot's build-vmmaker script can reliably find them.

In fact, having reliable URLs for any of the external plugins (strictly speaking any plugin, since we can over-ride an internal plugin if needed) would be interesting because then we could actually do what was originally intended with the "I can't find no stinkin plugin of that name!" error, which was to handle it by looking up on the net for a plausible version and installing it and restarting the operation. Maybe a mere 20 years later we can actually implement this?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Passive aggression


Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Levente Uzonyi
In reply to this post by Eliot Miranda-2
 
On Thu, 8 Mar 2018, Eliot Miranda wrote:

>
> Hi Levente,
>
>> On Mar 7, 2018, at 3:44 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>>> On Wed, 7 Mar 2018, [hidden email] wrote:
>>>
>>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>>>
>>
>> snip
>>
>>> Item was changed:
>>> ----- Method: FilePlugin>>primitiveConnectToFile (in category 'file primitives') -----
>>> primitiveConnectToFile
>>>    "Connect to the file with the supplied FILE* and writeFlag.
>>>    FILE* must be supplied in a byte object (ByteArray) with the platform address size.
>>>    writeFlag must be a boolean and compatible with the existing file access."
>>>    | writeFlag cfileOop cfile filePointer |
>>> +    <var: 'cfile' type: #'void *'>
>>> -    <var: 'cfile' type: 'void* '>
>>>    <export: true>
>>> +    writeFlag := interpreterProxy booleanValueOf: (interpreterProxy stackValue: 0).
>>> -    writeFlag := interpreterProxy
>>> -                booleanValueOf: (interpreterProxy stackValue: 0).
>>
>> It should be checked here if the primitive has failed or not, shouldn't it?
>
> Not necessarily.  All failures only set the failure code; they don't reset it.  So it is acceptable to gather a sequence of parameters and perform a single failure check.  The important thing is to check for failure before doing anything with the parameters.

Well, yes, in the end #connectToFile:write: will not use the value of
writeFlag, but that is way too unintuitive in my option.
Also, since there is an error code for this case, the code could just
return with PrimErrBadArgument.

Levente

>
>
>>
>>>    cfileOop := interpreterProxy stackValue: 1.
>>>    cfile := self pointerFrom: cfileOop.
>>>    cfile ifNil:
>>>        [^interpreterProxy primitiveFailFor: PrimErrBadArgument].
>>>    filePointer := self connectToFile: cfile write: writeFlag.
>>>    interpreterProxy failed ifFalse: +        [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> +                            thenPush: filePointer]!
>>> -        [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> -                            thenPush: filePointer].
>>> -    ^interpreterProxy primitiveFail.!
>>>
>>> Item was changed:
>>> ----- Method: FilePlugin>>primitiveConnectToFileDescriptor (in category 'file primitives') -----
>>> primitiveConnectToFileDescriptor
>>>    "Connect to the existing file identified by fileDescriptor.
>>>    fileDescriptor must be an integer.
>>>    writeFlag is aboolean indicating whether to open in read or write mode and must be compatible with the existing file access."
>>>    | writeFlag fdPointer fd filePointer |
>>> +    <var: 'fd' type: #int>
>>> -    <var: 'fd' type: 'int'>
>>>    <export: true>
>>>    writeFlag := interpreterProxy
>>>                booleanValueOf: (interpreterProxy stackValue: 0).
>>
>> Same as above.
>>
>> Levente
>>
>>>    fdPointer := interpreterProxy stackValue: 1.
>>>    (interpreterProxy isIntegerObject: fdPointer)
>>>        ifFalse: [^ interpreterProxy primitiveFailFor: PrimErrBadArgument].
>>>    fd := interpreterProxy integerValueOf: fdPointer.
>>>    filePointer := self connectToFd: fd write: writeFlag.
>>> +    interpreterProxy failed ifFalse:
>>> +        [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> +                            thenPush: filePointer]!
>>> -    interpreterProxy failed
>>> -        ifFalse: [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>>> -            thenPush: filePointer].
>>> -    ^interpreterProxy primitiveFail.!
Reply | Threaded
Open this post in threaded view
|

Auto-load plugins from the net (was: VM Maker: VMMaker.oscog-eem.2347.mcz)

David T. Lewis
In reply to this post by timrowledge
 
On Thu, Mar 08, 2018 at 09:56:29AM -0800, tim Rowledge wrote:

>
> > On 08-03-2018, at 7:57 AM, Eliot Miranda <[hidden email]> wrote:
> >
> > but since we no longer include the processor simulator plugins in the standard vm builds, the VM obtained by
> >     image/getGoodSpur[64]VM.sh
> > won't allow simulating the CoInterpreter (the JIT), only the StackInterpreter.  So this needs to be fixed.
> >
> > I could build the processor simulator plugins and put them on my website or we could set up a build on the CI infrastructure.
>
> I'd urge having them built by the autobuild stuff for consistency. It must
> surely be possible to have the built external plugins moved off to one
> side as part of that build? Then we'd 'merely' need a suitable link in
> the download page(s) to point to them for manual fetching and a stable
> address so that Eliot's build-vmmaker script can reliably find them.
>
> In fact, having reliable URLs for any of the external plugins (strictly
> speaking any plugin, since we can over-ride an internal plugin if needed)
> would be interesting because then we could actually do what was originally
> intended with the "I can't find no stinkin plugin of that name!" error,
> which was to handle it by looking up on the net for a plausible version
> and installing it and restarting the operation. Maybe a mere 20 years later
> we can actually implement this?
>

That's an interesting idea, first I've heard of it. Can you sketch out how
such a loading scheme might work?

I am envisioning something along the lines of:

- try loading the primitive
- if not found determine name of the plugin for that primitive
- look up href location for the plugin (modulo 32/64 bit host/image)
- also check if we tried this once before, don't try it again
- download plugin file to a writeable location on your computer, where that
  location would be in the lookup path for module loading
- maybe validate the file in some way for security
- try loading the primitive again
- if not successful, remember that this primitive is not available, then fall
  back on the actual fallback code

Is that the idea?

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Auto-load plugins from the net (was: VM Maker: VMMaker.oscog-eem.2347.mcz)

timrowledge
 


> On 08-03-2018, at 5:25 PM, David T. Lewis <[hidden email]> wrote:
>
>
> That's an interesting idea, first I've heard of it. Can you sketch out how
> such a loading scheme might work?
>
> I am envisioning something along the lines of:
>
> - try loading the primitive
> - if not found determine name of the plugin for that primitive
> - look up href location for the plugin (modulo 32/64 bit host/image)
> - also check if we tried this once before, don't try it again
> - download plugin file to a writeable location on your computer, where that
>  location would be in the lookup path for module loading
> - maybe validate the file in some way for security
> - try loading the primitive again
> - if not successful, remember that this primitive is not available, then fall
>  back on the actual fallback code
>
> Is that the idea?

Pretty much got it. The only extra info we'd need is a root for module URLs - something like modules.squeak.org maybe? and work out the vm details to complete the path to something like https://module.squeak.org/linux/32/armv6/blogsmasherplugin

We'd know at that point that there isn't an installed copy already on the machine since it would have been found by the external lookup. It wouldn't need redownloading unless we did something to delete that copy - say a date related thing to say it's out of date or the rental is due :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Motie Warriors does it take to change a lightbulb?”
"None. One of the dead ones will do it."



Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Alistair Grant
In reply to this post by Ben Coman
 
Hi Eliot, Clément & Ben,

Thanks very much for all your suggestions on getting started with the
simulator.  I'll be looking at them all.

Thanks again,
Alistair



On 8 March 2018 at 17:42, Ben Coman <[hidden email]> wrote:

>
>
>
> On 8 March 2018 at 22:59, Alistair Grant <[hidden email]> wrote:
>>
>>
>> Hi Eliot,
>>
>> On Wed, Mar 07, 2018 at 10:46:41PM +0000, [hidden email] wrote:
>> >
>> > Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>> > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: VMMaker.oscog-eem.2347
>> > Author: eem
>> > Time: 7 March 2018, 2:46:20.98144 pm
>> > UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
>> > Ancestors: VMMaker.oscog-akg.2346
>> >
>> > Review of Alistair's recent FilePlugin changes:
>> >
>> > Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.
>>
>> In my defense, the slang code I was looking at used strings.  But this
>> makes sense and I'll change.
>>
>>
>> > With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
>> >       bytesWritten := self
>> >                                               sqFile: file
>> >                                               Write: count * elementSize
>> >                                               From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
>> >                                               At: startIndex - 1 * elementSize.
>> > instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:
>>
>> It looks like it's at the point where I need to understand
>> the simulator (which I haven't looked at yet).
>>
>> I haven't seen it yet, but I'll definitely watch Clémnt's video.
>> Where else should I look to get started with the simulator?
>
>
> Here is a beginner picking the brains of the experts...
> http://forum.world.st/Exploring-the-simulator-was-Re-REPL-image-for-simulation-td4896870.html
>
> which Clement summarised here...
> https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/
>
> cheers -ben
>
>
>>
>> > In primitiveConnectToFile[Descriptor] you write
>> >
>> >       interpreterProxy failed ifFalse:
>> >               [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> >                                                       thenPush: filePointer].
>> >       ^interpreterProxy primitiveFail.
>> >
>> > but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write
>> >
>> >       interpreterProxy failed ifFalse:
>> >               [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> >                                                       thenPush: filePointer]
>>
>> OK.
>>
>> Thanks for the feedback,
>> Alistair
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Auto-load plugins from the net (was: VM Maker: VMMaker.oscog-eem.2347.mcz)

Eliot Miranda-2
In reply to this post by timrowledge
 
Hi Tim,

> On Mar 8, 2018, at 5:46 PM, tim Rowledge <[hidden email]> wrote:
>
>
>
>
>> On 08-03-2018, at 5:25 PM, David T. Lewis <[hidden email]> wrote:
>>
>>
>> That's an interesting idea, first I've heard of it. Can you sketch out how
>> such a loading scheme might work?
>>
>> I am envisioning something along the lines of:
>>
>> - try loading the primitive
>> - if not found determine name of the plugin for that primitive
>> - look up href location for the plugin (modulo 32/64 bit host/image)
>> - also check if we tried this once before, don't try it again
>> - download plugin file to a writeable location on your computer, where that
>> location would be in the lookup path for module loading
>> - maybe validate the file in some way for security
>> - try loading the primitive again
>> - if not successful, remember that this primitive is not available, then fall
>> back on the actual fallback code
>>
>> Is that the idea?
>
> Pretty much got it. The only extra info we'd need is a root for module URLs - something like modules.squeak.org maybe? and work out the vm details to complete the path to something like https://module.squeak.org/linux/32/armv6/blogsmasherplugin
>
> We'd know at that point that there isn't an installed copy already on the machine since it would have been found by the external lookup. It wouldn't need redownloading unless we did something to delete that copy - say a date related thing to say it's out of date or the rental is due :-)


In doing this it would be nice to decouple the plugin primitive binding mechanism from invocation a la VisualWorks. The issue here is that in the Squeak VM binding is done on first invocation.  The n VisualWorks an inbound invocation results in a callback. Although a specific primitive failure with its own failure code is feasible, it means we would have to rewrite every plugin primitive method so it's infeasible.  The callback selector would have to be in the specialObjectsArray.  The system's response would be to bind the primitive and retry, but this would happen at the Smalltalk level, not hidden in the VM.  Esteban has already provided some of the binding machinery (a primitive to look up function addresses by name in a loaded library).

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "How many Motie Warriors does it take to change a lightbulb?”
> "None. One of the dead ones will do it."
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Clément Bera-4
In reply to this post by Alistair Grant
 


On Fri, Mar 9, 2018 at 9:22 AM, Alistair Grant <[hidden email]> wrote:

Hi Eliot, Clément & Ben,

Thanks very much for all your suggestions on getting started with the
simulator.  I'll be looking at them all.

Thanks again,
Alistair


Another thing you can do is to simulate the simulator itself, so you can look at the code, the execution from the outside and from the inside at the same time. See picture below

| cos |
cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
cos desiredNumStackPages: 8.
cos openOn: 'SpurVMMaker.image'.
cos systemAttributes
at: 2 put: '-doit';
at: 3 put: '| cos |
cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
cos desiredNumStackPages: 8.
cos openOn: ''SpurVMMaker.image''.
cos openAsMorph; run'.

cos openAsMorph; run


 


On 8 March 2018 at 17:42, Ben Coman <[hidden email]> wrote:
>
>
>
> On 8 March 2018 at 22:59, Alistair Grant <[hidden email]> wrote:
>>
>>
>> Hi Eliot,
>>
>> On Wed, Mar 07, 2018 at 10:46:41PM +0000, [hidden email] wrote:
>> >
>> > Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>> > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: VMMaker.oscog-eem.2347
>> > Author: eem
>> > Time: 7 March 2018, 2:46:20.98144 pm
>> > UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
>> > Ancestors: VMMaker.oscog-akg.2346
>> >
>> > Review of Alistair's recent FilePlugin changes:
>> >
>> > Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.
>>
>> In my defense, the slang code I was looking at used strings.  But this
>> makes sense and I'll change.
>>
>>
>> > With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
>> >       bytesWritten := self
>> >                                               sqFile: file
>> >                                               Write: count * elementSize
>> >                                               From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
>> >                                               At: startIndex - 1 * elementSize.
>> > instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:
>>
>> It looks like it's at the point where I need to understand
>> the simulator (which I haven't looked at yet).
>>
>> I haven't seen it yet, but I'll definitely watch Clémnt's video.
>> Where else should I look to get started with the simulator?
>
>
> Here is a beginner picking the brains of the experts...
> http://forum.world.st/Exploring-the-simulator-was-Re-REPL-image-for-simulation-td4896870.html
>
> which Clement summarised here...
> https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/
>
> cheers -ben
>
>
>>
>> > In primitiveConnectToFile[Descriptor] you write
>> >
>> >       interpreterProxy failed ifFalse:
>> >               [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> >                                                       thenPush: filePointer].
>> >       ^interpreterProxy primitiveFail.
>> >
>> > but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write
>> >
>> >       interpreterProxy failed ifFalse:
>> >               [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> >                                                       thenPush: filePointer]
>>
>> OK.
>>
>> Thanks for the feedback,
>> Alistair
>>
>
>



--
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Alistair Grant
 
Hi Clément,


On 10 March 2018 at 13:27, Clément Bera <[hidden email]> wrote:

>
>
>
> On Fri, Mar 9, 2018 at 9:22 AM, Alistair Grant <[hidden email]> wrote:
>>
>>
>> Hi Eliot, Clément & Ben,
>>
>> Thanks very much for all your suggestions on getting started with the
>> simulator.  I'll be looking at them all.
>>
>> Thanks again,
>> Alistair
>>
>
> Another thing you can do is to simulate the simulator itself, so you can look at the code, the execution from the outside and from the inside at the same time. See picture below
>
> | cos |
> cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
> cos desiredNumStackPages: 8.
> cos openOn: 'SpurVMMaker.image'.
> cos systemAttributes
> at: 2 put: '-doit';
> at: 3 put: '| cos |
> cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
> cos desiredNumStackPages: 8.
> cos openOn: ''SpurVMMaker.image''.
> cos openAsMorph; run'.
>
> cos openAsMorph; run

And down the rabbit hole we go... :-)

But seriously: Thanks for the tip, I doubt I would have thought of this.

Cheers,
Alistair



>> On 8 March 2018 at 17:42, Ben Coman <[hidden email]> wrote:
>> >
>> >
>> >
>> > On 8 March 2018 at 22:59, Alistair Grant <[hidden email]> wrote:
>> >>
>> >>
>> >> Hi Eliot,
>> >>
>> >> On Wed, Mar 07, 2018 at 10:46:41PM +0000, [hidden email] wrote:
>> >> >
>> >> > Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>> >> > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2347.mcz
>> >> >
>> >> > ==================== Summary ====================
>> >> >
>> >> > Name: VMMaker.oscog-eem.2347
>> >> > Author: eem
>> >> > Time: 7 March 2018, 2:46:20.98144 pm
>> >> > UUID: 062614a7-e3da-4b30-997a-9568911b9ff5
>> >> > Ancestors: VMMaker.oscog-akg.2346
>> >> >
>> >> > Review of Alistair's recent FilePlugin changes:
>> >> >
>> >> > Alistair, in var:type: declarations use symbols for types, as these are shared in lots of cases.
>> >>
>> >> In my defense, the slang code I was looking at used strings.  But this
>> >> makes sense and I'll change.
>> >>
>> >>
>> >> > With several plugins, but especially the FilePlugin and SocketPlugin, avoid using cCode: 'aString(...)' inSmalltalk: [passive default] because this is not simulateable.  For example in FilePlugin>>#primitiveFileWrite you'll see
>> >> >       bytesWritten := self
>> >> >                                               sqFile: file
>> >> >                                               Write: count * elementSize
>> >> >                                               From: (interpreterProxy cCoerce: (interpreterProxy firstIndexableField: array) to: #'char *')
>> >> >                                               At: startIndex - 1 * elementSize.
>> >> > instead of a self cCode: 'sqFileWriteFromAt(...)' form and you'll find an implementation at FilePluginSimulator>>#sqFile:Write:From:At:
>> >>
>> >> It looks like it's at the point where I need to understand
>> >> the simulator (which I haven't looked at yet).
>> >>
>> >> I haven't seen it yet, but I'll definitely watch Clémnt's video.
>> >> Where else should I look to get started with the simulator?
>> >
>> >
>> > Here is a beginner picking the brains of the experts...
>> > http://forum.world.st/Exploring-the-simulator-was-Re-REPL-image-for-simulation-td4896870.html
>> >
>> > which Clement summarised here...
>> > https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/
>> >
>> > cheers -ben
>> >
>> >
>> >>
>> >> > In primitiveConnectToFile[Descriptor] you write
>> >> >
>> >> >       interpreterProxy failed ifFalse:
>> >> >               [^interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> >> >                                                       thenPush: filePointer].
>> >> >       ^interpreterProxy primitiveFail.
>> >> >
>> >> > but there's no point calling primitiveFail a secoind time given that interpreterProxy failed tells you the primitive has already failed.  Simply write
>> >> >
>> >> >       interpreterProxy failed ifFalse:
>> >> >               [interpreterProxy pop: 3 "rcvr, name, writeFlag"
>> >> >                                                       thenPush: filePointer]
>> >>
>> >> OK.
>> >>
>> >> Thanks for the feedback,
>> >> Alistair
>> >>
>> >
>> >
>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.github.io/
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

timrowledge
In reply to this post by Clément Bera-4
 


> On 10-03-2018, at 4:27 AM, Clément Bera <[hidden email]> wrote:
>
> Another thing you can do is to simulate the simulator itself, so you can look at the code, the execution from the outside and from the inside at the same time. See picture below
>
> | cos |
> cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
> cos desiredNumStackPages: 8.
> cos openOn: 'SpurVMMaker.image'.
> cos systemAttributes
> at: 2 put: '-doit';
> at: 3 put: '| cos |
> cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
> cos desiredNumStackPages: 8.
> cos openOn: ''SpurVMMaker.image''.
> cos openAsMorph; run'.
>
> cos openAsMorph; run

That is rather more than a little bit cool. Even more fun - make one of the simulators be using the ARM cpu sim so you can simulate the simulation of simulating a different cpu whilst debugging the debugger debugger simulation. Or something like that; easy to get lost in the mirrors.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PBT: Prune Binary Tree


Reply | Threaded
Open this post in threaded view
|

Re: VM Maker: VMMaker.oscog-eem.2347.mcz

Clément Bera-4
 


On Sat, Mar 10, 2018 at 7:24 PM, tim Rowledge <[hidden email]> wrote:



> On 10-03-2018, at 4:27 AM, Clément Bera <[hidden email]> wrote:
>
> Another thing you can do is to simulate the simulator itself, so you can look at the code, the execution from the outside and from the inside at the same time. See picture below
>
> | cos |
> cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
> cos desiredNumStackPages: 8.
> cos openOn: 'SpurVMMaker.image'.
> cos systemAttributes
>               at: 2 put: '-doit';
>               at: 3 put:      '| cos |
> cos := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
> cos desiredNumStackPages: 8.
> cos openOn: ''SpurVMMaker.image''.
> cos openAsMorph; run'.
>
> cos openAsMorph; run

That is rather more than a little bit cool. Even more fun - make one of the simulators be using the ARM cpu sim so you can simulate the simulation of simulating a different cpu whilst debugging the debugger debugger simulation. Or something like that; easy to get lost in the mirrors.


I tried, but primitiveNewCPU cannot be simulated, hence you can simulate only a StackVMSimulator ;-).

It takes a few hours to open inside the simulator window though.

 
tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PBT: Prune Binary Tree





--
Clément Béra
Pharo consortium engineer
https://clementbera.github.io/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq