Hi Tim, alas this: + ----- Method: BitBltSimulator>>halftoneAt: (in category 'memory access') ----- + halftoneAt: idx + + ^ (halftoneBase + (idx \\ halftoneHeight * 4)) long32At: 0! breaks the VM simulator, my main development environment for the VM. I know you need to progress but can I ask you to test your changes against some valid simulation before committing? Here's an expression that should run the standard VM simulator and given a suitable image should run without problems: | vm om | vm := StackInterpreterSimulator newWithOptions: #(#ObjectMemory #Spur32BitMemoryManager ). om := vm objectMemory. vm desiredNumStackPages: 8. "Makes simulation faster by creating fewer stack pages." vm openOn: '/Users/eliot/Cog/spurreader.image'. "Choose any image but if you use one created by http://www.squeakvm.org/svn/squeak/branches/Cog/image/buildspurtrunkreaderimage.sh you'll be able to interact with it throguh a little dialog box that reads chunk format expressions, simulating the reader in the image that reads chunk expressions from stdin." vm instVarNamed: 'assertVEPAES' put: false. "This makes the simulation faster by turning off some expensive asserts" ^ [vm openAsMorph; halt; run] on: Halt , ProvideAnswerNotification "This exception handler ignores some halts and confirmers occurring during simulation" do: [:ex | ex messageText == #primitiveExecuteMethodArgsArray ifTrue: [ex resume]. ex messageText = 'clear transcript?' ifTrue: [ex resume: false]. ex pass] Thanks! I'm about to commit a merge. I've no idea whether my change, which is: halftoneAt: idx ^self cCode: [(halftoneBase + (idx \\ halftoneHeight * 4)) long32At: 0] inSmalltalk: [self long32At: halftoneBase + (idx \\ halftoneHeight * 4)] will break RSqueak. Apologies if it does. Perhaps we can fund time to discuss the differences. I still don't understand how RSqueak uses primitive simulations, or why, if it does, we can't use a different subclass to isolate RSqueak and the VMSimulator from each other. This treading on each other's toes is getting painful ;-). For example if you used a consistent naming such as RSqueakFooSimulator and simply copied all the relevant simulation-specific plugin subclasses we would avoid treading on each other's toes and the system would be easier to understand. HTH On Thu, Feb 11, 2016 at 12:56 AM, <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
Hi Tim,
On Fri, Feb 19, 2016 at 3:36 PM, Eliot Miranda <[hidden email]> wrote:
and this also breaks simulation: Item was changed: ----- Method: VMClass>>oopForPointer: (in category 'memory access') ----- oopForPointer: pointerOrSurrogate "This gets implemented by Macros in C, where its types will also be checked. oop is the width of a machine word, and pointer is a raw address." <doNotGenerate> + ^pointerOrSurrogate! - ^pointerOrSurrogate asInteger! The asInteger is absolutely required. Again you could override in an RSqueak-specific subclass.
_,,,^..^,,,_ best, Eliot |
Hi Eliot,
yes, maybe we can find a time to discuss this in a call. These changes I did were also done to fix the two simulation tests (testAlphaCompositingSimulated and testAlphaCompositingSimulated2) which were failing on a fresh image with VMMaker loaded for me. Were they not failing for you? These tests have been there since 2009, and I assumed they use a valid entry point into the simulation (namely BitBlt>>copyBitsSimulated). Were not actually running an entire simulator, we're just running the Slang code directly in the system (like those tests to), and ideally I'd like this to be done in a way that would work on any Squeak VM (if you don't use the Balloon or BitBlt plugins, for example). Using your latest version, these BitBltSimulation tests are failing again for me, do they work for you? Cheers, Tim
|
Hi Eliot,
Your code for VM simulation does not work for me on a newly downloaded and updated trunk image with your version of VMMaker. There are problems in InterpreterPrimitives>>primitiveUtcWithOffset and StackInterpreter class>>initializeClassIndices (the latter got installed with incorrect bytecodes, but correct source, so recompiling fixed that for me). Patching around those problems, I can run your simulation snippet. However, the BitBltSimulation tests fail. I also noticed that lots of VMMaker tests are failing, anyway, so I have a question: is there some magic invocation that I have to do to prepare my image for VMMaker to make the tests green, or is it that the VM team just doesn't use tests? If the latter, maybe we can have a discussion about that, too. If only about what it means for potential new contributors to see a package with tests that are mostly red ;) I'm going to commit some small changes and a test to run the simulation, so I can run that test, too, whenever I make changes to the VMMaker. cheers, Tim
|
Free forum by Nabble | Edit this page |