Menu
▾
▴
squeak-vmdev
|
From: Tim R. <ti...@su...> - 2004-04-23 21:49:19
Attachments:
sq
|
Dudes, dudettes, dunces and other interested sophonts - there is a new version of VMMaker that I hope will be suitable for the final 3.7 release. This latest version stores the primitive function addresses in the MCache so that calling a prim within #internalExecuteNewMethod can branch pretty directly instead of a switch statement. It's not so much a performance thing (yet) as a flexibility thing, since we can alter #functionPointerFor:inClass: to specialise the chosen prim to suit the class at some later stage. The not-so-inline method activations still go via the table of prim function addresses for now. I'd be interested to know if anyone can see any reason or way to use the MCache entry in those cases. It's been tested on RISC OS & winXP and appears to be reliable - not to mention 2.2 times faster on RISC OS than the 3.6 VMs. Sadly the winXP results only show about 5% improvement but why would I care about that :-) I still don't have a decent way to upload to cvs so you'll have to use the attached copy of sq.h - or upload it for everyone's convenience - in order to get a good build. The new #define for dispatchFunctionPointer is the only change from thelast version. tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Strange OpCodes: DSO: Do Something or Other |
|
From: Dan I. <Da...@Sq...> - 2004-05-21 17:26:32
|
>How's the 64bit stuff going? Any changes that are worth putting into >general release VMMaker? Not at this point. There will be a huge pile after a while. I hope to put out a general update in a week or 10 days. >I got bitten by the oop>2gb problem this week. Your(?) code for >checking for acceptable classes when loading an image segment goes nuts >if fed an oop it thinks is -ve. Don't suppose you've done any work that >might fix some of these places? Hate to waste time duplicating work. The first work that we (mainly Ian right now) are doing is to generalize the kernel interpreter so that it can run any combination of 32- or 64-bit image on 32- or 64-bit machine. This means being careful about the types of pointers, small integers and other quantities such as bytes, 16-, 32- and 64-bit ints. Other than through general code review, we would not find such a problem as that to which you allude, as it is particular to images that are close to their maximum oop size. Your 32-bit image is a valuable example, and it's not likely that we'll find a 64-bit image with this problem for a while. Therefore: please *do* look into fixing it or forwarding it to me for attention, and we'll make sure to incorporate it with out other changes. Thanks - Dan |
|
From: John M M. <jo...@sm...> - 2004-05-21 22:31:48
|
Hi, when I saw this, what happen was that os-x decided to load the 1GB image at the 2GB boundary, versus the 1GB or earlier location. This was a choice made by the OS, which then caused immediate failure. On May 21, 2004, at 10:26 AM, Dan Ingalls wrote: >> How's the 64bit stuff going? Any changes that are worth putting into >> general release VMMaker? > > Not at this point. There will be a huge pile after a while. I hope > to put out a general update in a week or 10 days. > >> I got bitten by the oop>2gb problem this week. Your(?) code for >> checking for acceptable classes when loading an image segment goes >> nuts >> if fed an oop it thinks is -ve. Don't suppose you've done any work >> that >> might fix some of these places? Hate to waste time duplicating work. > > The first work that we (mainly Ian right now) are doing is to > generalize the kernel interpreter so that it can run any combination > of 32- or 64-bit image on 32- or 64-bit machine. This means being > careful about the types of pointers, small integers and other > quantities such as bytes, 16-, 32- and 64-bit ints. > > Other than through general code review, we would not find such a > problem as that to which you allude, as it is particular to images > that are close to their maximum oop size. Your 32-bit image is a > valuable example, and it's not likely that we'll find a 64-bit image > with this problem for a while. > > Therefore: please *do* look into fixing it or forwarding it to me for > attention, and we'll make sure to incorporate it with out other > changes. > > Thanks > - Dan > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle > 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > > -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Tim R. <ti...@su...> - 2004-05-21 22:43:38
|
In message <9DE...@sm...>
John M McIntosh <jo...@sm...> wrote:
> Hi, when I saw this, what happen was that os-x decided to load the 1GB
> image at the 2GB boundary, versus the 1GB or earlier location.
> This was a choice made by the OS, which then caused immediate failure.
Likewise - startofmemory was &7xxxxxxxx and endofmemory was well into
&8xxxxxxxxx territory. The good news is that the image segment loading
is the only thing I've noticed failing because of that, though it's not
impossible that occasional mysterious crashes are due to the problem.
As with OSX, it's an OS memory allocation choice that isn't
controllable by the application.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
It said, "Insert disk #3," but only two will fit!
|
|
From: Tim R. <ti...@su...> - 2004-05-24 04:55:45
|
> The first work that we (mainly Ian right now) are doing is to > generalize them kernel interpreter so that it can run any combination > of 32- or 64-bit image on 32- or 64-bit machine. This means being > careful about the types of pointers, small integers and other > quantities such as bytes, 16-, 32- and 64-bit ints. > It would be kind of useful to know just what changes are being proposed here. Having worked on the previous generation change from 16 to 32 bits some eighteen years ago I might even have some useful suggestions and experience. tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Death is a nonmaskable interrupt. |
Thanks for helping keep SourceForge clean.
X