[Vm-dev] Exploring the simulator (was Re: REPL image for simulation)

[Ben Coman]

On Sun, May 29, 2016 at 10:14 AM, Ben Coman <btc at openinworld.com> wrote:
> Hi Clement, Thanks for your detailed reply.  I particularly liked your
> warm up exercises.  Goal directed learning is better than general
> browsing.
>
> On Tue, May 24, 2016 at 1:29 AM, Clément Bera <bera.clement at gmail.com> wrote:
>>
>> Hi Ben,
>>
>> The REPL image expects chunk format. Hence you need to write "3 + 4 !"
>>
>> To get warmed-up:
>> 1) Inspect the object memory, then look for the first class table page instance variable. It's an oop referencing an array, try in the simulator to "printOop:" the address of the first class table page that you found. It should print it in the Transcript, the first entries are immediate, in Spur32 SmallInteger/Character/SmallInteger.
>
> The inspector showed a Spur32MMLECoSimulator and classTableFirstPage
> held 16r5311F8. Plugging that into [print oop...] showed...

  16r5311F8: a(n) Array
   16r52D108 nil  16r15C3A50 class SmallInteger   16r878D70 class
Character  16r15C3A50 class SmallInteger
  16r1111DC0 class SmallFloat64   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r52D108 nil   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r52D108 nil   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r87AE60 class Array   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r52D108 nil   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r52D108 nil   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r52D108 nil   16r52D108 nil   16r52D108 nil   16r52D108 nil
   16r878C58 class LargeNegativeInteger   16r878C90 class
LargePositiveInteger  16r10AEAE8 class BoxedFloat64   16r879438 class
Message

All the nils I guess are due to the class table being a hash map?

Is there some way from within the simulation to reference an object by
its hex number.  For example, to use the size of that array from
within the simulation, something like...

   classTableSize := 16r5311F8 objectFromHex size

>
>
>> 2) print the active stack, look for the method's address. Try to print it as an oop, and if it tells you "address in the machine code zone", print the cog method and its machine code instead.

I presume is the active stack is
[print call stack] which produces...

  16r1012F8 M MultiByteFileStream(StandardFileStream)>basicNext
16r1E7408: a(n) MultiByteFileStream
  16r101334 M UTF8TextConverter>nextFromStream: 16r1EA418: a(n)
UTF8TextConverter
  16r10135C M MultiByteFileStream>next 16r1E7408: a(n) MultiByteFileStream
  16r10138C I MultiByteFileStream(PositionableStream)>nextChunkNoTag
16r1E7408: a(n) MultiByteFileStream
  16r1013B0 I StdioListener>run 16r1E7C98: a(n) StdioListener
  16r1013D0 I [] in UndefinedObject>(nil) 16r52D108: a(n) UndefinedObject
  16r1013F0 I [] in BlockClosure>newProcess 16r1E7E00: a(n) BlockClosure
---------

[print oop...] 16r1012F8   tells me...
    16r1012F8 is in the stack zone

[print cog method for...] 16r1012F8    tells me...
    not a method

[print mc/cog frame]   says...
Assertion failed
with debugger at CogVMSimulatorLSD(CoInterpreter)>>isMachineCodeFrame:

So I seem to be missing something.


I restarted the simulator and this time...
[print call stack...]
  16r1012F8 M MultiByteFileStream(StandardFileStream)>basicNext
16r2A1BA8: a(n) MultiByteFileStream
  16r101334 M UTF8TextConverter>nextFromStream: 16r2A2188: a(n)
UTF8TextConverter
  16r10135C M MultiByteFileStream>next 16r2A1BA8: a(n) MultiByteFileStream
  16r10138C I MultiByteFileStream(PositionableStream)>nextChunkNoTag
16r2A1BA8: a(n) MultiByteFileStream
  16r1013B0 I StdioListener>run 16r2A1B00: a(n) StdioListener
  16r1013D0 I [] in UndefinedObject>(nil) 16r52D108: a(n) UndefinedObject
  16r1013F0 I [] in BlockClosure>newProcess 16r2A1690: a(n) BlockClosure
----------

[print oop...] 16r1012F8
  16r1012F8 is in the stack zone

[print oop...] 16r2A1BA8
  16r2A1BA8: a(n) MultiByteFileStream
   16r2A2740 '????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????'
       16r1 =0 (16r0)        16r1 =0 (16r0)   16r52D108 nil
   16r52D108 nil   16r52D118 false   16r9AA1E8 #stdin   16r24CC18 a ByteArray
   16r2A2728 '?'   16r52D108 nil   16r2A2188 an UTF8TextConverter
16r6DF1D8 #lf
   16r52D128 true
-----------

Now after doing 3+4! several times,
[print call stack...] produces...
  16r101300 M MultiByteFileStream(StandardFileStream)>basicNext
16r2A1BA8: a(n) MultiByteFileStream
  16r10133C M UTF8TextConverter>nextFromStream: 16r2A2188: a(n)
UTF8TextConverter
  16r101364 M MultiByteFileStream>next 16r2A1BA8: a(n) MultiByteFileStream
  16r10138C M MultiByteFileStream(PositionableStream)>nextChunkNoTag
16r2A1BA8: a(n) MultiByteFileStream
  16r1013B0 I StdioListener>run 16r2A1B00: a(n) StdioListener
  16r1013D0 I [] in UndefinedObject>(nil) 16r52D108: a(n) UndefinedObject
  16r1013F0 I [] in BlockClosure>newProcess 16r2A1690: a(n) BlockClosure

btw, What is the meaning of the M and I in the second column?  I
notice that 16r10138C has changed from an I to a M.

Also the address associated with basicNext changed from 16r1012F8 to
16r101300. Can some meaning be inferred from that?

cheers -ben