squeak-vmdev

[Squeak-VMdev] Request for help with simulation in 3.7

[Dan I. <Da...@Sq...>]

Hi, Guys -

In starting to work on the 64-bit system, i was never able to get any current version of Squeak to simulate itself fully.  Tim Rowledge had a couple of work-arounds that at least allowed some windows to paint, and an early MVC image to run, so I took those and have been using them, in hopes that by the time I got well through the 64-bit work I would find a solid base to work from.

I am now at the point where the 64-bit system works essentially as well as the 32-bit system in simulation, but that is not good enough.  There are failures in both during morphic display, and these become fatal as they recur during attempts to put up error windows.  Moreover the latest system, even when running MVC, uses outline fonts, and there are failures in simulating these.

I need to know some very basic information, which has changed since I was last in control of the VM and simulation.

1.  If everything worked right, is it the case that a current system should be able to simulate itself?  What this means is that, provided that the plugin interface all works (and fails) properly, does all the necessary failure code exist such that the system will run completely and with integrity?  If this is not so, then a further question is, apart from whatever fixes may be needed, how much new code would need to be written?

2.  Assuming the answer to (1) is yes (and I sure hope it is), then the question is, does anyone anywhere have a recent version of Squeak that can simulate itself successfully in Morphic?  This means displaying the mouse ( ideally), and a browser in which one can at least type 3+4, and print the value.  If so, then this is all I need, as I can use that to find whatever problems there are in the latest 3.7 and VMMaker that I am using for the basis of the 64-bit work.

I would be happy to supply further debugging info, and you can, of course, see it all for yourself if you have time to load up VMMaker in the latest 3.7, and try simulating itself.

Most of my current failures stem from BalloonEngine>>#primInitializeBuffer:, which either was written to fail, or fails as a side-effect of other work-arounds.  Unfortunately I cannot figure out what should happen here.  I am similarly in the dark about, eg, transformations in the 3DMatrix plugin, but I believe that I'm getting by by making things fail.

I have asked Craig Latta about this, since he claims to have achieved full simulation of 3.6 in 3.6, but now he's not sure.  I think you two are the only others who may know more or may have gone farther at vairous times in the past, but I'm also CC'ing the VM list in case someone else has more info.

I don't need much here, I don't think.  Either a single working system, or some documentation that relates to simulating the complex plugins.  I can supply lots of traces, and diagnostic info from the simulator transcript if that would be of use.

Thanks in advance for any guidance you can offer.

	- Dan

Re: [Squeak-VMdev] Request for help with simulation in 3.7

[Ned K. <ne...@sq...>]

On Friday 09 July 2004 12:33 pm, Dan Ingalls wrote:

> I am now at the point where the 64-bit system works essentially as well as
> the 32-bit system in simulation, but that is not good enough.  There are
> failures in both during morphic display, and these become fatal as they
> recur during attempts to put up error windows.

Where are you seeing the problems?

> Moreover the latest system, 
> even when running MVC, uses outline fonts, and there are failures in
> simulating these.

It doesn't have to use outline fonts. Just remove the TTCFont and set the 
system fonts to not use them.

> I need to know some very basic information, which has changed since I was
> last in control of the VM and simulation.
>
> 1.  If everything worked right, is it the case that a current system should
> be able to simulate itself?  What this means is that, provided that the
> plugin interface all works (and fails) properly, does all the necessary
> failure code exist such that the system will run completely and with
> integrity?  If this is not so, then a further question is, apart from
> whatever fixes may be needed, how much new code would need to be written?

Did you get the various simulation changes that I and others posted (I think I 
mailed some to you)? I don't think they have gotten back into the image (but 
they should), because they needed more testing.

