Vm-dev November 2007

vm-dev@lists.squeakfoundation.org

15 participants
17 discussions

File links in Unix VM broken?
by Andreas Raab 08 Nov '07

08 Nov '07

Hi - I had an interesting problem today. I had created a directory with a plain file like /foo/bar/plainfile and then added a subdirectory with a relative link to that file: /foo/bar/baz/link -> ../plainfile The link would be listed in the the directory listing primitives but would fail to open (although bash and any other unix tool would work just fine with it). When I played around a little more I found that the VM was trying to open /foo/plainfile instead of /foo/bar/plainfile (placing a test file in the location confirmed that) so it seems as if the Unix file code doesn't deal correctly with "up links" (going one hop too many). Any ideas how to fix that? I can work around it easy enough now that I know it but it'd be good if the problem could be fixed in general. Cheers, - Andreas

3 2

64bit: "This interpreter (vers. 68000) cannot read image file (vers. 274877913446)."
by John Thornborrow 05 Nov '07

05 Nov '07

Hello all, This is my first message to this list. I have compiled a 64bit VM for my Gentoo 64bit Intel Core2Duo machine, and I receive the message "This interpreter (vers. 68000) cannot read image file (vers. 274877913446)." for any image I try to run. I'm unable to identify a cause/solution; can anyone help? Apologies if this is a question asked very frequently. John www.pinesoft.co.uk Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

9 22

Re: [Vm-dev] extending every header by a word
by Rob Withers 01 Nov '07

01 Nov '07

Hi Michael, I was reading your mind. :) The very first thing I did was to subclass SystemTracer2 and pry it apart to see what I needed to do. I will set the vatId to 1 and a few other flags in that new header. I think I have my SystemTracer specified, but I have to wait until I get the vm together, before I can trace the image and test it. I also think I have a grasp on what needed to change in the vm...not so bad, for now. I just need to make all senders of the instantiation protocols use the new ones which specify a vat header. Thanks, Rob ----- Original Message ---- From: Michael Haupt mhaupt(a)gmail.com Hi Rob, On 11/1/07, Rob Withers <reefedjib(a)yahoo.com> wrote: > Is there anything in particular you can point me to consider or warn me of? this is just one thing that immediately pops up in my mind... you will have to convert *all* objects in the *entire* image before you will be able to use them again. Best, Michael

1 0

extending every header by a word
by Rob Withers 01 Nov '07

01 Nov '07

I am looking into what changes will be required for me to add a word to every header. I am hoping someone can give me a 5 minute overview to confirm/extend what I have learned from A Tour of the Squeak OE. I see on page 20 of the Tour of the Sq OE the layout of an object in memory, with headers. The first decision is where does the new vatHeader go, and since it will go on every header, I think I will put it just before the baseHeader, such that headers look like: type: 3 <vatHeader> <baseHeader> type: 1 <classHeader> <vatHeader> <baseHeader> type: 0 <sizeHeader> <classHeader> <vatHeader> <baseHeader> So looking into the code, I see the BaseHeaderSize running around all over the place, but please correct me, this is just to account for the fact that an oop points to the first header word, so it gets sized and stripped in various situations. I am hoping this should not be affected by a header size increase. I have just started looking, but I see that I will need to change the #classHeader:, #sizeHeader, add #vatHeader:, and anywhere that writes to the classHeader and sizeHeader, like: #allocate:headerSize:h1:h2:h3:doFill:with:. This is by no means exhaustive. Is there anything in particular you can point me to consider or warn me of? many thanks, Rob

2 1

executing a specified compiled method
by Rob Withers 01 Nov '07

01 Nov '07

I am trying to write a primitive that will execute a compiled method, one of the arguments. Does anything nasty jump out at you from this code? primitiveExecuteCompiledMethodOnReceiverWithArgs | argumentArray newReceiver methodToBeExecuted arrayArgumentCount cntxSize index | self export: true. self success: (argumentCount = 3). successFlag ifFalse: [^ successFlag]. argumentArray := self popStack. newReceiver := self popStack. methodToBeExecuted := self popStack. self popStack. "Pop the old receiver" self push: newReceiver. "Push the new receiver" receiverClass := lkupClass := self fetchClassOf: newReceiver. newMethod := methodToBeExecuted. methodClass := receiverClass. index := 1. [index <= arrayArgumentCount] whileTrue: [self push: (self fetchPointer: index - 1 ofObject: argumentArray). index := index + 1]. argumentCount := arrayArgumentCount. self executeNewMethod. successFlag := true. It is crashing my vm, when I call it. many thanks, Rob

2 2

Sound driver "plays" silence
by Andrew Gaylard 01 Nov '07

01 Nov '07

In my message, archived here http://lists.squeakfoundation.org/pipermail/vm-dev/2007-October/001595.html I mentioned that it seems that once a sound has played, the image keeps sending silence to the sound device. This keeps the CPU quite busy, as seen both by the OS (load average) and the interpreter (slower benchmarks). I've had a little more time to dig into this, and it seems this is expected behaviour: it is toggled by the "soundStopWhenDone" preference, and read in SoundPlayer>>playLoop. It seems that this is off by default (i.e. sound never really stops, once started). Switching it to "on" solved my problem. So now I'm curious. Why was it built this way? And why do released images have this preference off? For most modern hardware, this isn't an issue, but for slower hardware (e.g. mine), or for power-lean systems (e.g. the OLPC) I think it could be. Andrew

3 2

bad code in patch to bug 6555
by Rob Withers 01 Nov '07

01 Nov '07

I am attempting to generate a VM with the InterpreterSimulator-fixes-mtf.1.cs patch loaded from http://bugs.squeak.org/view.php?id=6555. The problem is with the following methods: InterpreterPlugin>>#long32At: byteAddress "Simulation support. Answer the 32-bit word at byteAddress which must be 0 mod 4." ^self getInterpreter long32At: byteAddress and InterpreterPlugin>>#long32At: byteAddress put: a32BitValue "Simulation support. Store the 32-bit value at byteAddress which must be 0 mod 4." ^self getInterpreter long32At: byteAddress put: a32BitValue When the plugin is being inlined, the recursive call to #long32At: and #long32At:put: is causing the inlining to enter an infinite loop. With these methods removed, everything builds fine. Rob

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev November 2007