Hi Nicolas,
On Sun, Apr 26, 2020 at 6:27 PM Eliot Miranda <eliot.miranda(a)gmail.com>
wrote:
>
>
> On Apr 26, 2020, at 1:50 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice(a)gmail.com> wrote:
>
>
> and https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2732.diff
>
>
Alas no. The bug is definitely still there in both 32-bit and 64-bits in
the trunk of VMMaker under the simulator. Run with your favorite trunk
image and in the simulation open up an About Squeak SystemReporter. The
good news is that it is *only* in the simulator on 64-bits. On the real VM
on my Mac I see no problems.
Nicolas, can you point me to the (un)signed shifts that had to be changed
in Slang to fix the problem in the real VM? That should make it trivial to
fix the simulation. I ask because there are no senders of >>> in
BitBltSimulation so I don't see an obvious place to focus on.
> Thanks!!
>
>
> Le dim. 26 avr. 2020 à 22:48, Nicolas Cellier <
> nicolas.cellier.aka.nice(a)gmail.com> a écrit :
>
>> Hi Eliot,
>> already fixed by
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3fa41faef52a157954…
>>
>> Le dim. 26 avr. 2020 à 22:44, Eliot Miranda <eliot.miranda(a)gmail.com> a
>> écrit :
>>
>>> Hi Tim,
>>>
>>> On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda <eliot.miranda(a)gmail.com>
>>> wrote:
>>>
>>>> Hi Bruce,
>>>>
>>>> On Mar 22, 2020, at 8:31 AM, Bruce O'Neel <bruce.oneel(a)pckswarms.ch>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Good news, playing with
>>>>
>>>> --enable-fast-bitblt
>>>>
>>>>
>>>> and
>>>>
>>>> --disable-fast-bitblt
>>>>
>>>>
>>>> does work in that it builds a working VM.
>>>>
>>>> Good news/bad news, it does not change the font problem. So that's not
>>>> the problem.
>>>>
>>>>
>>>> Great news. We now know it is an X11 problem and can stop worrying
>>>> about the fast BitBLT code. Thanks.
>>>>
>>>
>>> Looks like the problem, or at least a version of the problem, is nothing
>>> to do with X11. If I open an About Squeak System Reporter in the simulator
>>> (64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM.
>>> So it looks tile the issue is actually in BitBlt itself.
>>>
>>> <SysRepFixedPitch.png>
>>>
>>>
>>>>
>>>> cheers
>>>>
>>>> bruce
>>>>
>>>> *21 March 2020 01:07 tim Rowledge <tim(a)rowledge.org <tim(a)rowledge.org>>
>>>> wrote:*
>>>>
>>>>
>>>>
>>>> > On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
>>>> >
>>>> >
>>>> > I specialize in ridiculous. Good news, I guess, is that I dug up a
>>>> monitor, and, walked it downstairs with a keyboard and mouse and attached
>>>> it. The effect with the BitstreamVeraSans and ComicSans fonts are the same.
>>>> Maybe it likes serfed fonts?
>>>>
>>>> I'm completely baffled by this. I don't get this effect with any ARM vm
>>>> that I have that actually runs, with any image I have.
>>>>
>>>> >
>>>> > So that means that it is not some funky X11 over the wire problem
>>>> with the Mac and Windows X11 servers problem. That's good.
>>>>
>>>> Guess so, though it just makes life weirder.
>>>>
>>>> >
>>>> > I have no idea then why. Are these fonts part of the image? Is it
>>>> some funky binary format that for some reason Coq is mis-reading?
>>>>
>>>> Yes, the font glyphs are in-image. We've been using these ones for
>>>> goodness knows how many years.
>>>>
>>>> >
>>>> > I built a stack VM and I get the same result with a Squeak 5.3 image.
>>>>
>>>> There*shouldn't* be any difference between the stack & cog vms.
>>>>
>>>> You could try building a VM with the fastbitblt turned off I suppose -
>>>> a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related
>>>> lines in the Makefile in you squeak.cog.spur/build directory. I haven't
>>>> actually built an ARM vm without that in years so I don't know it it even
>>>> still works.
>>>>
>>>>
>>>> tim
>>>> --
>>>> tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim
>>>> It is easier to change the specification to fit the program than vice
>>>> versa.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>>
>
--
_,,,^..^,,,_
best, Eliot
Hi,
Currently, Squeak VM binaries files.squeak.org/6.0alpha come with the
Image even though Image is available as a separate zip. The Image
constitutes more than half the download size and is often useless
because I update my image much more frequently than the VM binaries.
Is it possible to exclude the Image from the platform binaries to keep
them slim?
Regards .. Subbu
Hi Tim,
On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda <eliot.miranda(a)gmail.com>
wrote:
> Hi Bruce,
>
> On Mar 22, 2020, at 8:31 AM, Bruce O'Neel <bruce.oneel(a)pckswarms.ch>
> wrote:
>
> Hi,
>
> Good news, playing with
>
> --enable-fast-bitblt
>
>
> and
>
> --disable-fast-bitblt
>
>
> does work in that it builds a working VM.
>
> Good news/bad news, it does not change the font problem. So that's not
> the problem.
>
>
> Great news. We now know it is an X11 problem and can stop worrying about
> the fast BitBLT code. Thanks.
>
Looks like the problem, or at least a version of the problem, is nothing to
do with X11. If I open an About Squeak System Reporter in the simulator
(64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM.
So it looks tile the issue is actually in BitBlt itself.
[image: SysRepFixedPitch.png]
>
>
> cheers
>
> bruce
>
> *21 March 2020 01:07 tim Rowledge <tim(a)rowledge.org <tim(a)rowledge.org>>
> wrote:*
>
>
>
> > On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
> >
> >
> > I specialize in ridiculous. Good news, I guess, is that I dug up a
> monitor, and, walked it downstairs with a keyboard and mouse and attached
> it. The effect with the BitstreamVeraSans and ComicSans fonts are the same.
> Maybe it likes serfed fonts?
>
> I'm completely baffled by this. I don't get this effect with any ARM vm
> that I have that actually runs, with any image I have.
>
> >
> > So that means that it is not some funky X11 over the wire problem with
> the Mac and Windows X11 servers problem. That's good.
>
> Guess so, though it just makes life weirder.
>
> >
> > I have no idea then why. Are these fonts part of the image? Is it some
> funky binary format that for some reason Coq is mis-reading?
>
> Yes, the font glyphs are in-image. We've been using these ones for
> goodness knows how many years.
>
> >
> > I built a stack VM and I get the same result with a Squeak 5.3 image.
>
> There*shouldn't* be any difference between the stack & cog vms.
>
> You could try building a VM with the fastbitblt turned off I suppose -
> a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related
> lines in the Makefile in you squeak.cog.spur/build directory. I haven't
> actually built an ARM vm without that in years so I don't know it it even
> still works.
>
>
> tim
> --
> tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim
> It is easier to change the specification to fit the program than vice
> versa.
>
>
>
>
>
>
>
--
_,,,^..^,,,_
best, Eliot
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 99553e018b7bf1ff01c7ad932b17a8e61fcdd9a1
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/99553e018b7bf1ff01…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2020-04-25 (Sat, 25 Apr 2020)
Changed paths:
M platforms/Cross/plugins/BochsIA32Plugin/sqBochsIA32Plugin.cpp
M platforms/Cross/plugins/BochsX64Plugin/sqBochsX64Plugin.cpp
M processors/IA32/bochs/cpu/cpu.cc
M processors/IA32/bochs/cpu/proc_ctrl.cc
Log Message:
-----------
Fix the x86 & x86_64 simulators after the change to the sideways-jump interpret
invocation uncovered a bug in them. Simplify the run invocation, eliminating
a superfluous setjmp (cpu_loop does a setjmp). Modify the cpu_loop setjmp to
set the stop_reason to the longjmp code. Eliminate a compiler warning in
bochs/cpu/proc_ctrl.cc which needs different printf strings for 32 & 64 bits.
[ci skip]
Eliot Miranda uploaded a new version of Cog to project VM Maker:
http://source.squeak.org/VMMaker/Cog-eem.405.mcz
==================== Summary ====================
Name: Cog-eem.405
Author: eem
Time: 25 April 2020, 8:42:08.457845 pm
UUID: 35edc518-f11b-43f8-90c7-6a93e755e67d
Ancestors: Cog-eem.404
Include MIPS in the hack fix, and fix a comment.
=============== Diff against Cog-eem.404 ===============
Item was changed:
----- Method: GdbARMAlien>>hackFixNextPCOfJumpFor:using: (in category 'execution') -----
hackFixNextPCOfJumpFor: aProcessorSimulationTrap using: objectMemory
"This is a hack fix before we revise the simulators. When a jump call is made, the
+ next pc is effectively the return address in the link reg, not the instruction following
- next pc is effectively the return address on the stack, not the instruction following
the jump. So reset it here. All this is because currently the simulators don't execute
a control transfer to a fake address, as would a real processor. Once the processor
simulators correctly emulate such control transfers, we can ditch this hack."
aProcessorSimulationTrap nextpc: self lr!
Item was added:
+ ----- Method: MIPSSimulator>>hackFixNextPCOfJumpFor:using: (in category 'processor api') -----
+ hackFixNextPCOfJumpFor: aProcessorSimulationTrap using: objectMemory
+ "This is a hack fix before we revise the simulators. When a jump call is made, the
+ next pc is effectively the return address in the link reg, not the instruction following
+ the jump. So reset it here. All this is because currently the simulators don't execute
+ a control transfer to a fake address, as would a real processor. Once the processor
+ simulators correctly emulate such control transfers, we can ditch this hack."
+
+ aProcessorSimulationTrap nextpc: self lr!
Eliot Miranda uploaded a new version of Cog to project VM Maker:
http://source.squeak.org/VMMaker/Cog-eem.404.mcz
==================== Summary ====================
Name: Cog-eem.404
Author: eem
Time: 25 April 2020, 8:38:56.265452 pm
UUID: 61ffd076-549a-4f7f-b1ca-90fd7f70df67
Ancestors: Cog-eem.403
Add the jump-call hack fix for the processor simulators.
=============== Diff against Cog-eem.403 ===============
Item was added:
+ ----- Method: BochsIA32Alien>>hackFixNextPCOfJumpFor:using: (in category 'execution') -----
+ hackFixNextPCOfJumpFor: aProcessorSimulationTrap using: objectMemory
+ "This is a hack fix before we revise the simulators. When a jump call is made, the
+ next pc is effectively the return address on the stack, not the instruction following
+ the jump. So reset it here. All this is because currently the simulators don't execute
+ a control transfer to a fake address, as would a real processor. Once the processor
+ simulators correctly emulate such control transfers, we can ditch this hack."
+
+ aProcessorSimulationTrap nextpc: (objectMemory longAt: self sp)!
Item was added:
+ ----- Method: BochsX64Alien>>hackFixNextPCOfJumpFor:using: (in category 'execution') -----
+ hackFixNextPCOfJumpFor: aProcessorSimulationTrap using: objectMemory
+ "This is a hack fix before we revise the simulators. When a jump call is made, the
+ next pc is effectively the return address on the stack, not the instruction following
+ the jump. So reset it here. All this is because currently the simulators don't execute
+ a control transfer to a fake address, as would a real processor. Once the processor
+ simulators correctly emulate such control transfers, we can ditch this hack."
+
+ aProcessorSimulationTrap nextpc: (objectMemory longAt: self sp)!
Item was added:
+ ----- Method: GdbARMAlien>>hackFixNextPCOfJumpFor:using: (in category 'execution') -----
+ hackFixNextPCOfJumpFor: aProcessorSimulationTrap using: objectMemory
+ "This is a hack fix before we revise the simulators. When a jump call is made, the
+ next pc is effectively the return address on the stack, not the instruction following
+ the jump. So reset it here. All this is because currently the simulators don't execute
+ a control transfer to a fake address, as would a real processor. Once the processor
+ simulators correctly emulate such control transfers, we can ditch this hack."
+
+ aProcessorSimulationTrap nextpc: self lr!