Hi, Does anybody know the current status of the various simulators? Even the classes are a bit confusing, since their class comments are just copied and pasted from their siblings/ancestors, so I cannot figure out what is current and what is used for what. Could some kind soul please summarize which images are supposed to be run by which simulator? E.g. is InterpreterSimulator (and subclasses) still being used/working? More concretely, I tried to run StackInterpreterSimulator on a 4.5 image, since it does not support the current image format, but I keep hitting various errors. A particularly confusing kind is that NewObjectMemory refers sometimes to its interpreter instvar, sometimes to its coInterpreter instvar (sometimes to both in the same method), even though only the coInterpreter instvar is initialized. Does it need both instvars, and if so, what are their roles and how should they be initialized? Thank you, Florin |
Hi Florin,
On Tue, Mar 8, 2016 at 12:46 PM, Florin Mateoc <[hidden email]> wrote:
I can vouch for the simulators in VMMaker.oscog. StackInterpreterSimulator and CogVMSimulator work. InterpreterSimulator is extremely unlikely to any more. Even the classes are a bit confusing, since their class comments are just copied and pasted from their They're not in VMMaker.oscog (which is on http://source.squeak.org/VMMaker). CogVMSimulator's comment is quite different from StackInterpreterSimulator. In fact, they could do with being made a little more similar ;-) Could some kind soul please summarize which images are supposed to be run by which simulator? E.g. is Not in VMMaker.oscog. The Interpreter there-in hasn't been touched for many years. We have a task when time allows to merge Interpreter[Simulator] from VMMaker with Interpreter[Simulator] from VMMaker.oscog, so that for example we can have a Spur context interpreter. More concretely, I tried to run StackInterpreterSimulator on a 4.5 image, since it does not support the current image In VMMaker.oscog that's not the case. StackInterpreterSimulator allInstVarNames select: [:v| '*terpreter*' match: v] #('interpreterProxy') If what you want is to work with the current Squeak, Pharo or Newspeak VMs then you need to be using VMMaker.oscog. The latest version is Name: VMMaker.oscog-nice.1713 Author: nice Time: 5 March 2016, 3:15:22.817 am UUID: ac270981-d3ba-4c42-a2b1-3a83693776be Ancestors: VMMaker.oscog-nice.1712 The size of [unsigned] long long was not infered... VM fool proofing: Fix a missing guard in SmartSyntaxPlugin like explained at Fix two missing guards in VM profiling primitives: one should not use the result of stackObjectValue: before checking for success, otherwise a null pointer exception will occur in case of failure. Thank you, _,,,^..^,,,_ best, Eliot |
Hi Eliot, Thank you, VMMaker.oscog works better, indeed. I still got an error while executing: (StackInterpreterSimulator new openOn: 'F:\Smalltalk\squeak\Squeak-4.5-All-in-One.app\Contents\Resources\Squeak4.5-decompiler.image') test Do I need any additional settings? Here is the erorr report: 'From: 8 March 2016 5:35:01.126 pm VM: Win32 - Smalltalk Image: Squeak5.0 [latest update: #15117] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir F:\Smalltalk\squeak\Squeak-5.0-All-in-One\Squeak-5.0-All-in-One.app\Contents\Resources Trusted Dir F:\Smalltalk\squeak\Squeak-5.0-All-in-One\Squeak-5.0-All-in-One.app\Contents\Resources\fmateoc Untrusted Dir C:\Users\fmateoc\Documents\My Squeak NewObjectMemorySimulatorLSB(Object)>>error: Receiver: a NewObjectMemorySimulatorLSB Arguments and temporary variables: aString: ''unaligned access'' Receiver''s instance variables: memory: a LittleEndianBitmap of length 7421053 youngStart: 25087060 endOfMemory: 29212852 memoryLimit: 29684212 nilObj: 4 falseObj: 12 trueObj: 20 specialObjectsOop: 4339092 rootTable: #(2837948 4339092 219644 231688 231700 3830388 10956 22224904 5356 1...etc... rootTableCount: 88 rootTableOverflowed: false extraRoots: nil extraRootCount: 0 weakRoots: #(2572452 nil nil nil nil nil nil nil nil nil nil nil nil nil nil ni...etc... weakRootCount: 1 child: 1501724940 field: 345348 parentField: 3 freeBlock: nil lastHash: 17871637 allocationCount: nil lowSpaceThreshold: 200000 signalLowSpace: false compStart: 26763028 compEnd: 26867736 fwdTableNext: 26868032 fwdTableLast: 29684204 remapBuffer: #(26772976 26772968 nil nil nil nil nil nil nil nil nil nil nil ni...etc... remapBufferCount: 0 allocationsBetweenGCs: nil tenuringThreshold: 2000 gcBiasToGrow: 0 gcBiasToGrowGCLimit: 0 gcBiasToGrowThreshold: nil statFullGCs: 0 statIncrGCs: 18 statFullGCUsecs: 0 statIncrGCUsecs: 0 statGCEndTime: nil statIGCDeltaUsecs: 0 statTenures: 0 statRootTableOverflows: 0 freeContexts: nil freeLargeContexts: nil interruptCheckCounter: nil totalObjectCount: 471363 shrinkThreshold: 8388608 growHeadroom: 4194304 headerTypeBytes: a CArrayAccessor on: #(8 4 0 0) youngStartLocal: 25087060 statMarkCount: 4111 statMarkCountLocal: 4111 statSweepCount: 2961 statMkFwdCount: 45 statCompMoveCount: 45 statGrowMemory: 0 statShrinkMemory: 0 statRootTableCount: 88 statAllocationCount: nil statSurvivorCount: 931 statSpecialMarkCount: 1616 forceTenureFlag: 0 gcStartUsecs: 3634910906984935 coInterpreter: a StackInterpreterSimulatorLSB freeStart: 26773052 reserveStart: 27070132 scavengeThreshold: 27070132 needGCFlag: false fullGCLock: 0 edenBytes: 2097152 checkForLeaks: 0 statGCEndUsecs: 3634910906984935 heapMap: a CogCheck32BitHeapMap parent: nil NewObjectMemorySimulatorLSB(VMClass)>>unalignedAccessError Receiver: a NewObjectMemorySimulatorLSB Arguments and temporary variables: Receiver''s instance variables: memory: a LittleEndianBitmap of length 7421053 youngStart: 25087060 endOfMemory: 29212852 memoryLimit: 29684212 nilObj: 4 falseObj: 12 trueObj: 20 specialObjectsOop: 4339092 rootTable: #(2837948 4339092 219644 231688 231700 3830388 10956 22224904 5356 1...etc... rootTableCount: 88 rootTableOverflowed: false extraRoots: nil extraRootCount: 0 weakRoots: #(2572452 nil nil nil nil nil nil nil nil nil nil nil nil nil nil ni...etc... weakRootCount: 1 child: 1501724940 field: 345348 parentField: 3 freeBlock: nil lastHash: 17871637 allocationCount: nil lowSpaceThreshold: 200000 signalLowSpace: false compStart: 26763028 compEnd: 26867736 fwdTableNext: 26868032 fwdTableLast: 29684204 remapBuffer: #(26772976 26772968 nil nil nil nil nil nil nil nil nil nil nil ni...etc... remapBufferCount: 0 allocationsBetweenGCs: nil tenuringThreshold: 2000 gcBiasToGrow: 0 gcBiasToGrowGCLimit: 0 gcBiasToGrowThreshold: nil statFullGCs: 0 statIncrGCs: 18 statFullGCUsecs: 0 statIncrGCUsecs: 0 statGCEndTime: nil statIGCDeltaUsecs: 0 statTenures: 0 statRootTableOverflows: 0 freeContexts: nil freeLargeContexts: nil interruptCheckCounter: nil totalObjectCount: 471363 shrinkThreshold: 8388608 growHeadroom: 4194304 headerTypeBytes: a CArrayAccessor on: #(8 4 0 0) youngStartLocal: 25087060 statMarkCount: 4111 statMarkCountLocal: 4111 statSweepCount: 2961 statMkFwdCount: 45 statCompMoveCount: 45 statGrowMemory: 0 statShrinkMemory: 0 statRootTableCount: 88 statAllocationCount: nil statSurvivorCount: 931 statSpecialMarkCount: 1616 forceTenureFlag: 0 gcStartUsecs: 3634910906984935 coInterpreter: a StackInterpreterSimulatorLSB freeStart: 26773052 reserveStart: 27070132 scavengeThreshold: 27070132 needGCFlag: false fullGCLock: 0 edenBytes: 2097152 checkForLeaks: 0 statGCEndUsecs: 3634910906984935 heapMap: a CogCheck32BitHeapMap parent: nil NewObjectMemorySimulatorLSB>>long64At: Receiver: a NewObjectMemorySimulatorLSB Arguments and tempo...etc... |
Hi Florin,
On Tue, Mar 8, 2016 at 2:42 PM, Florin Mateoc <[hidden email]> wrote:
You shouldn't, but there may be an initialization bug. Can you post just the stack, without all those simulator inst vars? The stack trace gets interesting at "NewObjectMemorySimulatorLSB>>long64At:" just when the post gets truncated. I don't know why long64At: would be sent in a V3 simulation so it piques my interest.
_,,,^..^,,,_ best, Eliot |
On 3/8/2016 7:20 PM, Eliot Miranda
wrote:
Sure, here it is: NewObjectMemorySimulatorLSB(Object)>>error: NewObjectMemorySimulatorLSB(VMClass)>>unalignedAccessError NewObjectMemorySimulatorLSB>>long64At: NewObjectMemorySimulatorLSB(ObjectMemory)>>fetchLong64:ofObject: [] in StackInterpreterSimulatorLSB(InterpreterPrimitives)>>signed64BitValueOf: False>>ifTrue:ifFalse: StackInterpreterSimulatorLSB(VMClass)>>cppIf:ifTrue:ifFalse: StackInterpreterSimulatorLSB(InterpreterPrimitives)>>signed64BitValueOf: StackInterpreterSimulatorLSB(InterpreterPrimitives)>>primitiveLessThanLargeIntegers StackInterpreterSimulatorLSB(StackInterpreter)>>dispatchFunctionPointer: StackInterpreterSimulatorLSB(StackInterpreter)>>slowPrimitiveResponse StackInterpreterSimulatorLSB(StackInterpreter)>>internalExecuteNewMethod StackInterpreterSimulatorLSB(StackInterpreter)>>commonSendOrdinary StackInterpreterSimulatorLSB(StackInterpreter)>>normalSend StackInterpreterSimulatorLSB(StackInterpreter)>>bytecodePrimLessThan StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>dispatchOn:in: StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>test UndefinedObject>>DoIt Florin |
In reply to this post by Eliot Miranda-2
Hi again, I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes. In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption come from, because it does not seem limited to this method. Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail. Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied and pasted. For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits. Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and #positive64BitValueOf: do not take care of the BigEndian case. Cheers, Florin |
On 3/9/2016 3:17 PM, Florin Mateoc wrote: > Hi again, > > I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even > mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes. > In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption > come from, because it does not seem limited to this method. > Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail. > > Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied > and pasted. > For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte > LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to > 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits. > > Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and > #positive64BitValueOf: do not take care of the BigEndian case. > > Cheers, > Florin For what it's worth, I did try the obvious (if what I suspect is correct) fix in #signed64BitValueOf: and it seemed to work: ... self cppIf: VMBIGENDIAN ifTrue: [value := objectMemory fetchByte: sz - 1 ofObject: oop. sz - 2 to: 0 by: -1 do: [:i | value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]] ifFalse: [value := (objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger. 4 to: sz - 1 do: [:i | value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]]. instead of the original: ... self cppIf: VMBIGENDIAN ifTrue: [value := objectMemory fetchByte: sz - 1 ofObject: oop. sz - 2 to: 0 by: -1 do: [:i | value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]] ifFalse: [value := sz > 4 ifTrue: [objectMemory fetchLong64: 0 ofObject: oop] ifFalse: [(objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger]]. |
Hi Florin, I believe the correct fix is for ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8. I'll commit asap (which is once I have 64-bit small float tagging converted). But your fix should keep you going until then. _,,,^..^,,,_ (phone) > On Mar 9, 2016, at 1:53 PM, Florin Mateoc <[hidden email]> wrote: > > >> On 3/9/2016 3:17 PM, Florin Mateoc wrote: >> Hi again, >> >> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even >> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes. >> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption >> come from, because it does not seem limited to this method. >> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail. >> >> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied >> and pasted. >> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte >> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to >> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits. >> >> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and >> #positive64BitValueOf: do not take care of the BigEndian case. >> >> Cheers, >> Florin > > > For what it's worth, I did try the obvious (if what I suspect is correct) fix in #signed64BitValueOf: and it seemed to work: > > > ... > self cppIf: VMBIGENDIAN > ifTrue: > [value := objectMemory fetchByte: sz - 1 ofObject: oop. > sz - 2 to: 0 by: -1 do: [:i | > value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]] > ifFalse: > [value := (objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger. > 4 to: sz - 1 do: [:i | > value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]]. > > > instead of the original: > > > ... > self cppIf: VMBIGENDIAN > ifTrue: > [value := objectMemory fetchByte: sz - 1 ofObject: oop. > sz - 2 to: 0 by: -1 do: [:i | > value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]] > ifFalse: [value := sz > 4 > ifTrue: [objectMemory fetchLong64: 0 ofObject: oop] > ifFalse: [(objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger]]. > |
On 3/9/2016 8:23 PM, Eliot Miranda wrote: > > Hi Florin, > > I believe the correct fix is for ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8. I'll commit asap (which is once I have 64-bit small float tagging converted). But your fix should keep you going until then. > > _,,,^..^,,,_ (phone) Hi Eliot, I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :)) Florin >> On Mar 9, 2016, at 1:53 PM, Florin Mateoc <[hidden email]> wrote: >> >> >>> On 3/9/2016 3:17 PM, Florin Mateoc wrote: >>> Hi again, >>> >>> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even >>> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes. >>> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption >>> come from, because it does not seem limited to this method. >>> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail. >>> >>> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied >>> and pasted. >>> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte >>> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to >>> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits. >>> >>> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and >>> #positive64BitValueOf: do not take care of the BigEndian case. >>> >>> Cheers, >>> Florin >> |
On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <[hidden email]> wrote:
Because in V3 any object occupies some number of 32-bit words, zero padded. So a 5 byte large integer is actually a 4 byte header followed by an 8 byte unit whose most significant 3 bytes are always zero. In Spur, any object occupies some number of 8-byte words, so a 5 byte integer has an 8 byte header followed by an 8 byte unit, but a 9 byte integer occupies 24 bytes (8 byte header, 16 bytes data). So in V3, fetching 64-bits from a 5 to 8 byte large integer must be done in two reads because objects are only aligned to a 4 byte boundary, but in Spur it can be done in a single 64-bit read because all objects are aligned on an 8 byte boundary.
_,,,^..^,,,_ best, Eliot |
On 3/10/2016 12:02 PM, Eliot Miranda
wrote:
Thank you, that makes perfect sense Florin |
In reply to this post by Eliot Miranda-2
On 3/10/2016 12:02 PM, Eliot Miranda
wrote:
Since ObjectMemory (in its subclasses) actually already decomposes long64At: in two 32-bit reads, instead of duplicating the decomposition in fetchLong64:ofObject: (the caller or long64At:), shouldn't the fix just be to replace the alignment check within long64At:? i.e. replacing the hardcoded 8 with BytesPerWord: byteAddress \\ 8 ~= 0 ifTrue: [self unalignedAccessError]. Florin |
Hi Florin,
|
On Fri, Mar 11, 2016 at 12:04:22AM -0800, Eliot Miranda wrote: > > This is where it gets tricky. The implementations of longAt:[put:] et al in the subclasses are only for simulation. The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are. The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware. Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions. > You may want to look at package MemoryAccess in the VMMaker repository. I have not integrated into the oscog branch, but that could probably be done without too much work. This is an implementation of the sqMemoryAccess.h macros written entirely in slang. That means that there is no hidden CPP magic. It is written entirely in Smalltalk, and the "simulated" macros are what actually gets translated to C. With full inlining, performance is about the same as the CPP macros (or at least it was the last time I checked it). I wrote the package when was working out the 32/64 bit image and host combinations for VMM trunk. I was finding the CPP macros rather confusing, so it helped be able to work with them in Smalltalk rather than try to guess what the macros were going to do. Dave |
On 3/11/2016 8:28 AM, David T. Lewis wrote: > > On Fri, Mar 11, 2016 at 12:04:22AM -0800, Eliot Miranda wrote: >> This is where it gets tricky. The implementations of longAt:[put:] et al in the subclasses are only for simulation. The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are. The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware. Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions. >> > You may want to look at package MemoryAccess in the VMMaker repository. I > have not integrated into the oscog branch, but that could probably be done > without too much work. > > This is an implementation of the sqMemoryAccess.h macros written entirely > in slang. That means that there is no hidden CPP magic. It is written entirely > in Smalltalk, and the "simulated" macros are what actually gets translated > to C. With full inlining, performance is about the same as the CPP macros > (or at least it was the last time I checked it). > > I wrote the package when was working out the 32/64 bit image and host > combinations for VMM trunk. I was finding the CPP macros rather confusing, > so it helped be able to work with them in Smalltalk rather than try to > guess what the macros were going to do. > > Dave > > Thanks guys, this gets closer and closer to what I am trying to understand: how good is the match between the simulation and the translated version and where does it possibly break down? I had this idea that, since translation necessarily works with a frozen and closed-world assumption, plus there is no real compile-time pressure, this could be used to translate almost normal Smalltalk instead of Slang and thus potentially bring even the static VM development to the masses, as a complement to Sista. But of course, if the simulation is only a best-efforts approximation, this may not work very well. In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely based on reading this relatively obscure code, can you please elucidate a couple of mysteries for me? 1. Was this fetchLong64: bug a V3 VM bug as well or just a simulation bug? 2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian? 3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with separate calls for sign, instead of just using the signed version (see primitiveAddLargeIntegers)? Florin |
On Fri, Mar 11, 2016 at 6:40 AM, Florin Mateoc <[hidden email]> wrote:
The simulation is pretty close. The JIT's simulation closer. This is simply history, plus the fact that debugging a JIT is more difficult and therefore more accurate simulation helps. But if you're interested in closed world translations you might contact Gerardo Richarte and Xavier Burroni and ask them about their JIT work. In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely Just a simulation bug. The code generated for the real VM is correct. 2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian? They don't have to. Large Integers in Smalltalk are always little endian. Nicolas Cellier has a prototype that would organize then as a sequence of 32-bit words, in which case they would be endian-dependent, but this is problematic because in 32-bit systems SmallInteger is only 31 bits, and so accessing the one and only 32-bit word of the large integer 16rFFFFFFFF answers that large integer itself. Further, organizing it as a sequence of 16-bit words doesn't help either because 16rFFFF * 16rFFFF overflows 31-bit SmallIntegers. so if one wants to be able to implement large integer arithmetic non-primitively in the image using SmallIntegers, 8 bits is the largest convenient unit. 3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with Some large integer primitives want to interpret the bit patterns in large integers as bit patterns and use magnitude64BitValueOf:. So,e primitives want to interpret the bit patterns in large integers as arithmetic values, failing for LargeNegativeInteger, and use positive64BitValueOf:. Perhaps positive64BitValueOf: is surplus to requirements, but it fits with the existing set. BTW, they are /not/ primitives. They are run-time support functions. Let's not get confused. Florin _,,,^..^,,,_ best, Eliot |
On 3/11/2016 5:47 PM, Eliot Miranda
wrote:
<snip>
Thank you for the explanations, especially since I know you are very busy. As for my interest in closed world translations, I am indeed interested and I know it can be done (the type inferencing and inlining parts), but if I don't have "customers", meaning especially you as Squeak's main vm developer, I won't spend time on it. It is not a trivial project. Cheers, Florin |
|
On 3/11/2016 9:31 PM, Eliot Miranda wrote: > Then maybe we can pull you into some Sista work. Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code. But that may be quite an effort and be something we can collaborate on. But right now the focus is on making what else have now fast and complete. The "perfect" solution can wait until we can afford the opportunity cost. > Well, if there is Sista work that does not involve C, I am interested in that as well |
Hi Florin, > On Mar 11, 2016, at 7:37 PM, Florin Mateoc <[hidden email]> wrote: > > >> On 3/11/2016 9:31 PM, Eliot Miranda wrote: >> Then maybe we can pull you into some Sista work. Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code. But that may be quite an effort and be something we can collaborate on. But right now the focus is on making what else have now fast and complete. The "perfect" solution can wait until we can afford the opportunity cost. > > Well, if there is Sista work that does not involve C, I am interested in that as well None of Sista involves C. First, the vast majority of Sista is image level. It is an SSA based analyser that rewrites bytecode methods to bytecode methods that include unsafe bytecodes. Second, the JIT fir tgose bytecode methods is all Smalltalk and targets machine code via an abstract assembler-like intermediate language augmented with a model of the stack that also functions as a register allocator. Sista is developed directly in Smalltalk with no limitations from Slang, or having to generate a VM. It exists in the image just like the bytecode compiler. The JIT is developed in the context of the VM simulator. It does have to obey Slang's restrictions. But machine code execution etc is via safe simulators such as Bochs so again the development experience is dynamic and safe. C only enters the picture when generating and compiling a production VM and us a very small part of the overall experience. |
Free forum by Nabble | Edit this page |