Hi,
The latest VM that I build from open-smalltalk VM 2278 or 2280 does not work (Stack overflow at start-up OR bugged UI with strange color making any text impossible to read). I have the problem on 2 different computers, Mac OS X and Linux. I am able to build successfully the VM from 2274 but I can do it only with a previous version of the platform files (else I got a linking error - scavengeLog: used but not implemented). I am not sure the problem comes from the recent platform files or the recent changes in the VMMaker packages since they need each other to be able to be compiled. What is the right way to work around this problem ? I am about to commit on VMMaker package Sista update but I cannot merge with 2280 since I can't compile a working VM from there, so I'll commit without merging if I cannot solve this problem |
Hi Clement, I let a comment on line 1972 of src/plugins/BitBltPlugin/BitBltPlugin.c on commit https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1dd1a9c0d61ed1c367fb226e59ce0386af3bf5ed 2017-11-23 17:00 GMT+01:00 Clément Bera <[hidden email]>:
|
Hmm, I tried to fix declaration of unskew, but it does not seem enough... 2017-11-23 21:06 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
I can generate a working Win64 squeak cog spur VM at least up to VMMaker.oscog-cb.2272, no time to finish bissecting right now... 2017-11-24 11:37 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
Since I experienced mangled display when generating source with VMMaker.oscog-cb.2274, I suspect that the problem is related to genPrimitiveStringReplace introduced in VMMaker.oscog-cb.22732017-11-24 16:45 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
Hmm, my bad, I fail to find a bug in genPrimitiveStringReplace It appears that I messed up with git client... (bissecting on two different machines is not a good idea anyway) What I find now is this:- mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and src/plugins/* from head is not OK (mangled) - mac osx 64 squeak.cog.spur generated with VMMaker.oscog-cb.2274 and src/plugins/* taken from old commit is OK https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3010e4465405f6ec7a289fc3a3d21eb324816a8f#diff-2ecd46f56f9702ad7a50219dd086a8c5 So that's at least two different problems, one in the plugins, one in 2017-11-25 22:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
2017-11-26 16:20 GMT+01:00 Nicolas Cellier <[hidden email]>:
The problem in generated plugins is in MiscPrimitivePlugin.c There are not many changes, so I'll see if I can identify the problem and fix it in VMMaker. Then there will be the problem of the 64bit cog spur vm...
|
2017-11-26 16:40 GMT+01:00 Nicolas Cellier <[hidden email]>:
So I have fixed the code of primitiveDecompressFromByteArray from MiscPrimitivePlugin but IT'S NOT IN VMMaker... I fixed the Squeak trunk version (Graphics-nice.385), I presume there is a similar thing in Pharo. We can't continue with this Misc thing, it's not manageable. I've also pushed the fix on github. Now remains the 64bits cog spur VM problem
|
2017-11-26 17:14 GMT+01:00 Nicolas Cellier <[hidden email]>:
And the VM problem is the one that I reported in the other thread "Something wrong in latest code generation" There's a buggy inversion in primitiveAdd and primitiveSubtract, where we test for primitiveFailure BEFORE generating primitive failure (or success). We should fix code generation in VMMaker, regenerate, then this should restore Opensmalltalk-vm health
|
2017-11-26 17:34 GMT+01:00 Nicolas Cellier <[hidden email]>:
But Eliot did already fixed the code generation in VMMaker.oscog-eem.2280 (it was TMethod >> inlineSend: aSendNode directReturn: directReturn exitVar: exitVar in: aCodeGen) So we just have to regenerate code...
|
> On 27. Nov 2017, at 00:59, Nicolas Cellier <[hidden email]> wrote: > Dear Nicolas, > But Eliot did already fixed the code generation in VMMaker.oscog-eem.2280 > (it was TMethod >> inlineSend: aSendNode directReturn: directReturn exitVar: exitVar in: aCodeGen) > > So we just have to regenerate code... thank you for your work tracking down the issues! You sure had other things planned?! Wouldn't it be nice if this event could be used to embrace automation? cheers holger |
2017-11-26 18:14 GMT+01:00 Holger Freyther <[hidden email]>:
Hi Holger, Most often, heroic actions are counter productive. They may delay adoption of better practices (including more sustainable ones). So beside what I had planned or not, this is a good question anyway ;) |
Hi, Thanks Nicolas. I will try anytime soon (Wednesday at worst) to regenerate the code. About MiscPlugin... I have set-up a project with my student for next semester (January-May). The idea is to: 1) Port Misc to standard plugin architecture. 2) Evaluate the performance of specific primitives in JIT intrinsic (I mean rewritten like SmallInteger>>#+ in the JIT), especially findSubString and compareString, both with standard instructions of Cog's RTL and with SSE4.2 string instructions. 3) Based on evaluation, consider to move 1 or 2 primitives from plugin to core VM primitives and add the intrinsic version in production. I did 3 steps so the project is interesting and allows to work with different part of the VM, but I think only 1) is guaranteed to be done with the student level. I expect therefore the Misc problem to be solved by the end of March (If my student don't do it I will do it). If you want to collaborate on this at a rate of one ~15 min skype meeting per month please tell me, I will introduce you to the student (we're all French speakers). By the way, I think the new Misc should be renamed ByteObjectPlugin since this is about ByteString & ByteArray (hash, comparison, indexOf:, findSubString, ...) and BitMap (compression/decompression). What do you think ? On Sun, Nov 26, 2017 at 6:28 PM, Nicolas Cellier <[hidden email]> wrote:
Clément Béra Pharo consortium engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq |
2017-11-26 21:04 GMT+01:00 Clément Bera <[hidden email]>:
Yes, good idea, and while at it, we will make the String comparison return -1, 0 or 1 insted of 1,2,3. Maybe ByteObjectAcceleratorPlugin, but it's a bit long...
|
On 27 November 2017 at 04:15, Nicolas Cellier <[hidden email]> wrote:
"Accelerator" seems redundant. Isn't that semantic implicit in making a plugin? cheers -ben |
> About MiscPlugin... > > I have set-up a project with my student for next semester (January-May). The idea is to: > 1) Port Misc to standard plugin architecture. > 2) Evaluate the performance of specific primitives in JIT intrinsic (I mean rewritten like SmallInteger>>#+ in the JIT), especially findSubString and compareString, both with standard instructions of Cog's RTL and with SSE4.2 string instructions. > 3) Based on evaluation, consider to move 1 or 2 primitives from plugin to core VM primitives and add the intrinsic version in production. Excellent. 1 & 3 were jobs Andreas & I planned to tackle *years* ago, part of our original ideas for the plugin stuff that just never got done. 2 of course wasn’t even a fantasy back then because no Cog, and I’d guess that several of the methods might run faster when Cogged than as typical primitives. I would suggest adding the Bitmap methods to the BitBltPlugin, the SampleSound method to SoundGenerationPlugin (and repeat job 1 on that similarly messed plugin) and the ByteString methods to… well I’d like to say the core VM, but maybe a StringPrimsPlugin might be better. Maybe that would be a place to test out WideString equivalents, too. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not. |
In reply to this post by Nicolas Cellier
On Sun, Nov 26, 2017 at 5:14 PM, Nicolas Cellier <[hidden email]> wrote:
I added that: But the long term solution is what we discussed
Clément Béra Pharo consortium engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq |
Free forum by Nabble | Edit this page |