Menu
▾
▴
squeak-vmdev
|
From: Ian P. <ian...@in...> - 2004-04-08 13:56:25
|
On 08 Apr 2004, at 15:14, Andreas Raab wrote: > I take that as a clear "yes", right?! ;-) Absolutely. The two GC things I'd most like to see are: - being able to lock-down objects (so they don't move, allocated outside the heap, preferably via a generalised mechanism that isn't restricted just to variable words -- our recent exchange about LIFO context allocation, etc...) - a way to reserve a certain guaranteed amount of heap memory that will never be allocated during normal instantiation, but remains available for (e.g.) primitives (LargeInts, whatever) and other non-primitive internal mechanisms. (In addition to context flushing, there are things like Message creation for send/return exceptions that could benefit from this. Orthogonal example: Unix filesystem partitions reach 100% capacity for users before they're really full -- the additional space remains available to root processes.) Cheers, Ian |
|
From: Tim R. <ti...@su...> - 2004-04-08 16:51:36
|
In message <07e401c41d4e$66c86440$b2d0fea9@R22>
"Andreas Raab" <and...@gm...> wrote:
> John,
>
> Yup, that's pretty much what I had in mind, e.g.,
>
> * when we go into a primitive we set a disableGC flag
> * if there is allocation we fall through in sufficientSpaceToAllocate:
> (possibly growing mem if needed but not GCing)
> * upon primitive return we do the allocation check and GC if necessary
>
Why go to the trouble of adding extra code simply to turn off
something. simpler, cleaner and more intelligable to just remove the
damn code!
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Hypnotized as a child and couldn't be woken.
|
|
From: Andreas R. <and...@gm...> - 2004-04-08 17:26:11
|
> Why go to the trouble of adding extra code simply to turn off > something. simpler, cleaner and more intelligable to just remove the > damn code! Err ... that was a joke, yes? Removing GC? Or what do you mean... - A. |
|
From: Jecel A. Jr <je...@me...> - 2004-04-08 14:32:06
|
Ooops... I sent this only to Ian the first time instead of the list. He wrote a very nice reply giving even more examples of why this is a good idea. On Wednesday 07 April 2004 22:02, Ian Piumarta wrote: > Which reminds me of something else Dan & I talked about in the past: > evaluating arguments from right to left. Saves an awful lot of > tedious peeking into the middle of the stack to pick up the receiver. > (Combined with the above, potentially wins Really Big for 386 too. > OTOH, the tradeoffs for register architectures are a little more > complex.) My Neo Smalltalk evaluates right-to-left. That lets me get by with just one send instruction. The first instructions in a compiled method grab the right number of arguments from the caller's stack. Unless it is a short leaf method - in that case it can skip creating its own stack and run directly with the caller's stack. This is a very common case since I currently do very little inlining (just the usual ifTrue: stuff). In the green book Dan mentioned that the change to left-to-right from Smalltlak-78 to -80 was supposed to make people stop complaining about surprising results and to make creating really simple compilers possible. I didn't get this last part as the right-to-left order is easier in the recursive compilers I have written so far. -- Jecel P.S.: I hope comparing how my own and other implementations (I am very familiar with Self, for example) do things isn't too annoying. If it is, please let me know |
|
From: Avi B. <av...@be...> - 2004-04-08 18:07:46
|
On Apr 8, 2004, at 7:32 AM, Jecel Assumpcao Jr wrote: > My Neo Smalltalk evaluates right-to-left. That lets me get by with just > one send instruction. The first instructions in a compiled method grab > the right number of arguments from the caller's stack. Unless it is a > short leaf method - in that case it can skip creating its own stack and > run directly with the caller's stack. This is a very common case since > I currently do very little inlining (just the usual ifTrue: stuff). Not that this really matters at all, but - this also makes implementing Forth-like languages (see my Sorrow package on SM) easier. |
|
From: John M M. <jo...@sm...> - 2004-04-08 00:53:02
|
Ned I looked at this a year back in terms of checking for large integers
that fit into 32bit since there is routines to load smallish large
integers into 32bits.
This made messing with calculations absolute 512MB > < 2 billion really
fast. However this is rare in practice, some thought is required to
watch out
for large postive/negative integers and not screw up signage, and as
Andreas pointed
out to me small integer math is like 99.999ish %, with perhaps some
float mixed in.
followed by that large integer stuff requiring a send.
Mmmm I'm not sure I've a change set, perhaps some C code if you want to
look at it?
On Apr 7, 2004, at 3:54 PM, Ned Konz wrote:
> On Tuesday 06 April 2004 3:48 pm, Ian Piumarta wrote:
>> On 06 Apr 2004, at 23:50, Yoshiki Ohshima wrote:
>>> how about using "01" for OOP
>>> and "00" for SmallInteger? Some processor's addressing mode let us
>>> access the word-aligned memory with such pointer, while "no-tag" for
>>> SmallInteger may save some bit-operations.
>>
>> Just another data point: some Smalltalk implementations put the
>> SmallInteger tag in the topmost bit. This makes SI tag and overflow
>> checks after arithmetic simpler: addition and subtraction work
>> in-place, plus you can just look at the sign flag after the operation
>> instead of "mask + test-zero" or "shift + xor + sign-test".
>>
>> On architectures where you can set the sign flag during move this can
>> also often eliminate any need to mask and test on the tag bit; after a
>> move you can "trap" immediately on (non-)SI oops.
>
> On a related note, does it seem wasteful to anyone but me that we do
> the
> following in primBytecodeAdd:
>
> int rcvr;
> int arg;
>
> rcvr = longAt(localSP - (1 * 4));
> arg = longAt(localSP - (0 * 4));
> if (((rcvr & arg) & 1) != 0) /* areIntegers: rcvr and: arg */
> {
> result = ((rcvr >> 1)) + ((arg >> 1));
> if ((result ^ (result << 1)) >= 0) /* isIntegerValue: result */
> {
> /* begin internalPop:thenPush: */
> longAtput(localSP -= (2 - 1) * 4, ((result << 1) | 1));
> /* begin fetchNextBytecode */
> currentBytecode = byteAt(++localIP);
> goto l9;
> }
> }
> else
> {
> /* Try to add them as a float */
> /* If success, we're done. Get the next bytecode and loop */
> }
>
> /* otherwise, do a normal send */
>
>
> For a total operation count (not counting the stack load/store) of:
> 1 AND
> 2 bit tests
> 2 right shifts
> 2 left shifts
> 1 OR
> 1 XOR
> 1 ADD
>
> when for the majority of additions (those that don't overflow 31 bits)
> we only
> have to add the top two values (resetting one low bit first so that we
> don't
> get a carry from B0 to B1).
>
> Seems like we could save the shifts in most cases by looking at the
> top two
> bits of the receiver and argument; if the sign bits are different or
> the high
> bits (B30) are both the same as the sign bits we aren't going to get
> any
> overflow.
>
> --
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&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: Bryce K. <br...@ka...> - 2004-04-08 19:38:49
|
Ned Konz writes: > On a related note, does it seem wasteful to anyone but me that we do the > following in primBytecodeAdd: Yes, that sequence does seem wasteful. Ideally I'd like to generate: and arg1, arg2, andResult and andResult, 2r11, dummy1 branch-if-not-zero overflowBlock add addResult, arg1, arg2 branch-on-overflow overflowBlock This sequence is possible if we change from integers having tag 1 to integers having tag 0 leaving the tag in the lower bits. The Self community wrote some nice papers on tagging and high performance simple garbage collection. The above sequence only has the add on the critical path during the common case where the arguments are SmallIntegers and the result is also a SmallInteger. The other four instructions do not matter so long as both branches are correctly predicted as not taken. Looking up oops can be done by using the small offset provided in most load or store instructions. This means that a non-zero oop tag has no overhead. But interpreted code probably spends most of it's time recovering from branch mispredicts. Compiled code should be sufficiently faster that the garbage collector will be the major bottle-neck. Realistically any changes to tagging should be looking to provide a large improvement to garbage collector performance. 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? My limited benchmarking indicates that code using arrays is dominated by at: and at:put: overhead. We're not yet at the point where our inefficient SmallInteger format matters. Once we're at the point where SmallInteger addition is worth improving our garbage collector will be a serious bottleneck. Currently the garbage collector uses about 10% of the time reduce the 90% by enough to make these few instructions matter and garbage collection will be closer to 50%. So, yes it does seem wasteful, but first let's improve things so that the waste really matters. Even then other things (the garbage collector) will be more important which require image changes. Anything that simplifies and speeds up at: and at:put: will matter much more. Tim, that primitive work? Bryce |
|
From: Ian P. <ian...@in...> - 2004-04-09 00:26:14
|
On 08 Apr 2004, at 21:46, Bryce Kampjes wrote: > This sequence is possible if we change from integers having tag 1 to > integers having tag 0 leaving the tag in the lower bits. The Self > community wrote some nice papers on tagging and high performance > simple garbage collection. Teeny reminder (which may be irrelevant): Itanium cannot add -1 into an effective address without introducing an additional add instruction and stop bit (!) before each ld/st insn. (Unless I'm missing some neat trick on the Itanium? If so, someone please enlighten me! ;) > 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? To get the same benefits as the existing at-cache you'd need two levels. The first in the method cache (to get you to the right accessor implementation, with fixed field size being stored in a // MC slot presumably?) then another instance-specific one (to get you to the object's indexable size). Maybe all this is saying is that we might want to rethink how object size is encoded in the header to make it trivially easy to extract the indexable size, whatever the format of the object. (What we really want is to generate format-specific accessor primtives on-the-fly. The fixed field size is then implicit in the implementation and all that's needed is the primitive implementation address slot in the method cache.) Bye, Ian |
|
From: Tim R. <ti...@su...> - 2004-04-09 00:50:41
|
In message <805...@in...>
Ian Piumarta <ian...@in...> wrote:
> On 08 Apr 2004, at 21:46, Bryce Kampjes wrote:
>
> > This sequence is possible if we change from integers having tag 1 to
> > integers having tag 0 leaving the tag in the lower bits. The Self
> > community wrote some nice papers on tagging and high performance
> > simple garbage collection.
>
> Teeny reminder (which may be irrelevant): Itanium cannot add -1 into an
> effective address without introducing an additional add instruction and
> stop bit (!) before each ld/st insn.
And at umpty-eleven gazillion gigglehertz, do we care? Besides, itanium
is actually Itanic and is about to sink into the deep.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: CAO: Compare Apples to Oranges
|
|
From: Ian P. <ian...@in...> - 2004-04-09 00:52:03
|
On 09 Apr 2004, at 02:48, Tim Rowledge wrote: >> Teeny reminder (which may be irrelevant): Itanium cannot add -1 into >> an > And at umpty-eleven gazillion gigglehertz, do we care? Besides, itanium > is actually Itanic and is about to sink into the deep. Why did I say: "which may be irrelevant"? ;) Ian |
|
From: Ned K. <ne...@bi...> - 2004-04-06 23:00:09
|
On Tuesday 06 April 2004 2:50 pm, Yoshiki Ohshima wrote: > > * Wide characters (Unicode is defined as 21 bit; but Yoshiki really needs > > 24) > I'd like to have 30 bit for a char. What's the advantage of doing that? What can't you represent in 24 bits? I'm assuming that you can put most of the extra meta-info into Strings. To uniquely index glyphs, wouldn't 24 bits be enough (possibly with some information from the String that holds the characters)? -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
|
From: Ian P. <ian...@in...> - 2004-04-06 23:05:46
|
On 07 Apr 2004, at 00:59, Ned Konz wrote: >> I'd like to have 30 bit for a char. > > What's the advantage of doing that? What can't you represent in 24 > bits? You can pack five "sixbit"-encoded DECSystem-10 characters into a single 30-bit word. ;-) ;-) Seriously, though, you're right. UCS (Unicode) only needs 21. Unless I'm missing something? Tchao, Ian |
|
From: Yoshiki O. <Yos...@ac...> - 2004-04-07 03:41:08
|
Ned and everyone, > On Tuesday 06 April 2004 2:50 pm, Yoshiki Ohshima wrote: > > > * Wide characters (Unicode is defined as 21 bit; but Yoshiki really needs > > > 24) > > I'd like to have 30 bit for a char. > > What's the advantage of doing that? What can't you represent in 24 > bits? > > I'm assuming that you can put most of the extra meta-info into Strings. To > uniquely index glyphs, wouldn't 24 bits be enough (possibly with some > information from the String that holds the characters)? The extra bits are used for the meta-info, yes, and the meta-info is primarily used as "language tag" to label the languages. In Squeak, the tag will be used to select the proper scanner, and font. In this case, we'd like to have more than 8 (2^(24-21)) languages. CJKV, Armenian, Mongolian, Philippine languages, there are languages that require "meta-info". I see that my current design is somewhat hybrid approach of two. One approach would be that a string carries sequence of naked 21-bit quantity (or this can be wider, but naked code point). Glyph info and scanning rules, etc. are supplied by the attributes attached to the string (probably in a form of TextAttribute.) In this case, we can't, say, inspect or print a string. Which may not too bad given that the current inspector doesn't show $<char> form for a slot of a string. However, I think people expect to be able to inspect a "naked" string. An extreme along this line is that we even don't need Character objects; we can make a string with length of 1 behave as if today's character. After all, "a character cannot print itself" is the way Unicode is designed. So, using Unicode is kind of a synonym of this approach. (I wouldn't pursue this extreme in Squeak, though.) The other approach is to make a character self-contained thing. It knows how to print itself, etc. To make this happen, a Character has to carry more than naked code-point and the higher bits in the word is where it goes. I kind of like the former approach. In the latter approach, people would like to add more attribute in the bits but always are under the fear of running out the bits. And, the indirect way of nature is not nice. However the implementation is not there yet. Also, the self-contained nature is still nice in Smalltalk and I would imagine that most of the Smalltalkers expect to be able to inspect strings and characters. So far, the hybrid approach, in which you can put things in the higher bits mostly to provide the default value, well as you can override the default by attaching attribute as TextAttributes seems least destructive. Implementing the former approach is my "future plan," but not for V4. (Someone could try it.) Whether a (wide) character should be an immediate or not, I would say that it doesn't have to; they aren't in today's Squeak. Even if we make them so, we can't use the flyweight pattern (there will be too many). And, the character object floating around (not in the String) are not that many in typical use. I think we can live with non-immediate character objects. This leaves the future extension such as implementing konjaku-mojikyo like thing (http://www.mojikyo.org/). If the "gray-beards' decision" is "we go with 24 bit immediate chars", well, I could do it. In this case, the 3 bits are used to discriminate unified kanji's and ask people who want to use some other languages to put up with a little inconvenience. -- Yoshiki |
|
From: Tim R. <ti...@su...> - 2004-04-06 23:07:23
|
In message <uzn...@YO...>
Yoshiki Ohshima <Yos...@ac...> wrote:
> I think once Tim suggested this, but how about using "01" for OOP
> and "00" for SmallInteger? Some processor's addressing mode let us
> access the word-aligned memory with such pointer, while "no-tag" for
> SmallInteger may save some bit-operations.
Actually I think it was Bryce that suggested this and I objected. IIRC
the suggestor made an argument that I had to admit was plausible. Can't
remember details now.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: DMK: Destroy Memory-protection Key
|
|
From: Tim R. <ti...@su...> - 2004-04-06 23:12:28
|
In message <011401c41c2b$d09ba810$b2d0fea9@R22>
"Andreas Raab" <and...@gm...> wrote:
> > Just another data point: some Smalltalk implementations put the
> > SmallInteger tag in the topmost bit.
[snip]
BrouHaHa being one example.
>
> Hm... if we'd accept cutting the address range in half (which isn't that big
> of a deal) that is actually a pretty interesting idea. It would allow us to
> use low bits as "other tags" similar to immediate, say 00->oop, 01->GC flag,
> 10->Character, 11->Undefined, without too much of a bother.
>
> The only objection I'd have is whether this would have any effects on
> machines that "like to give you the upper half of the address space" (e.g.,
> all addresses must have that "tag bit" set).
I'd say this was a bit of a problem. BHH didn't have an issue since
OOPs were indices into an OT and thus never had much chance of
exceeding a few million. Especially on a machine with 1Mb ram total...
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Satisfaction Guaranteed: We'll send you another copy if it fails.
|
|
From: Ned K. <ne...@bi...> - 2004-04-07 05:28:54
|
On Tuesday 06 April 2004 8:40 pm, Yoshiki Ohshima wrote: > =A0An extreme along this line is that we even don't need Character > objects; we can make a string with length of 1 behave as if today's > character. =A0After all, "a character cannot print itself" is the way > Unicode is designed. =A0So, using Unicode is kind of a synonym of this > approach. =A0(I wouldn't pursue this extreme in Squeak, though.) > > =A0 The other approach is to make a character self-contained thing. =A0It > knows how to print itself, etc. =A0To make this happen, a Character has > to carry more than naked code-point and the higher bits in the word is > where it goes. But we already have this situation with the existing Characters. They don't= =20 know their encoding, so any attempt at printing them in an Inspector is ver= y=20 possibly wrong (unless they're in the default encoding). How often do you find yourself inspecting individual Characters inside a=20 String? Even more to the point: how often do you find yourself inspecting Character= s=20 that aren't inside a String? After all, a String could provide the required context to inspect its=20 characters. =2D-=20 Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
|
From: Yoshiki O. <Yos...@ac...> - 2004-04-07 05:57:20
|
Ned, At Tue, 6 Apr 2004 22:28:40 -0700, Ned Konz wrote: >=20 > On Tuesday 06 April 2004 8:40 pm, Yoshiki Ohshima wrote: > > =A0An extreme along this line is that we even don't need Character > > objects; we can make a string with length of 1 behave as if today's > > character. =A0After all, "a character cannot print itself" is the way > > Unicode is designed. =A0So, using Unicode is kind of a synonym of this > > approach. =A0(I wouldn't pursue this extreme in Squeak, though.) > > > > =A0 The other approach is to make a character self-contained thing. =A0= It > > knows how to print itself, etc. =A0To make this happen, a Character has > > to carry more than naked code-point and the higher bits in the word is > > where it goes. >=20 > But we already have this situation with the existing Characters. They don= 't=20 > know their encoding, so any attempt at printing them in an Inspector is v= ery=20 > possibly wrong (unless they're in the default encoding). What do you mean by "they don't know their encoding?" You mean that they don't know the font to use by default, etc.? For the first 256 chars, the default font simply *works*. For the other characters, this is not always the case. > How often do you find yourself inspecting individual Characters inside a = > String? >=20 > Even more to the point: how often do you find yourself inspecting Charact= ers=20 > that aren't inside a String? To which point? We should go with 24 bit immediate? We should go with "naked code point + attributes" approach? How often *I* inspect those is relevant here? I personally do it all the time, because I write and debug a part of Squeak that involves those objects. I guess you're saying that you like the *first* approach I wrote. Which isn't too different from my position. =20 > After all, a String could provide the required context to inspect its=20 > characters. How about the inspecting the string itself? -- Yoshiki |
|
From: Tim R. <ti...@su...> - 2004-04-07 19:59:39
|
In message <5F1...@in...>
Ian Piumarta <ian...@in...> wrote:
>
> Oh, just go install NetBSD on your ARM and never look back. ;)
Been there, done that, wiped up the vomit. I would love to have a good
kernel (stipulating for now that my understanding is that netBSD has
such) under RISC OS's GUI & applications. However, I'm not willing to pay
the price of a completely horrible user experience in order to get the
(noticable but not huge) improvement in kernel cleanliness. It's not as if I
haven't ever tried; I think my *nix experience goes back to 82 or
thereabouts. It's just that I've never felt that it was something a human
being should be subjected to if there is any plausible alternative. Er, and
note that after getting reacquainted with windows after six years I wouldn't
consider it to be such.
Besides, despite it being a truism that security through obscurity is
no security, I have to say that being effectivly immune to viruses is
quite an advantage these days.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
May the bugs of many programs nest on your hard drive.
|
|
From: Andreas R. <and...@gm...> - 2004-04-08 00:39:19
|
> While it probably won't impact speed on a decent implementation of the > CPU (the additional branch will be predicted correctly) it won't > increase speed either (you haven't reduced the overall number of data > hazards the pipeline has to deal with). Which reminds of something else we were talking about in the past: Passing primitive arguments as C arguments instead of the Smalltalk stack. I remember that you said that this would be advantageous for various reasons and since it requires changing the plugins and a lot of other stuff, V4 might be a chance to give this "more serious thoughts". Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2004-04-08 02:02:44
|
In message <6FE...@in...>
Ian Piumarta <ian...@in...> wrote:
>
> Current version:
>
> lwz r3,0xfffc(r27)
> lwz r4,0(r27)
> and r28,r3,r4
> andi. r9,r28,0x1
> beq <fail>
> srawi r5,r3,1
> srawi r0,r4,1
> add r4,r5,r0
> rlwinm r2,r4,1,0,30
> xor. r9,r4,r2
> blt <fail>
> ori r6,r2,0x1
> stwu r6,0xfffc(r27)
> <dispatch>
>
Just out of interest I extracted the RISC OS equivalent and I'm pleased
to see that the latest compiler does a reasonable job. Probably why it
makes a VM 20% faster than the old one...
LDR R0,[R5] get rcvr & arg from stack
LDR R2,[R5,#-4]
AND R1,R2,R0 do tag test
TST R1,#1
BEQ fail smallint test
MOV R1,R2,ASR #1 shift dn arg
ADD R0,R1,R0,ASR #1 add shifted arg to shifted rcvr
EORS R1,R0,R0,LSL #1 eor result with itself shifted up
BMI fail result test
MOV R1, #1 odd- put 1 in R0?
ORR R1,R0,R0,LSL #1 or in 1 to result shifted up
STR R0,[R5,#-4]! push & modify sp in one go
LDRB R7,[R6,R1]! fetch next byte - odd use R0 for 1
B dispatch
It's hard to see much that could be dropped (in the context of an
interpreter). If we could keep the top couple of items in registers it
would save two loads and a store. Even a translator would have to do
most of this I think; no load or store or bytecode fetch I guess?
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
People who deal with bits should expect to get bitten. - Jon Bentley
|
|
From: Tim R. <ti...@su...> - 2004-04-08 05:23:45
|
Does anyone recall the claimed reason for 'internalising' the method lookup/activation stuff? It seems pretty pointless to me, sitting here staring at it. I feel sure it must be giving the poor C compiler coniptions to have so much cruft in a single loop, probably leading to register allocation indigestion. So far as I can see the only cost to having them external is the internalize/externalize SP/IP code and that's a couple of storage instructions. The only code I can see particularly benefitting from being 'internal' is the quickreturn prims which use internalPop:thenPush: - but changing them to external status would only involve referring to the global SP/IP and IIRC all of us are using the global vars in an array now which speeds that up. Maybe I'll try it out in my copious spare time. tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Useful random insult:- A Neanderthal brain in a Cro-Magnon body. |
|
From: Tim R. <ti...@su...> - 2004-04-08 16:48:57
|
In message <083a01c41d51$64cbf0a0$b2d0fea9@R22>
"Andreas Raab" <and...@gm...> wrote:
> > I'd suggest that the VM changes are pretty small but ought to include
> > the ability to pass back an error value (fortunately I have ancient
> > code to do that sitting somewhere) so the image knows what the problem
> > was and does the smart thing.
>
> Yes, that is a "must do" in my understanding. Thanks for reminding. I think
> we might just extend #primitiveFail to include an "error reason", so you
> would use it via:
>
> interpreterProxy->primitiveFail(ERROR_BAD_ARGUMENT);
>
> or somesuch.
Well, I guess I'll dig out the old code then. Needs a trivial change to
the compiler when handling prims IIRC.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: PO: Punch Operator
|
|
From: Ian P. <ian...@in...> - 2004-04-08 19:20:33
|
On 08 Apr 2004, at 20:07, Avi Bryant wrote: > On Apr 8, 2004, at 7:32 AM, Jecel Assumpcao Jr wrote: > >> My Neo Smalltalk evaluates right-to-left. > > Not that this really matters at all, but - this also makes > implementing Forth-like languages easier. This matters even less, but right-to-left arg eval order makes implementing Java on top of the Squeak VM harder. Tchao, Ian |
|
From: Dan I. <Da...@Sq...> - 2004-04-08 19:30:11
|
>On 08 Apr 2004, at 20:07, Avi Bryant wrote: > >>On Apr 8, 2004, at 7:32 AM, Jecel Assumpcao Jr wrote: >> >>>My Neo Smalltalk evaluates right-to-left. >> >>Not that this really matters at all, but - this also makes implementing Forth-like languages easier. Ian commented... >This matters even less, but right-to-left arg eval order makes implementing Java on top of the Squeak VM harder. and likewise implementing Squeak on top of the Java VM ;-) - Dan |
|
From: Ned K. <ne...@bi...> - 2004-04-08 21:40:26
|
On Tuesday 06 April 2004 10:57 pm, Yoshiki Ohshima wrote: > What do you mean by "they don't know their encoding?" You mean that > they don't know the font to use by default, etc.? > > For the first 256 chars, the default font simply *works*. For the > other characters, this is not always the case. 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. > > How often do you find yourself inspecting individual Characters inside a > > String? > > > > Even more to the point: how often do you find yourself inspecting > > Characters that aren't inside a String? > > 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. > I guess you're saying that you like the *first* approach I wrote. > Which isn't too different from my position. Right. -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X