Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 75f466efe6bb05b85f75cba327626f7267713158
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/75f466efe6bb05b85f…
Author: Ronie Salgado <roniesalg(a)gmail.com>
Date: 2019-08-22 (Thu, 22 Aug 2019)
Changed paths:
M cmake/PluginsCommon.cmake
Log Message:
-----------
I fixed a mistake in the compilation of the SqueakSSL plugin in the minheadless VM for Mac.
Commit: 23c3d109be15eacd53d11b04c071267d2b1529a5
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/23c3d109be15eacd53…
Author: Ronie Salgado <roniesalg(a)gmail.com>
Date: 2019-08-22 (Thu, 22 Aug 2019)
Changed paths:
M cmake/PluginsCommon.cmake
Log Message:
-----------
On the minheadless VM that is built using cmake, the add_vm_plugin_sources cmake macro requires specifying the the plugin sources explicitly, which is omitting the src/plugins/SqueakSSL/SqueakSSL.c in the compilation of the plugin. By using the other macro (add_vm_plugin_auto), the platform specific files are automatically found with a glob pattern. This is a mistake that I introduced myself. This problem can be reproduced in Pharo using the minheadless vm of this repository on OS X with the following script:
```smalltalk
url := 'https://google.com' asZnUrl.
ZnClient new
url: url;
get;
response
```
In the case of the minheadless VM for OS X, we are treating the VM as it were an unix since we are removing all of the platform specific windowing code in this VM variant. For this reason, in the cases where OS X is different than another unix, the plugin code has to be added manually.
Commit: 4a3b1d457f4235898f1c43705a0e3222e8420960
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4a3b1d457f4235898f…
Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>
Date: 2019-08-31 (Sat, 31 Aug 2019)
Changed paths:
M cmake/PluginsCommon.cmake
Log Message:
-----------
Merge pull request #419 from ronsaldo/bug/fix-minheadless-squeakssl-mac-build
Minheadless SqueakSSL plugin compilation bug fix
Notes from ronsaldo:
On the minheadless VM that is built using cmake, the add_vm_plugin_sources cmake macro requires specifying the the plugin sources explicitly, which is omitting the src/plugins/SqueakSSL/SqueakSSL.c in the compilation of the plugin. By using the other macro (add_vm_plugin_auto), the platform specific files are automatically found with a glob pattern. This is a mistake that I introduced myself. This problem can be reproduced in Pharo using the minheadless vm of this repository on OS X with the following script:
´´´smalltalk
url := 'https://google.com' asZnUrl.
ZnClient new
url: url;
get;
response
´´´
Additional note: why Mac needs the explicit ${SqueakSSL_Sources} while Windows and Unix don't?
In the case of the minheadless VM for OS X, we are treating the VM as it were an unix since we are removing all of the platform specific windowing code in this VM variant. For this reason, in the cases where OS X is different than another unix, the plugin code has to be added manually.
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/20a361a0f8d4...4a…
Branch: refs/heads/hack_to_restore_b3D_macos32x86
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 4067ad97dd0a0ea031b85918c2ca04594cf3d7e3
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4067ad97dd0a0ea031…
Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>
Date: 2019-08-31 (Sat, 31 Aug 2019)
Changed paths:
M build.macos32x86/common/Makefile.plugin
M build.macos32x86/common/Makefile.vm
A platforms/iOS/plugins/B3DAcceleratorPlugin32/Makefile
A platforms/iOS/plugins/B3DAcceleratorPlugin32/sqMacOpenGL.h
A platforms/iOS/plugins/B3DAcceleratorPlugin32/sqMacOpenGL.m
A platforms/iOS/plugins/B3DAcceleratorPlugin32/zzz/sqMacOpenGL.c
A platforms/iOS/plugins/B3DAcceleratorPlugin32/zzz/sqMacOpenGL.h
A platforms/iOS/plugins/B3DAcceleratorPlugin32/zzz/sqMacOpenGLInfo.c
A platforms/iOS/plugins/B3DAcceleratorPlugin32/zzz/sqMacUIConstants.h
Log Message:
-----------
hack to restore B3DAcceleratorPlugin on macos32x86
This is a temporary hack because MacOS32 is going away soon anyway
It restore the files from 5a38b3483dc5c82c7ecc85a590fdf1b095377a1f
in platforms/iOS/plugins/B3DAcceleratorPlugin32
and hack the build.macos32x86 makefiles to use that
Guille's procrastination experiments inspired me to procrastination of my
own,
with an experiment around debugging Pharo-Headless-Linux-VM using Visual
Studio running on Windows.
I've refined the steps-from-scratch to reproduce down to the following...
Overview...
1. Install Windows Subsystem from Linux
2. Install Visual Studio 2019
3. Build and run hello-world exercise inside WSL
4. Build and run Pharo-Headless-VM inside WSL
Now lets get started...
###############################
Install Windows Subsystem from Linux
###############################
1A. On a Windows 10 box, go to the Windows App Store and Ubuntu 18.04...
Ref: https://docs.microsoft.com/en-us/windows/wsl/install-win10
1B. Ensure this configured as the default (otherwise later the
$defaultWSLPath variable doesn't work and you may see a Visual Studio error
"Could not open windows subsystem shell")...
C:\Users\Ben>wslconfig /l
Windows Subsystem for Linux Distributions:
Legacy (Default)
kali-linux
Ubuntu-18.04
Ubuntu-16.04
C:\Users\Ben>wslconfig /setdefault Ubuntu-18.04
C:\Users\Ben>wslconfig /l
Windows Subsystem for Linux Distributions:
Ubuntu-18.04 (Default)
Legacy
kali-linux
Ubuntu-16.04
Ref:
https://www.howtogeek.com/344688/how-to-set-your-default-linux-distribution…
btw, my Windows 10 box recently upgrade to latest version.
C:\Users\Ben> ver
Microsoft Windows [Version 10.0.18362.295]
1C. Start Ubuntu-18.04, then update/upgrade/install pre-requisites...
```
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install clang gcc gdb make rsync zip # Visual Studio
requirement
sudo apt-get install uuid-dev # Pharo VM build
requirement
```
While that is running...
####################
Install Visual Studio 2019
####################
2A. Download and run the installer for Visual Studio Community 2019 (not
Visual Studio Code)
Ref: https://visualstudio.microsoft.com/free-developer-offers/
2B. When the "Visual Studio Installer" opens, under its "Workloads" tab,
select "Linux development with C++" and click **Install**.
Ref:
https://docs.microsoft.com/en-us/cpp/linux/download-install-and-setup-the-l…
#####################################
Build and run hello-world exercise inside WSL
#####################################
3A. Start Visual Studio 2019
and at its opening window, under "Get started" click "Create a new project".
Then scroll down and choose "CMake Project" and <Next>.
and configure...
Project name: hello-world
then click <Create>.
Ref:
https://docs.microsoft.com/en-us/cpp/linux/cmake-linux-project?view=vs-2019
Now it may immediately start the CMake build and get an error because its
using the default "x64-Debug" configuration.
Ignore that, we will create a new configuration to build on Windows
Subsystem for Linux.
3B. From the "Configuration drop-down" (where you see "x64-Debug")
select "Manage Configurations..."
Delete "x64-Debug".
Add... "WSL-Debug" and use all defaults then press <CTRL-S> to save.
Inside WSL, Cmake will start generating the makefiles.
At some point you might see "Supported CMake version is not present on WSL.
Install CMake binaries built by Microsoft?"
YES, do that.
3C. After "CMake generation finished",
pull down "Select Startup Item" and select "hello-world"
then press the green PLAY button.
Inside WSL, the make build will start and after its done the pharo
executable will run there.
In the [Output] tab, it was successful if you see "The thread
'hello-world' (0x1f7a) has exited with code 0" .
3D. For proof that its running inside WSL, lets write a file!
In the "Solution Explorer" tab, browse to "hello-world.cpp" and change its
contents to...
```
#include <stdio.h>
int main()
{
FILE* fp;
int i;
/* open the file for writing*/
fp = fopen("/tmp/built-by-visual-studio", "w");
fprintf(fp, "It worked.\n");
fclose(fp);
return 0;
}
```
then press the green PLAY button.
After you see "thread 'hello-world' has exited with code 0"
open a WSL shell and run...
$ cat /tmp/built-by-visual-studio
It worked
3E. To experience debugging Linux from Visual Studio, first remove the test
file...
$ rm /tmp/built-by-visual-studio
then put a breakpoint on "fopen" and click the PLAY button.
Check if the file is there...
$ cat /tmp/built-by-visual-studio
cat: /tmp/built-by-visual-studio: No such file or directory
<STEP OVER> fopen
$ cat /tmp/built-by-visual-studio
<STEP OVER> fprintf
$ cat /tmp/built-by-visual-studio
<STEP OVER> fclose
$ cat /tmp/built-by-visual-studio
It worked
3F. All done...
File > Close Folder
#####################################
Build and run Pharo-Headless-VM inside WSL
#####################################
4A. From Visual Studio 2019 opening window, under "Get started" click
"Clone or check out code"
Repository location: https://github.com/bencoman/opensmalltalk-vm.git
then click <Clone>.
https://docs.microsoft.com/en-us/visualstudio/get-started/tutorial-open-pro…
4B. In the bottom-right status bar, click the "branching" icon and choose
"Manage Branches".
Expand "remotes/origin",
then right-click "headless-WSL-VisualStudio" and "Checkout"
A fixed "WSL-Debug" configuration is a part of this branch, so its
CMake-build should auto-start and complete successfully.
4C. After "CMake generation finished",
pull down "Select Startup Item" and select "pharo (build/vm/pharo)"
then press the green PLAY button.
Don't worry if it sits for a long time on
"BalloonEnginePlugin>>primitiveAddRect"
The [Error List] tab pops up with 116 Warnings.
Switching back to the [Output] tab, you hopefully see "thread 'pharo'
(0x4d0d) has exited with code 0"
So the VM just built and ran headless under Windows Subsystem for Linux.
Now lets debug that from Visual Studio.
4D. Browse to src/main.c and put a breakpoint in main() on the call to
parseArguments()
Then click the PLAY button.
Once stopped at the breakpoint, <STEP INTO>.
In the [Autos] tab, expand the "parameters" variable. Observe "imageFile"
is empty.
Notice "imageFile" becomes "Pharo.image" after <STEP OVER>
splitVMAndImageParameters().
So now I leave you to play. I'd be interested in hearing about people's
experiences.
Placing the correct PharoHeadless.image in the right place to actually run
the image
is left as an exercise for the reader.
cheers -ben
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker Inbox:
http://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.2546.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.2546
Author: nice
Time: 29 August 2019, 1:17:48.054344 am
UUID: a6a8d0a3-4f7c-4927-85c1-e99f2c7b2591
Ancestors: VMMaker.oscog-nice.2545
Grrr, fixup
What this invert: dance really serve for?
Due to this, I reread the method twice or thrice, and still make a mistake from time to time...
=============== Diff against VMMaker.oscog-nice.2545 ===============
Item was changed:
----- Method: CogObjectRepresentation>>genPrimitiveLessOrEqual (in category 'primitive generators') -----
genPrimitiveLessOrEqual
^self getPrimitiveDoMixedArithmetic
ifTrue: [self
genSmallIntegerComparison: JumpLessOrEqual
orDoubleComparison: #JumpFPGreaterOrEqual:
+ invert: true]
- invert: false]
ifFalse: [self genSmallIntegerComparison: JumpLessOrEqual]!
Comparison of SmallInteger and Float is simple in Spur32, we just have to convert the SmallInteger to a (double), which is an exact operation, and perform the comparison of (double).
But it's more tricky in Spur64 because SmallInteger has more precision (61 bits) than Float (53 bits) and thus conversion to (double) might be inexact...
Example:
si := 1<<(Float precision + 2)+1.
sf := si asFloat.
self deny: sf = si.
self deny: si = sf.
It's not obvious to find where the trick happens in the VM, because all code at upper level is equivalent to trivial asFloat conversion followed by comparison, and there are many possible path!
Let's concentrate on <=
SmallInteger receiver:
- #primitiveLessOrEqual
- #genPrimitiveLessOrEqual (JIT)
BoxedFloat64 receiver:
- #primitiveFloatLessOrEqual
- #genPrimitiveFloatLessOrEqual (JIT)
SmallFloat64 receiver:
- #primitiveSmallFloatLessOrEqual
- #genPrimitiveSmallFloatLessOrEqual (JIT)
All receivers (non jitted sender or stack VM only?):
- #bytecodePrimLessOrEqual
For generated C code, the protection is programmed in lower level #loadFloatOrIntFrom:
To check that it does not exceed 53 bits, we shift the integer left << and forth >> and verify integrity. If not, we fail the primitive.
With shift length as programmed currently, the primitive will fail for 52 bits and above. It should fail for 54 bits and above, but that's a detail, the primitive will fail more often than necessary...
The problem is that there is no such exactness check for jitted primitives!
I have sketched a solution in Squeak inbox (See http://source.squeak.org/inbox/Kernel-nice.1260.diff), demonstrated here for SmallInteger <=
^(asFloat := self asFloat) = aNumber
ifTrue: [self <= aNumber truncated]
ifFalse: [asFloat <= aNumber]
In C code that is:
if ( (double) si == sf ) return si <= (int64) sf;
else return (double) si <= sf;
It works for all the comparisons (though = and ~= could be a bit simpler, no need to perform the comparison twice).
And it's simple enough to be jitted (I have prototyped it this evening).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/417
Nicolas Cellier uploaded a new version of VMMaker to project VM Maker Inbox:
http://source.squeak.org/VMMakerInbox/VMMaker.oscog-nice.2543.mcz
==================== Summary ====================
Name: VMMaker.oscog-nice.2543
Author: nice
Time: 27 August 2019, 5:42:55.856384 am
UUID: 4d58051c-e032-4926-851a-e04c8f477aa2
Ancestors: VMMaker.oscog-nice.2542
Fixup stupid refactoring bug...
=============== Diff against VMMaker.oscog-nice.2542 ===============
Item was changed:
----- Method: InterpreterPrimitives>>primitiveHighBit (in category 'arithmetic integer primitives') -----
primitiveHighBit
| integerReceiverOop leadingZeroCount highestBitZeroBased |
integerReceiverOop := self stackTop.
"Convert the receiver Oop to use a single tag bit"
self numSmallIntegerTagBits > 1
+ ifTrue: [integerReceiverOop := (integerReceiverOop >>> (self numSmallIntegerTagBits-1) bitOr: 1)].
- ifTrue: [integerReceiverOop := objectMemory integerValueOf: (integerReceiverOop >>> (self numSmallIntegerTagBits-1) bitOr: 1)].
self cppIf: #'__GNUC__' defined
ifTrue:
["Note: in gcc, result is undefined if input is zero (for compatibility with BSR fallback when no CLZ instruction available).
but input is never zero because we pass the oop with tag bits set, so we are safe"
objectMemory wordSize = 4
ifTrue: [leadingZeroCount := self __builtin_clz: integerReceiverOop]
ifFalse: [leadingZeroCount := self __builtin_clzll: integerReceiverOop].
leadingZeroCount = 0
ifTrue:
["highBit is not defined for negative Integer"
self primitiveFail]
ifFalse:
["Nice bit trick: 1-based high-bit is (32 - clz) - 1 to account for tag bit.
This is like two-complement - clz - 1 on 5 bits, or in other words a bit-invert operation clz ^16r1F"
self pop: 1 thenPushInteger: (leadingZeroCount bitXor: (BytesPerWord * 8 - 1))]]
ifFalse: [self cppIf: #'_MSC_VER' defined
ifTrue:
["In MSVC, _lzcnt and _lzcnt64 builtins do not fallback to BSR when not supported by CPU
Instead of messing with __cpuid() we always use the BSR intrinsic"
"Trick: we test the oop sign rather than the integerValue. Assume oop are signed (so far, they are, sqInt are signed)"
integerReceiverOop < 0 ifTrue: [self primitiveFail] ifFalse: [
"Setting this variable is useless, but VMMaker will generate it at a worse place"
highestBitZeroBased := 0.
"We do not even test the return value, because integerReceiverOop is never zero"
objectMemory wordSize = 4
ifTrue: [self _BitScanReverse: highestBitZeroBased address _: integerReceiverOop]
ifFalse: [self _BitScanReverse64: highestBitZeroBased address _: integerReceiverOop].
"thanks to the tag bit, the +1 operation for getting 1-based rank is not necessary"
self pop: 1 thenPushInteger: highestBitZeroBased]]
ifFalse:
["not gcc/clang, nor MSVC, you have to implement if your compiler provide useful builtins"
self primitiveFail]].!