Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
1) this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
2) assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
3) finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
On 19 Oct 2015, at 20:01, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed…
thanks!
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
Look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace You should be able to build a 32bit cog.spur VM using the current Xcode under the current OSX
On Mon, Oct 19, 2015 at 11:01 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
Ok I pushed fixes to deal with a code compile error, plus update the code base so that it does not leak memory when running under the os-x legacy 32bit objective-c runtime. Brave folks could look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace xCode project.
On Mon, Oct 19, 2015 at 11:09 AM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace You should be able to build a 32bit cog.spur VM using the current Xcode under the current OSX
On Mon, Oct 19, 2015 at 11:01 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does
not says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because
(2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ===========================================================================
Hi,
I think this does not solves my problem :(
but… do you think this leaks where present before? I’m using different way to build pharovm (using cmake to generate it, not an xcode project) so I can add the definitions there… but I tried to integrate your changes to my sources and I found that you are using newer objc instructions, so the build with sdk 10.6 (needed to still support leopard) failed (then I reverted, waiting for a better moment to perform this task) … yet, I didn’t tried too much so I don’t know if the error is not fixable in 10.6 or I just missed a configuration.
Any hint?
cheers, Esteban
On 20 Oct 2015, at 03:03, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok I pushed fixes to deal with a code compile error, plus update the code base so that it does not leak memory when running under the os-x legacy 32bit objective-c runtime. Brave folks could look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace xCode project.
On Mon, Oct 19, 2015 at 11:09 AM, John McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote: Look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace You should be able to build a 32bit cog.spur VM using the current Xcode under the current OSX
On Mon, Oct 19, 2015 at 11:01 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
No the leaks are new because I took the original code base and attempted to integrate with Pharo and other forms of the iOS tree and concert to modern obj-c and ARC
Later I discover that the 32 bit OSX legacy objective c runtime does not support ARC. Which means it leaks bytes for cursor changing, file lookup and events.
To fix that some defines that provide the retain, release, autorelease for 32 bit but not 64 bit
Sent from my iPhone
On Oct 19, 2015, at 11:32 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
I think this does not solves my problem :(
but… do you think this leaks where present before? I’m using different way to build pharovm (using cmake to generate it, not an xcode project) so I can add the definitions there… but I tried to integrate your changes to my sources and I found that you are using newer objc instructions, so the build with sdk 10.6 (needed to still support leopard) failed (then I reverted, waiting for a better moment to perform this task) … yet, I didn’t tried too much so I don’t know if the error is not fixable in 10.6 or I just missed a configuration.
Any hint?
cheers, Esteban
On 20 Oct 2015, at 03:03, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok I pushed fixes to deal with a code compile error, plus update the code base so that it does not leak memory when running under the os-x legacy 32bit objective-c runtime. Brave folks could look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace xCode project.
On Mon, Oct 19, 2015 at 11:09 AM, John McIntosh johnmci@smalltalkconsulting.com wrote: Look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace You should be able to build a 32bit cog.spur VM using the current Xcode under the current OSX
On Mon, Oct 19, 2015 at 11:01 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com: > > Hi, > > Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? > For me, a completely broken :( > > 1) this structure (in maybeInlinePositive32BitIntegerFor: and others): > > (integerValue >= 0 > and: [objectMemory isIntegerValue: integerValue]) ifTrue: > [^objectMemory integerObjectOf: integerValue]. > > Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value. > > 2) assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow. > > 3) finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work). > > I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long. > > But for 2 and 3 I have no idea where to start. > > Does anyone has an idea? > > Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
Esteban,
good news, https://github.com/devernay/xcodelegacy supports Xcode 7 and El capitan... So we can still compile a legacy MacCarbon based VM compatible with snow leopard. I ried it, it works and I can run Squeak 5.0 (spur) with such VM.
For my own brand of macosx 32/squeak.cog.spur, it's less glorious. I can compile with latest clang (7), but the image immediately quit when I use this VM (with a correct STARTUP/QUIT log pair in the change log though...).
I'll continue to dig.
2015-10-20 8:32 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
I think this does not solves my problem :(
but… do you think this leaks where present before? I’m using different way to build pharovm (using cmake to generate it, not an xcode project) so I can add the definitions there… but I tried to integrate your changes to my sources and I found that you are using newer objc instructions, so the build with sdk 10.6 (needed to still support leopard) failed (then I reverted, waiting for a better moment to perform this task) … yet, I didn’t tried too much so I don’t know if the error is not fixable in 10.6 or I just missed a configuration.
Any hint?
cheers, Esteban
On 20 Oct 2015, at 03:03, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok I pushed fixes to deal with a code compile error, plus update the code base so that it does not leak memory when running under the os-x legacy 32bit objective-c runtime. Brave folks could look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace xCode project.
On Mon, Oct 19, 2015 at 11:09 AM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace You should be able to build a 32bit cog.spur VM using the current Xcode under the current OSX
On Mon, Oct 19, 2015 at 11:01 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does
not says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because
(2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ===========================================================================
Hi,
On 20 Oct 2015, at 22:43, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Esteban,
good news, https://github.com/devernay/xcodelegacy https://github.com/devernay/xcodelegacy supports Xcode 7 and El capitan... So we can still compile a legacy MacCarbon based VM compatible with snow leopard. I ried it, it works and I can run Squeak 5.0 (spur) with such VM.
In Pharo we do not compile mac carbon VMs since couple of years ago so this is not a big problem for us (thankfully… at least a problem less :P)
cheers, Esteban
For my own brand of macosx 32/squeak.cog.spur, it's less glorious. I can compile with latest clang (7), but the image immediately quit when I use this VM (with a correct STARTUP/QUIT log pair in the change log though...).
I'll continue to dig.
2015-10-20 8:32 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi,
I think this does not solves my problem :(
but… do you think this leaks where present before? I’m using different way to build pharovm (using cmake to generate it, not an xcode project) so I can add the definitions there… but I tried to integrate your changes to my sources and I found that you are using newer objc instructions, so the build with sdk 10.6 (needed to still support leopard) failed (then I reverted, waiting for a better moment to perform this task) … yet, I didn’t tried too much so I don’t know if the error is not fixable in 10.6 or I just missed a configuration.
Any hint?
cheers, Esteban
On 20 Oct 2015, at 03:03, John McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote:
Ok I pushed fixes to deal with a code compile error, plus update the code base so that it does not leak memory when running under the os-x legacy 32bit objective-c runtime. Brave folks could look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace xCode project.
On Mon, Oct 19, 2015 at 11:09 AM, John McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote: Look at Cog/build.macos32x86/squeak.cog.spur and the miosvm script or the SqueakCogSpur32x86.xcworkspace You should be able to build a 32bit cog.spur VM using the current Xcode under the current OSX
On Mon, Oct 19, 2015 at 11:01 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
I regularly sync (merge) with Eliot branch, but I'm a few months behind, not much time recently. Also, I upgraded Xcode to latest version but did not yet tried to compile the VM, so no premature promises... I'll try and have a look and will keep you informed...
cheers
2015-10-19 19:56 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
I don’t know about Eliot, but I cannot wait. Without Alien, I have no FFI with callbacks. Without FFI with callbacks I have no replacement for NativeBoost. Without NativeBoost I have not Athens (and OSWindow) And without those, Pharo cannot migrate to Spur.
So if you have a working version (or partially working), please, share it.
Esteban
On 19 Oct 2015, at 19:48, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
I've changed many of these in my experimental branch when trying to remove lot of UB - but it's not up to date with latest Eliot .oscog versions...
I'd like we review some of these changes, but only if Eliot is ready, he has many things cooking already.
http://smalltalkhub.com/mc/nice/NiceVMExperiments/main http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
2015-10-19 18:31 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
well… I solve the problem. Everything is about the first issue report (comparison is always true). I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression:
intValue bitXor: (intValue << 1)) >= 0
since number fitted in "long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger.
my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. That works.
Now, I have this doubts:
- how is possible this was working before? maybe this is a change in clang 7 (apple)? - now I have a lot of complains of “comparison of unsigned expression is always true” all around the image. Should we take care about them?
I will do some tests and commit to VMMaker tomorrow.
cheers, Esteban
On 19 Oct 2015, at 18:31, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
Ok, you know there is a test plugin squeakSUnitTester (See the *m/h files) I made to check types being passed to/from the Objective-C interface to confirm things are being transferred/received correctly. However I did write something similar for the FFI interface where, or using using Smalltalk code where I iterated over the entire range of +/- 2 billion then edge cases for LargePositive/Negative integers for each point where we added another byte of accuracy for a few bytes. The reasons for that was to confirm that integer conversion was working correctly for all cases when we had migrated to 32bit clean code a decade back.
On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
well… I solve the problem. Everything is about the first issue report (comparison is always true). I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression:
intValue bitXor: (intValue << 1)) >= 0
since number fitted in "long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger.
my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. That works.
Now, I have this doubts:
- how is possible this was working before? maybe this is a change in clang
7 (apple)?
- now I have a lot of complains of “comparison of unsigned expression is
always true” all around the image. Should we take care about them?
I will do some tests and commit to VMMaker tomorrow.
cheers, Esteban
On 19 Oct 2015, at 18:31, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
On Tue, Oct 20, 2015 at 01:48:35PM -0700, John McIntosh wrote:
Ok, you know there is a test plugin squeakSUnitTester (See the *m/h files) I made to check types being passed to/from the Objective-C interface to confirm things are being transferred/received correctly. However I did write something similar for the FFI interface where, or using using Smalltalk code where I iterated over the entire range of +/- 2 billion then edge cases for LargePositive/Negative integers for each point where we added another byte of accuracy for a few bytes. The reasons for that was to confirm that integer conversion was working correctly for all cases when we had migrated to 32bit clean code a decade back.
Hi John,
It wasn't really a decade back. Well not quite ;-)
Your mention of the FFI interface reminds me of the work we did to make the old FFI 32/64 bit clean. We never got that harvested into the VM, but the patches circa 2008 are still out there on the Mantis report at http://bugs.squeak.org/view.php?id=7237
I truly do not know if this has relevance any more, but maybe you and Eliot could comment? There were pointer size issues that had to be addressed in the image as well as in the plugin and support code, so some of it might still be of interest.
Dave
Hi David,
On Tue, Oct 20, 2015 at 3:20 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 20, 2015 at 01:48:35PM -0700, John McIntosh wrote:
Ok, you know there is a test plugin squeakSUnitTester (See the *m/h
files)
I made to check types being passed to/from the Objective-C interface to confirm things are being transferred/received correctly. However I did write something similar for the FFI interface where, or using using Smalltalk code where I iterated over the entire range of +/- 2 billion
then
edge cases for LargePositive/Negative integers for each point where we added another byte of accuracy for a few bytes. The reasons for that
was
to confirm that integer conversion was working correctly for all cases
when
we had migrated to 32bit clean code a decade back.
Hi John,
It wasn't really a decade back. Well not quite ;-)
Your mention of the FFI interface reminds me of the work we did to make the old FFI 32/64 bit clean. We never got that harvested into the VM, but the patches circa 2008 are still out there on the Mantis report at http://bugs.squeak.org/view.php?id=7237
I truly do not know if this has relevance any more, but maybe you and Eliot could comment? There were pointer size issues that had to be addressed in the image as well as in the plugin and support code, so some of it might still be of interest.
I *think* that the new ThreadedFFIPlugin-derived FFIs are 32/64-bit clean but its not been tested thoroughly. These plugins don't use any assembly, compile to pure C with perhaps two asm statements in them to get/set the stack pointer if alloca doesn't do exactly the right thing. But there's no code in there that assumes 32-bit sizes. We'll know soon enough.
Dave
On Tue, Oct 20, 2015 at 03:23:37PM -0700, Eliot Miranda wrote:
Hi David,
On Tue, Oct 20, 2015 at 3:20 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 20, 2015 at 01:48:35PM -0700, John McIntosh wrote:
Ok, you know there is a test plugin squeakSUnitTester (See the *m/h
files)
I made to check types being passed to/from the Objective-C interface to confirm things are being transferred/received correctly. However I did write something similar for the FFI interface where, or using using Smalltalk code where I iterated over the entire range of +/- 2 billion
then
edge cases for LargePositive/Negative integers for each point where we added another byte of accuracy for a few bytes. The reasons for that
was
to confirm that integer conversion was working correctly for all cases
when
we had migrated to 32bit clean code a decade back.
Hi John,
It wasn't really a decade back. Well not quite ;-)
Your mention of the FFI interface reminds me of the work we did to make the old FFI 32/64 bit clean. We never got that harvested into the VM, but the patches circa 2008 are still out there on the Mantis report at http://bugs.squeak.org/view.php?id=7237
I truly do not know if this has relevance any more, but maybe you and Eliot could comment? There were pointer size issues that had to be addressed in the image as well as in the plugin and support code, so some of it might still be of interest.
I *think* that the new ThreadedFFIPlugin-derived FFIs are 32/64-bit clean but its not been tested thoroughly. These plugins don't use any assembly, compile to pure C with perhaps two asm statements in them to get/set the stack pointer if alloca doesn't do exactly the right thing. But there's no code in there that assumes 32-bit sizes. We'll know soon enough.
Getting rid of the assembly bindings is a welcome change.
On the image side, class ExternalAddress needed to do the right thing for various pointer sizes. A patch for that is in Mantis 7237, so I can extract it if you think it may still be relevant.
Dave
On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
well… I solve the problem. Everything is about the first issue report (comparison is always true). I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression:
intValue bitXor: (intValue << 1)) >= 0
since number fitted in "long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger.
my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. That works.
No, you can't cast within maybeInlinePositive32BitIntegerFor:. That will break its use on long long values.
Now, I have this doubts:
- how is possible this was working before? maybe this is a change in clang
7 (apple)?
Unless we look in the debugger we won't know.
- now I have a lot of complains of “comparison of unsigned expression is
always true” all around the image. Should we take care about them?
Looks like it.
I will do some tests and commit to VMMaker tomorrow.
Don't just blindly commit a fix that makes clang 7 work. It could easily break everything elsewhere. Instead, we need to understand the issues first.
cheers, Esteban
On 19 Oct 2015, at 18:31, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
On 20 Oct 2015, at 23:28, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
well… I solve the problem. Everything is about the first issue report (comparison is always true). I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression:
intValue bitXor: (intValue << 1)) >= 0
since number fitted in "long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger.
my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. That works.
No, you can't cast within maybeInlinePositive32BitIntegerFor:. That will break its use on long long values.
but now does not work, because compiler says it is always true (any unsigned comparison to >= 0 will always evaluate to true for clang). Unsigned long is always >= 0. And with long long values (sqLong) always fit, so is also always true.
I can of course ensure the type of parameter passed to maybeInlinePositive32BitIntegerFor before (not in the method). That will fulfil your requirement of not cast the function.
Now, I have this doubts:
- how is possible this was working before? maybe this is a change in clang 7 (apple)?
Unless we look in the debugger we won't know.
I spent last 3 days doing it. #maybeInlinePositive32BitIntegerFor: was always “inlining”.
- now I have a lot of complains of “comparison of unsigned expression is always true” all around the image. Should we take care about them?
Looks like it.
So this is a major problem, I think… I will check.
Esteban
I will do some tests and commit to VMMaker tomorrow.
Don't just blindly commit a fix that makes clang 7 work. It could easily break everything elsewhere. Instead, we need to understand the issues first.
cheers, Esteban
On 19 Oct 2015, at 18:31, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
-- _,,,^..^,,,_ best, Eliot
Hi Esteban,
On Tue, Oct 20, 2015 at 2:37 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:28, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
well… I solve the problem. Everything is about the first issue report (comparison is always true). I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression:
intValue bitXor: (intValue << 1)) >= 0
since number fitted in "long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger.
my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. That works.
No, you can't cast within maybeInlinePositive32BitIntegerFor:. That will break its use on long long values.
but now does not work, because compiler says it is always true (any unsigned comparison to >= 0 will always evaluate to true for clang). Unsigned long is always >= 0.
Yes. But if called with a saint it won't be. What's the context? This thing is used in lots of places. Please tell me where you're finding the problem.
And with long long values (sqLong) always fit, so is also always true.
OK, so is what you're saying that
isIntegerValue: intValue "Answer if the given value can be represented as a Smalltalk integer value. In C, use a shift and XOR to set the sign bit if and only if the top two bits of the given value are the same, then test the sign bit. Note that the top two bits are equal for exactly those integers in the range that can be represented in 31-bits or 63-bits." <api> ^self cCode: [(intValue bitXor: (intValue << 1)) >= 0] inSmalltalk: [intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]]
doesn't work for other than 32-bit values in clang? Looks like this needs to be smarter. If it is called with squints then it is fine, but if called with long long or unsigned long long we need to use the Smalltalk code:
intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]
Slang can be (carefully) modified to do this. But please, I need some specific examples, not just "it doesn't work". I need to know where it doesn't work, because in many places it works just fine, and changing things willy nilly is not the right thing to do (tm).
I can of course ensure the type of parameter passed to maybeInlinePositive32BitIntegerFor before (not in the method). That will fulfil your requirement of not cast the function.
Now, I have this doubts:
- how is possible this was working before? maybe this is a change in
clang 7 (apple)?
Unless we look in the debugger we won't know.
I spent last 3 days doing it. #maybeInlinePositive32BitIntegerFor: was always “inlining”.
- now I have a lot of complains of “comparison of unsigned expression is
always true” all around the image. Should we take care about them?
Looks like it.
So this is a major problem, I think… I will check.
Esteban
I will do some tests and commit to VMMaker tomorrow.
Don't just blindly commit a fix that makes clang 7 work. It could easily break everything elsewhere. Instead, we need to understand the issues first.
cheers, Esteban
On 19 Oct 2015, at 18:31, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
-- _,,,^..^,,,_ best, Eliot
2015-10-20 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
well… I solve the problem. Everything is about the first issue report (comparison is always true). I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression:
intValue bitXor: (intValue << 1)) >= 0
since number fitted in "long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger.
my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. That works.
No, you can't cast within maybeInlinePositive32BitIntegerFor:. That will break its use on long long values.
Hi Eliot, but when would you pass unsigned long long > 16rFFFFFFFFUL ? In most case that would be positiveMachineIntegerFor: as you said...
Now, I have this doubts:
- how is possible this was working before? maybe this is a change in
clang 7 (apple)?
Unless we look in the debugger we won't know.
- now I have a lot of complains of “comparison of unsigned expression is
always true” all around the image. Should we take care about them?
Looks like it.
I will do some tests and commit to VMMaker tomorrow.
Don't just blindly commit a fix that makes clang 7 work. It could easily break everything elsewhere. Instead, we need to understand the issues first.
cheers, Esteban
On 19 Oct 2015, at 18:31, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
-- _,,,^..^,,,_ best, Eliot
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
On 20 Oct 2015, at 22:59, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 22:59, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ===========================================================================
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
On 20 Oct 2015, at 22:59, John McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
-- _,,,^..^,,,_ best, Eliot
On 20 Oct 2015, at 23:50, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
On 20 Oct 2015, at 22:59, John McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
btw the compiler warnings about this all the time, not just on sendInvokeCallbackContext:… that’s why I wonder how this is possible to work before :(
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
-- _,,,^..^,,,_ best, Eliot
On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:50, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 22:59, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
btw the compiler warnings about this all the time, not just on sendInvokeCallbackContext:… that’s why I wonder how this is possible to work before :(
Maybe it was only working before because of the address range in which callbackContext occurred. Maybe in el capital the stack is in a different place in memory and now it breaks things.
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
_,,,^..^,,,_
best, Eliot
_,,,^..^,,,_
best, Eliot
Doesn't the problem come from not respecting signedness when inlining? Or from having incompatible type hint in caller/callee when inlining?
If signedness differs, there the callee parameter should be inlined with a different variable and an explicit cast. Most time, we should arrange to not have a signedness difference. That's what I'm trying to achieve in my experimental branch. But it's soliloquy..
2015-10-20 23:59 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:50, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 22:59, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
btw the compiler warnings about this all the time, not just on sendInvokeCallbackContext:… that’s why I wonder how this is possible to work before :(
Maybe it was only working before because of the address range in which callbackContext occurred. Maybe in el capital the stack is in a different place in memory and now it breaks things.
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does
not says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because
(2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
_,,,^..^,,,_
best, Eliot
_,,,^..^,,,_
best, Eliot
On Tue, Oct 20, 2015 at 3:05 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Doesn't the problem come from not respecting signedness when inlining?
This is really tricky. It's really useful to have the inlined not enforce signedness or unsignedness when inlining because that allows the types to propagate through, which is most often what you want. This gets even more difficult when trying to make the code work for both 32-bits and 64-bits. Right now Slang is poised "just so" and I have a working 32-bit and 64-bit Spur system. But it took a long struggle last year, a day of which I spent with Bert at the CDG, to get it to work.
Or from having incompatible type hint in caller/callee when inlining?
That's more likely. If the type must be specified then it must be specified in the code with a type pragma. The problem is that lots of the time, the type must be specified very carefully. One can't just cast to (signed) because that actually means (signed int), which will truncate long long, or 64-bit long values.
If signedness differs, there the callee parameter should be inlined with a different variable and an explicit cast. Most time, we should arrange to not have a signedness difference. That's what I'm trying to achieve in my experimental branch. But it's soliloquy..
Well, if you're wrestling with this you know how difficult it is too.
2015-10-20 23:59 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:50, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 22:59, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
btw the compiler warnings about this all the time, not just on sendInvokeCallbackContext:… that’s why I wonder how this is possible to work before :(
Maybe it was only working before because of the address range in which callbackContext occurred. Maybe in el capital the stack is in a different place in memory and now it breaks things.
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm@gmail.com
wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does
not says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because
(2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
_,,,^..^,,,_
best, Eliot
_,,,^..^,,,_
best, Eliot
2015-10-21 0:11 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 20, 2015 at 3:05 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Doesn't the problem come from not respecting signedness when inlining?
This is really tricky. It's really useful to have the inlined not enforce signedness or unsignedness when inlining because that allows the types to propagate through, which is most often what you want. This gets even more difficult when trying to make the code work for both 32-bits and 64-bits. Right now Slang is poised "just so" and I have a working 32-bit and 64-bit Spur system. But it took a long struggle last year, a day of which I spent with Bert at the CDG, to get it to work.
Yes great progress with type inference! Maybe type inference should not prematurely freeze at method level: some inlined methods might be generic (unless containing explicit type hint pragma). It's like inference should take place in inlined code IMO.
Or from having incompatible type hint in caller/callee when inlining?
That's more likely. If the type must be specified then it must be specified in the code with a type pragma. The problem is that lots of the time, the type must be specified very carefully. One can't just cast to (signed) because that actually means (signed int), which will truncate long long, or 64-bit long values.
Esteban warning comes from this:
the caller of positive32BitInteger: passed a usqInt (either by type inference or explicit pragma hint) positive32BitInteger: expects a sqInt inlining replace the sqInt parameter with the usqInt caller variable.
I say positive32BitInteger: should expect a usqInt -- or maybe an unsigned int (32bits) - but this require further analysis for 64bits VM -- Because no sender will ever invoke positive32BitInteger: with a negative long... I use this for 2 years now and it works well in 32bits stack/cog v3/spur and even in legacy interpreter vm. I'll check again for 64bits VM
This case is an easy one, but there are more subtle traps for sure...
If signedness differs, there the callee parameter should be inlined with a different variable and an explicit cast. Most time, we should arrange to not have a signedness difference. That's what I'm trying to achieve in my experimental branch. But it's soliloquy..
Well, if you're wrestling with this you know how difficult it is too.
2015-10-20 23:59 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:50, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano <estebanlm@gmail.com
wrote:
On 20 Oct 2015, at 22:59, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
btw the compiler warnings about this all the time, not just on sendInvokeCallbackContext:… that’s why I wonder how this is possible to work before :(
Maybe it was only working before because of the address range in which callbackContext occurred. Maybe in el capital the stack is in a different place in memory and now it breaks things.
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano < estebanlm@gmail.com> wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and
others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does
not says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because
(2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
_,,,^..^,,,_
best, Eliot
_,,,^..^,,,_
best, Eliot
-- _,,,^..^,,,_ best, Eliot
On Wed, Oct 21, 2015 at 5:59 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 20, 2015 at 2:54 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:50, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 22:59, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
btw the compiler warnings about this all the time, not just on sendInvokeCallbackContext:… that’s why I wonder how this is possible to work before :(
Maybe it was only working before because of the address range in which callbackContext occurred. Maybe in el capital the stack is in a different place in memory and now it breaks things.
Maybe address space layout randomisation, depending on which older OSX version is being used for comparison, it seems to have evolved over a few versions. Maybe something subtle changed under the hood in the latest. * https://en.wikipedia.org/wiki/Address_space_layout_randomization#OS_X * http://tinyurl.com/osx-aslr cheers -ben
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
_,,,^..^,,,_ best, Eliot
_,,,^..^,,,_ best, Eliot
On Tue, Oct 20, 2015 at 2:50 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 20 Oct 2015, at 22:59, John McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
Right. So (integerValue ^ (integerValue << 1)) >= 0 must read (long)(integerValue ^ (integerValue << 1)) >= 0. So we probably need isIntegerValue: to read
isIntegerValue: intValue "Answer if the given value can be represented as a Smalltalk integer value. In C, use a shift and XOR to set the sign bit if and only if the top two bits of the given value are the same, then test the sign bit. Note that the top two bits are equal for exactly those integers in the range that can be represented in 31-bits or 63-bits." <api> ^self cCode: [(intValue bitXor: (intValue << 1)) *asInteger* >= 0] inSmalltalk: [intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]]
I'll be able to test thing change soon.
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
-- _,,,^..^,,,_ best, Eliot
On 20 Oct 2015, at 23:57, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 20, 2015 at 2:50 PM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
On 20 Oct 2015, at 23:35, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> wrote:
Hi Esteban,
On Tue, Oct 20, 2015 at 2:23 PM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
On 20 Oct 2015, at 22:59, John McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
I’m not using maybeInlinePositive32BitIntegerFor for anything. Is Eliot who is doing it :) But yes, I thought that first, then I followed the logic and figured out the intent was kept just changing the input type… but I might be wrong… Eliot should know better :)
what's the context?
I spotted the problem when calling
sendInvokeCallbackContext:
in concrete, when doing this:
self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger).
positiveMachineIntegerFor: always inlines the callback context (answering then a random position in memory).
and after analysis, I found that the casting of oop with “unsigned long” makes that the two comparisons in:
if ((integerValue >= 0) && ((integerValue ^ (integerValue << 1)) >= 0)) { object3 = ((integerValue << 1) | 1); goto l12; }
always evaluates to true, no matter the value it receives.
Right. So (integerValue ^ (integerValue << 1)) >= 0 must read (long)(integerValue ^ (integerValue << 1)) >= 0. So we probably need isIntegerValue: to read
isIntegerValue: intValue "Answer if the given value can be represented as a Smalltalk integer value. In C, use a shift and XOR to set the sign bit if and only if the top two bits of the given value are the same, then test the sign bit. Note that the top two bits are equal for exactly those integers in the range that can be represented in 31-bits or 63-bits."
<api> ^self cCode: [(intValue bitXor: (intValue << 1)) asInteger >= 0] inSmalltalk: [intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]]
I'll be able to test thing change soon.
it is working for me (at least on first pass) :)
Esteban
Esteban
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
assertCStackWellAligned always fail. No idea why because if does not says anything, just jmp back to the regular flow.
finally, ceCaptureCStackPointers also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk https://www.linkedin.com/in/smalltalk
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
The analysis I performed in 2013 was this one:
positive32BitIntegerFor: takes a positive 32 bit C integer, and make a Smalltalk integer object out of it (possibly a LargePositiveInteger in 32 bits VM)
The intention is clearly to pass a uint32 parameter, so the parameter must be unsigned and there is no point in testing if parameter is > 0. AFAIR, all the send sites in VMMaker/plugins were in accordance with this, but I changed many type int in senders I made this change and I had a working VM passing all the tests.
For 64 bits VM, this should probably be an unsigned int (not a usqInt which is too long).
2015-10-20 22:59 GMT+02:00 John McIntosh johnmci@smalltalkconsulting.com:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ===========================================================================
Hi John,
On Tue, Oct 20, 2015 at 1:59 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
No, we don't need this. Looking at the code, it is OK for positive32BitIntegerFor: to truncate to 32-bits. But if one wants to pass in a 32-bit value form a long one should write
^self positive32BitIntegerFor: (value bitAnd: 16rFFFFFFFF)
If one wants a value which is as big as a pointer one should use
^self positiveMachineIntegerFor: (value bitAnd: 16rFFFFFFFF)
Only use the 32Bit conversion routines when you want a 32-bit result. There are now 32-bit, 64-bit and machine versions of the conversion routines. The machine versions answer 32 or 64 bit results as appropriate.
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ===========================================================================
Sure but I see the follow use cases, which are best confusing, and just curious if they work as you think they should? Does clang optimize out the (value >= 0) if value is a unsigned type?
/* begin maybeInlinePositive32BitIntegerFor: */
assert(!((hasSixtyFourBitImmediates())));
if ((stackPtr >= 0)
&& ((stackPtr ^ (stackPtr << 1)) >= 0)) {
((stackPtr << 1) | 1);
goto l2;
} where stackPtr is sendInvokeCallbackStackRegistersJmpbuf(sqInt thunkPtr, sqInt stackPtr, sqInt regsPtr, sqInt jmpBufPtr)
or where integerValue is saint btw so casting to usqInt then back to saint is 'magic handwaving?'
integerValue = ((usqInt)usecs);
/* begin maybeInlinePositive32BitIntegerFor: */
assert(!((hasSixtyFourBitImmediates())));
if ((integerValue >= 0)
&& ((integerValue ^ (integerValue << 1)) >= 0)) {
v1 = ((integerValue << 1) | 1);
goto l1;
}
or this where value is declared as 'unsigned long' versus a squeak data type
value = ((usqInt)((vmCallbackContext->thunkp)));
/* begin positive32BitIntegerFor: */
/* begin maybeInlinePositive32BitIntegerFor: */
assert(!((hasSixtyFourBitImmediates())));
if ((value >= 0)
&& ((value ^ (value << 1)) >= 0)) {
((value << 1) | 1);
goto l2;
}
On Tue, Oct 20, 2015 at 2:34 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi John,
On Tue, Oct 20, 2015 at 1:59 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
No, we don't need this. Looking at the code, it is OK for positive32BitIntegerFor: to truncate to 32-bits. But if one wants to pass in a 32-bit value form a long one should write
^self positive32BitIntegerFor: (value bitAnd: 16rFFFFFFFF)
If one wants a value which is as big as a pointer one should use
^self positiveMachineIntegerFor: (value bitAnd: 16rFFFFFFFF)
Only use the 32Bit conversion routines when you want a 32-bit result. There are now 32-bit, 64-bit and machine versions of the conversion routines. The machine versions answer 32 or 64 bit results as appropriate.
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
-- _,,,^..^,,,_ best, Eliot
Hi John, Hi Esteban,
On Tue, Oct 20, 2015 at 2:48 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Sure but I see the follow use cases, which are best confusing, and just curious if they work as you think they should? Does clang optimize out the (value >= 0) if value is a unsigned type?
/* begin maybeInlinePositive32BitIntegerFor: */
assert(!((hasSixtyFourBitImmediates())));
if ((stackPtr >= 0)
&& ((stackPtr ^ (stackPtr << 1)) >= 0)) {
((stackPtr << 1) | 1);
goto l2;
} where stackPtr is sendInvokeCallbackStackRegistersJmpbuf(sqInt thunkPtr, sqInt stackPtr, sqInt regsPtr, sqInt jmpBufPtr)
or where integerValue is saint btw so casting to usqInt then back to saint is 'magic handwaving?'
integerValue = ((usqInt)usecs);
/* begin maybeInlinePositive32BitIntegerFor: */
assert(!((hasSixtyFourBitImmediates())));
if ((integerValue >= 0)
&& ((integerValue ^ (integerValue << 1)) >= 0)) {
v1 = ((integerValue << 1) | 1);
goto l1;
}
or this where value is declared as 'unsigned long' versus a squeak data type
value = ((usqInt)((vmCallbackContext->thunkp)));
/* begin positive32BitIntegerFor: */
/* begin maybeInlinePositive32BitIntegerFor: */
assert(!((hasSixtyFourBitImmediates())));
if ((value >= 0)
&& ((value ^ (value << 1)) >= 0)) {
((value << 1) | 1);
goto l2;
}
So first of all, this code is out of date. This method should read the following; notice the use of positiveMachineIntegerValueOf:, not positive32BitIntegerFor:
sendInvokeCallback: thunkPtr Stack: stackPtr Registers: regsPtr Jmpbuf: jmpBufPtr "Send the 4 argument callback message invokeCallback:stack:registers:jmpbuf: to Alien class with the supplied args. The arguments are raw C addresses and are converted to integer objects on the way." <export: true> | classTag | classTag := self fetchClassTagOfNonImm: (self splObj: ClassAlien). messageSelector := self splObj: SelectorInvokeCallback. argumentCount := 4. (self lookupInMethodCacheSel: messageSelector classTag: classTag) ifFalse: [(self lookupOrdinaryNoMNUEtcInClass: (objectMemory classForClassTag: classTag)) ~= 0 ifTrue: [^false]]. ((self argumentCountOf: newMethod) = 4 and: [primitiveFunctionPointer = 0]) ifFalse: [^false]. self push: (self splObj: ClassAlien). "receiver" self push: (self positiveMachineIntegerFor: thunkPtr). self push: (self positiveMachineIntegerFor: stackPtr). self push: (self positiveMachineIntegerFor: regsPtr). self push: (self positiveMachineIntegerFor: jmpBufPtr). self ifAppropriateCompileToNativeCode: newMethod selector: messageSelector. self justActivateNewMethod. (self isMachineCodeFrame: framePointer) ifFalse: [self maybeFlagMethodAsInterpreted: newMethod]. self externalWriteBackHeadFramePointers. self handleStackOverflow. self enterSmalltalkExecutiveFromCallback. "not reached" ^true
Second of all, this whole method is obsolete. It's there for old-style Alien callbacks. You should be using new-style Alien callbacks that use invokeCallbackContext: and sendInvokeCallbackContext:.
sendInvokeCallbackContext: vmCallbackContext "Send the calllback message to Alien class with the supplied arg(s). Use either the 1 arg invokeCallbackContext: or the 4 arg invokeCallback:stack:registers:jmpbuf: message, depending on what selector is installed in the specialObjectsArray. Note that if invoking the legacy invokeCallback:stack:registers:jmpbuf: we pass the vmCallbackContext as the jmpbuf argument (see reestablishContextPriorToCallback:). The arguments are raw C addresses and are converted to integer objects on the way." <export: true> <var: #vmCallbackContext type: #'VMCallbackContext *'> | classTag | classTag := self fetchClassTagOfNonImm: (self splObj: ClassAlien). messageSelector := self splObj: SelectorInvokeCallback. (self lookupInMethodCacheSel: messageSelector classTag: classTag) ifFalse: [(self lookupOrdinaryNoMNUEtcInClass: (objectMemory classForClassTag: classTag)) ~= 0 ifTrue: [^false]]. primitiveFunctionPointer ~= 0 ifTrue: [^false]. self saveCStackStateForCallbackContext: vmCallbackContext. self push: (self splObj: ClassAlien). "receiver" (self argumentCountOf: newMethod) = 4 ifTrue: [self push: (self positiveMachineIntegerFor: vmCallbackContext thunkp asUnsignedInteger). self push: (self positiveMachineIntegerFor: vmCallbackContext stackp asUnsignedInteger). self push: (self positiveMachineIntegerFor: vmCallbackContext intregargsp asUnsignedInteger)]. self push: (self positiveMachineIntegerFor: vmCallbackContext asUnsignedInteger). self ifAppropriateCompileToNativeCode: newMethod selector: messageSelector. self justActivateNewMethod. (self isMachineCodeFrame: framePointer) ifFalse: [self maybeFlagMethodAsInterpreted: newMethod]. self externalWriteBackHeadFramePointers. self handleStackOverflow. self enterSmalltalkExecutiveFromCallback. "not reached" ^true
On Tue, Oct 20, 2015 at 2:34 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi John,
On Tue, Oct 20, 2015 at 1:59 PM, John McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, you know you are using maybeInlinePositive32BitIntegerFor for BOTH unsigned and signed integers? That to me rings alarm bells, so do you need maybeInlinePositive32BitIntegerForSignedInteger or maybeInlinePositive32BitIntegerForUnSignedInteger or always cast the incoming value to an unsigned integer, or is it signed? If so are you sure you understand the math involved and the possible input values?
No, we don't need this. Looking at the code, it is OK for positive32BitIntegerFor: to truncate to 32-bits. But if one wants to pass in a 32-bit value form a long one should write
^self positive32BitIntegerFor: (value bitAnd: 16rFFFFFFFF)
If one wants a value which is as big as a pointer one should use
^self positiveMachineIntegerFor: (value bitAnd: 16rFFFFFFFF)
Only use the 32Bit conversion routines when you want a 32-bit result. There are now 32-bit, 64-bit and machine versions of the conversion routines. The machine versions answer 32 or 64 bit results as appropriate.
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
- assertCStackWellAligned always fail. No idea why because if does
not says anything, just jmp back to the regular flow.
- finally, ceCaptureCStackPointers also fails… this can be because
(2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long.
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Esteban
--
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================
-- _,,,^..^,,,_ best, Eliot
--
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk ===========================================================================
Hi Esteban,
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
Right, but oops are squints which are signed, so this shouldn't be a problem. We can't safely cast the value to signed because, unless we know the size of the integer, we may truncate it. e.g. (signed)integerValue is equivalent to (int)integerValue, and if integerValue were 64-bits the cast could cause the wrong answer.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
Put a breakpoint in warning and then you can see what the problem is.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
Right. The stack should be properly aligned on a 128-bit/16-byte boundary for SSE instructions to work correctly. So you need to step through the code generated for ceCaptureCStackPointers,and look at the execution state when assertCStackWellAlignedis evaluated. For this you must use a debugger and puzzle out the code at the machine level.
I guess solution of (1) is easy: argument number just has to be a sqLong
instead an unsigned long.
Right. Extremely important :-)
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Roll your sleeves up and dive in with gdb/lldb. And you can contact me via Skype or FaceTime if you want to talk it through and let me look over your shoulder.
Esteban
_,,,^..^,,,_ best, Eliot
Right. The stack should be properly aligned on a 128-bit/16-byte boundary
for SSE instructions to work correctly.
Note when we developed Sophie we found the quicktime engineers took advantage of this 16 byte boundary alignment and for some FFI quicktime calls would cleverly say oh look we need 4 bytes, and gee we know we have X input parms, but because the stack is aligned why there is four bytes FREE up there to use as working space so we avoid some sort of allocation or stack adjustment! This of course trashes something on the stack, usually an OOPS value, and crash happens a bit later...
On Tue, Oct 20, 2015 at 2:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Esteban,
On Mon, Oct 19, 2015 at 9:31 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi,
Does anyone tested Alien on Spur and "El capitan"? specifically callbacks? For me, a completely broken :(
- this structure (in maybeInlinePositive32BitIntegerFor: and others):
(integerValue >= 0 and: [objectMemory isIntegerValue: integerValue]) ifTrue: [^objectMemory integerObjectOf: integerValue].
Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value.
Right, but oops are squints which are signed, so this shouldn't be a problem. We can't safely cast the value to signed because, unless we know the size of the integer, we may truncate it. e.g. (signed)integerValue is equivalent to (int)integerValue, and if integerValue were 64-bits the cast could cause the wrong answer.
- assertCStackWellAligned always fail. No idea why because if does not
says anything, just jmp back to the regular flow.
Put a breakpoint in warning and then you can see what the problem is.
- finally, ceCaptureCStackPointers also fails… this can be because (2)
or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work).
Right. The stack should be properly aligned on a 128-bit/16-byte boundary for SSE instructions to work correctly. So you need to step through the code generated for ceCaptureCStackPointers,and look at the execution state when assertCStackWellAlignedis evaluated. For this you must use a debugger and puzzle out the code at the machine level.
I guess solution of (1) is easy: argument number just has to be a sqLong
instead an unsigned long.
Right. Extremely important :-)
But for 2 and 3 I have no idea where to start.
Does anyone has an idea?
Roll your sleeves up and dive in with gdb/lldb. And you can contact me via Skype or FaceTime if you want to talk it through and let me look over your shoulder.
Esteban
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org