Vm-dev December 2007

vm-dev@lists.squeakfoundation.org

18 participants
14 discussions

Re: Robot VM options
by David T. Lewis 18 Dec '07

18 Dec '07

Robert, I'm taking the liberty of copying your message to the Squeak vm-dev mailing list, which is: List-Archive: <http://lists.squeakfoundation.org/pipermail/vm-dev> List-Subscribe: <http://lists.squeakfoundation.org/mailman/listinfo/vm-dev>, <mailto:vm-dev-request@lists.squeakfoundation.org?subject=subscribe> Try googling "squeaknos" or "embedded squeak" which will lead you to e.g: http://people.squeakfoundation.org/article/59.html http://wiki.squeak.org/squeak/5727 Try reading "Squeak, Open Personal Computing and Multimedia" by Guzdial, Rose, et al. This includes chapters by some of the Squeak VM gurus that should help, especially part two, "Squeak for the Systems Programmer". http://www.amazon.com/Squeak-Open-Personal-Computing-Multimedia/dp/0 Note that the VM building tools have progressed quite a bit since that book was written, but the information in that book remains valid and well worth reading. Creating a Squeak VM for some arbitrary target hardware might be a bit off the main path for what you are trying to do, but there are certainly people with the talent and interest to handle that sort of thing in the Squeak community. Dave On Mon, Dec 17, 2007 at 04:13:55PM -0800, Robert F. Scheer wrote: > I've tossed the idea of Squeak out to the Portland Area Robotics Society > group list and the response is building up (although a bit sluggish). > > One question that immediately arose was whether Squeak is limited to the > "Big 3" OS's or is there a VM for other embedded processors maybe > without OS's. > > The Swiki says Squeak VM's are supported for Mac, MS, RISC and flavors > of UNIX. > > I remember reading somewhere that a student implemented a VM on a native > uP as a Summer project. > > Has there been much VM development on embedded uP's. > > Is there any work on a Squeak OS on any platform? > > Thanks for the support! > > - Robert >

1 0

Maximising Squeak on a Xinerama enabled display does not act correctly
by Danie Roux 10 Dec '07

10 Dec '07

All, If you have two physical displays that are Xinerama enabled, maximising causes the Squeak window to spread itself across both screens. The patch below should cause Squeak to realize its on a Xinerama display and only maximise on the one physical display: http://bugs.squeak.org/view.php?id=6745 -- Danie Roux *shuffle* Adore Unix - http://blog.danieroux.com

1 0

64 bit VM, source anyone?
by goran.krampe＠msc.se 05 Dec '07

05 Dec '07

Hi folks! Ok, so I was stupid enough to pick Debian Etch 64 bit when configuring my last server. I knew it would bite me :) and here I am confused about where to find a 64 bit VM to compile. AFAIK lots of small patches have been flying around lately, but where can I find a tar ball that has most of those? David, could you perhaps create one? Right now I use the binary i386 VM from ftp.squeak.org/debian, it seems to work but looks slowish to me (tinyBenchmarks): 295 million bytecods/sec 9.5 million sends/sec And regardless of that it seems reasonable to at least use a 64 bit VM. :) regards, Göran --- Debian-40-etch-64-minimal:~/squeak# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ stepping : 3 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips : 2063.10 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc

11 21

Re: Process>>terminate woes
by Andreas Raab 05 Dec '07

05 Dec '07

Hi - [cc: vm-dev which I accidentally left out earlier] Attached my proposed fixes for myList manipulation. The first CS (PrimSuspend-ar) changes primitiveSuspend to enable atomic removal from myList for the non-active process. The second (SuspendFixes-ar) has the main modifications for the in-image part (this may not work for all Squeak versions - I used a Croquet image as the basis, YMMV). Feedback is welcome, in particular from the usual suspects on vm-dev. Cheers, - Andreas Andreas Raab wrote: > Hi - > > I had an eventful (which is euphemistic for @!^# up) morning caused by > Process>>terminate. In our last round of delay and semaphore discussions > I had noticed that there is a possibility of having a race condition in > Process>>terminate but dismissed it as being of an application problem > (e.g., if you send #terminate make sure you have only one place where > you send it). > > This morning proved conclusively that this is a race condition which can > affect *every* user of the system. It is caused by Process>>terminate > which says: > > myList remove: self ifAbsent: []. > > The reason this is so problematic is that the modification of myList is > not atomic and that because of the non-atomic modification there is a > possibility of the VM manipulating the very same list concurrently due > to an external event (like a network interrupt). When this happens in > "just the right way" the effect is that any number of processes at the > same priority will "fall off" of the scheduled list. In the image that I > was looking at earlier we had the following situation: > * ~40 processes were not running > * The processes had their myList be an empty linked list > * The processes were internally linked (via nextLink) > * The processes were all at the same priority > Given that most of the processes were unrelated other than having the > same priority I think the evidence is pretty clear. > > The question is now: How can we fix it? My proposal would be to simply > change primitiveSuspend such that for a non-active process it will > primitively take the process off its suspendingList. This makes suspend > a little more general and (by returning the previous suspendingList) it > will also guard us against any following cleanup (like the Semaphore > situations earlier). > > Unfortunately, this *will* require VM changes but I don't think it can > be helped at this point since the VM will be manipulating these lists > atomically anyway. The good news though is that we can have reasonable > fallback code which does just exactly what we do today as a fallback to > primitiveSuspend. > > Any comments? Alternatives? Suggestions? > > > Cheers, > - Andreas > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2007