> 2.  Assuming the answer to (1) is yes (and I sure hope it is), then the
> question is, does anyone anywhere have a recent version of Squeak that can
> simulate itself successfully in Morphic?  This means displaying the mouse (
> ideally), and a browser in which one can at least type 3+4, and print the
> value.  If so, then this is all I need, as I can use that to find whatever
> problems there are in the latest 3.7 and VMMaker that I am using for the
> basis of the 64-bit work.

I had this going at one time, as I recall.

> I would be happy to supply further debugging info, and you can, of course,
> see it all for yourself if you have time to load up VMMaker in the latest
> 3.7, and try simulating itself.

What are you loading besides the basic image?

-- 
Ned Konz
MetaMagix
Stanwood WA
(360) 629-1091

Re: [Squeak-VMdev] Request for help with simulation in 3.7

[tim R. <ti...@su...>]

> 1.  If everything worked right, is it the case that a current system
> should be able to simulate itself?  What this means is that, provided
> that the plugin interface all works (and fails) properly, does all
> the necessary failure code exist such that the system will run
> completely and with integrity?  If this is not so, then a further
> question is, apart from whatever fixes may be needed, how much new
> code would need to be written?
> 
With the two fixes I sent you in between packing boxes and disconnecting 
  computers it should simulate about as well as can be expected right now.
As you've discovered, there are parts of some plugins which were not 
written with support for the simulator in mind.  For example, 6 methods 
send strlen: and 7 strcmp: - neither of which are simulated.

BalloonEngine>>#primInitializeBuffer: looks suspicious to me from a 
quick scan mainly because resetGraphicsEngineStats fills up 'workBuffer' 
which most likely needs to be wrapped in a CArrayAccessor in the 
BalloonEngineSimulation code. See BalloonEngineSimulation>smallSqrtTable 
for an example involving a small array.

Interpreter>primitiveTruncated fails for utterly obvious reasons - the 
line self cCode:'pushInteger((int) trunc)' inSmalltalk:[self 
pushInteger: rcvr truncated]] quite obviously doesn't do a range test on 
the truncated number and since a very large float can easily exceed an 
acceptable 32bit int, kaboom.

All of the improvements Ned (&I) proposed in april when you started 
looking at 64bitness are in the VMMaker3-7b5 package. The extra two 
fixes compensate for the latest work on dispatching direct function 
addresses in the message sending.

Aside from some places where the perpetrator of code can remember doing 
something unsimulable, the only real answer is to run till it breaks and 
find a fix each time. Ny experience is that this is tedious, time 
consuming and utterly unappreciated work that nobody cares about until 
they have a problem. Much like most VM work in fact :-)

I'm not in a position to do anything much with this for now; I'm still 
unpacking, setting up and trying to find everything.

tim

Re: [Squeak-VMdev] Request for help with simulation in 3.7

[Dan I. <Da...@Sq...>]

 tim Rowledge <ti...@su...>  wrote..

>With the two fixes I sent you in between packing boxes and disconnecting  computers it should simulate about as well as can be expected right now.
>As you've discovered, there are parts of some plugins which were not written with support for the simulator in mind.  For example, 6 methods send strlen: and 7 strcmp: - neither of which are simulated.

Well, my expectations are higher, but you're right that some recent additions seem never to have been simulated.

>BalloonEngine>>#primInitializeBuffer: looks suspicious to me from a quick scan mainly because resetGraphicsEngineStats fills up 'workBuffer' which most likely needs to be wrapped in a CArrayAccessor in the BalloonEngineSimulation code. See BalloonEngineSimulation>smallSqrtTable for an example involving a small array.

If Andreas is listening, it would be *extremely* useful to me to know how this is supposed to work.  In other words if everything should fail in simulation, or if some or all of it will have to run in slang code.  And whether that slang ever ran in simulation, or only in translation to C.

>Interpreter>primitiveTruncated fails for utterly obvious reasons - the line self cCode:'pushInteger((int) trunc)' inSmalltalk:[self pushInteger: rcvr truncated]] quite obviously doesn't do a range test on the truncated number and since a very large float can easily exceed an acceptable 32bit int, kaboom.

