Menu
▾
▴
squeak-vmdev
|
From: Yoshiki O. <Yos...@ac...> - 2004-04-08 22:02:23
|
Ned, > That's not the case unless you have decided on a standard encoding. For > instance, if you load Ian's X11 Fonts package into a stock image, you will > have fonts that display the same Character as different glyphs, because the > fonts in the stock image use the MacRoman encoding, and the X11 fonts use > Latin-1. Oh. I completely assume that we move to Unicode based encoding, Which means that first 256 chars are compatible latin-1. > > To which point? We should go with 24 bit immediate? We should go > > with "naked code point + attributes" approach? > > I think that we should probably stick to 24 bits and put other information > into the Strings. It is going to be a little bit more intrusive change than we might want to. The Compiler should carry the attributes from the thing it evaluates to the result. For example, if you put a string in a workscape something like: dict at: ',' put: ',' and put the different language tag to the second comma from the first in the workspace. In that case, the commas look differently in the workspace. If you do-it the expression, you want to make the key and value in the dictionary carry the same attribute when *they* were in the workscape. The self-containedness is nice in this regard. But, what would be the best argument to make the wide-characters immediate objects? -- Yoshiki |
|
From: Tim R. <ti...@su...> - 2004-04-08 22:05:51
|
In message <165...@ka...>
Bryce Kampjes <br...@ka...> wrote:
> It would probably be more worthwhile looking at at: and at:put:. Could
> Tim's improvements to primitives be used to create simple at:
> primitives that are quick to execute?
That's one of the aims; dispatch prims from a value cached in the
method lookup cache (I'm not actually doing that yet, but soon I hope)
so that specialized mini-prims can be used. It's an old trick and not
anything I thought up but it usually has benefits.
For example, one could have an at mini-prim that knows the rcvr is a
word array and so doesn't need to check the format, another for byte
arrays etc. The correct version is chosen and installed at lookup time.
For primPerform type code I imagine it is simpler to use the 'normal'
versions but perhaps it could be extended.
What I'd love to achieve is a send that goes something like:-
lookup message in cache
not found? do lookup & cache fill
find cache entry
branch to cached function addr
err, that's it. Oh, return!
Sadly we need to have the backup for if the prim function fails. I
considered making primfailure go via a tail call to the normal method
activation but that would require rewriting huge amounts of stuff.
Nobody is currently paying me enough to take on _that_ particular
labour. It would be nice though because instead of having a primIndex
of 0 we could have a pointer direct to methodActivate.
Current state is in
http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3
-7b2.sar for what it's worth.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: SCEU: Simulate Correct Execution, Usually
|
|
From: Tim R. <ti...@su...> - 2004-04-10 02:00:27
|
In message <014301c41dbb$6f406ec0$6688b8d9@R22>
"Andreas Raab" <and...@gm...> wrote:
> Tim,
>
> The idea was that you would specify primitives with arguments (like FFI
> and/or SmartInterpreterplugin) and then glue gets generated for the
> interpreter. So it would actually look somewhat along the lines of:
OK, that would help prepare for a real translator and it might be
argued that it would make writing prims simpler but I can't see any
particular performance benefit in our current VM. I guess we could
generate wrappers that do extra stuff on occasion as well -perhaps
debugging? Of course, he wrappers need generating somehow. The CCodeGen
could probably create static C code ones with a bit of futzing; doing it
in machine code dynamically might be more than we want to do right now?
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Oxymorons: Small crowd
|
|
From: Andreas R. <and...@gm...> - 2004-04-06 21:45:25
|
Oh, I almost forgot that: Here is one issue which is actually VERY high up on my VM/image-wishlist. It is the ability to have bits objects that won't be moved around by GC. In other words, a large portion of the time we spend in full GC is to move ridiculous amounts of bits around for no particular reason - say a 3MB Display bitmap. In general, this isn't overly problematic as this gets "old" rather rapidly but if you look at "heavy media environments" (say one of Alan's 200MB demos, or a fully loaded Croquet image) this is actually where most of the time for GC is spent. If we could get these bit objects to be ignored by the garbage collector we would a) speed up GCs and b) enable "external" clients (say like 3D rendering) to actually share these bits with Squeak (this has a whole lot of advantageous implications which I won't go into detail here). What does this have to do with V4? The easiest way to solve the above problem is to either allocate it "from the top" of Squeak's heap or via a C allocator and just make sure these bit objects are properly read and written. That's the approach I would take but it requires a tiny bit of support from the image format - namely that these "external bits" are separated from the "regular objects", e.g., the image format would have some marker that says "okay, here are the fixed bit objects" so that they can be allocated in the "right" portion of memory. Cheers, - Andreas |
|
From: Andreas R. <and...@gm...> - 2004-04-06 22:51:53
|
[fixed bit objects] > Like allocating video memory? Great! We need this - GPUs are becoming > general-purpose co-processors now (see http://www.gpgpu.org/). This would be one of the things you *might* use it for. All I'm really saying is that we should have something that allows us to load/save these "bit objects" without having to do ridiculous amounts of relocation. > Are there security implications of this? It should be impossible from > the image to just allocate some random memory, I suspect. Unrelated to the V4 aspects. Those things need to be handled by plugins anyway. Say if you want to use the ATI client texture storage (which I *do* want to use) you need to have the lower-level hooks to get this right. > Also, are there any hooks we should set into place to allow secure > execution of ... whatever? Just thinking aloud. If we need any bits > security-wise, now would be the time to get them in. Not at the VM level, I don't think. These issues must be addressed at a higher level and we really shouldn't start handing out ACLs or similar and then try to guess if some portion of Squeak code can be "trusted" or not. Security doesn't work well (if at all) on this level. The only reason why we have the security hooks we have today is that when we needed to ship at DOL there simply wasn't any viable solution other than building in these "last resort hooks" that we did. Not that they are "secure" in any reasonable meaning of the word. We're just lucky that no seasoned hacker sees Squeak a viable target for doing some Real Harm (tm). Cheers, - Andreas |
Thanks for helping keep SourceForge clean.
X