Yes, I fixed this way back.

>All of the improvements Ned (&I) proposed in april when you started looking at 64bitness are in the VMMaker3-7b5 package. The extra two fixes compensate for the latest work on dispatching direct function addresses in the message sending.
>
>Aside from some places where the perpetrator of code can remember doing something unsimulable, the only real answer is to run till it breaks and find a fix each time. Ny experience is that this is tedious, time consuming and utterly unappreciated work that nobody cares about until they have a problem. Much like most VM work in fact :-)

Having just bashed most of the kernel into execution of a true 64-bit image with a true 64-bit ObjectMemory, I'm pretty much into the tedium.  I do appreciate what everyone has done before, and the best form of that appreciation in my mind would be for me to get things working right again, and to leave some basic tests in place that will make it easy for the guides or whoever to check that most everything is right before any major release.

	- Dan

Re: [Squeak-VMdev] Request for help with simulation in 3.7

[Dan I. <Da...@Sq...>]

>All of it should and does run in the simulation

Thanks, Andreas -

This gives me great hope.

>- it's just that there are a
>few gotchas that I didn't think about for getting this stuff running from
>the interpsim (which, unfortunately insists on managing an array of bytes
>instead of objects...)
>
>AFAICT, the problem is really in the use of the workBuffer iVar in the B2D
>simulation which expects some sort of array (it's accessed via #at: and
>#at:put:) and typically holding a CArrayAccessor of some kind but being
>handed a SmallInt from the interpsim. Which in itself wouldn't be that big
>of a problem if the simulation would consistently use #longAt: and friends
>but it doesn't and so there it goes...
>
>I've attached a few changes which (I think) are the simplest workaround to
>the problem. Let me know if this works.

That's exactly the kind of boost I was after.  I'll take it from here and, with the caveat that I may have to ask you a couple more specific questions, I should be able to get things right.  I will report to all as things progress.

	- Dan

Re: [Squeak-VMdev] Request for help with simulation in 3.7

[Andreas R. <and...@gm...>]

Dan,

> That's exactly the kind of boost I was after.  I'll take it
> from here and, with the caveat that I may have to ask you a
> couple more specific questions, I should be able to get things
> right.  I will report to all as things progress.

Great. If you want to, we could meet wednesday to work out any remaining
issues. Let me know (or rather: Kim, since that'll be eating into eToys
time) if we want to set up a meeting for an hour or so.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Dan Ingalls" <Da...@Sq...>
To: "Andreas Raab" <and...@gm...>
Cc: <squ...@li...>
Sent: Monday, July 12, 2004 11:30 AM
Subject: Re: [Squeak-VMdev] Request for help with simulation in 3.7


> >All of it should and does run in the simulation
>
> Thanks, Andreas -
>
> This gives me great hope.
>
> >- it's just that there are a
> >few gotchas that I didn't think about for getting this stuff running from
> >the interpsim (which, unfortunately insists on managing an array of bytes
> >instead of objects...)
> >
> >AFAICT, the problem is really in the use of the workBuffer iVar in the
B2D
> >simulation which expects some sort of array (it's accessed via #at: and
> >#at:put:) and typically holding a CArrayAccessor of some kind but being
> >handed a SmallInt from the interpsim. Which in itself wouldn't be that
big
> >of a problem if the simulation would consistently use #longAt: and
friends
> >but it doesn't and so there it goes...
> >
> >I've attached a few changes which (I think) are the simplest workaround
to
> >the problem. Let me know if this works.
>
> That's exactly the kind of boost I was after.  I'll take it from here and,
with the caveat that I may have to ask you a couple more specific questions,
I should be able to get things right.  I will report to all as things
progress.
>
> - Dan
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Squeak-VMdev mailing list
> Squ...@li...
> https://lists.sourceforge.net/lists/listinfo/squeak-vmdev
>