> Brent Dax wrote: > > TOGoS: > > # When I say in IMCC: > > # > > # $P0 = $P1 + $P2 > > # > > # , I expect it to create a new value and > > # store it in > > # $P0, not give me a segfault because I didn't say > > # > > # $P0 = new <figure out what the heck type > > # $P0 is supposed to be based > > # on the types of $P1 and $P2> > > # > > # first. > > > > Then your expectations are wrong. > > Noone is saying that the add opcode *should* try to > intuit that -- he's > trying to say that there should be two versions of > the add opcode, one > of which uses assign semantics, and the other of > which uses set > semantics.
Yap. *That's* what I was saying :-) The one problem with this is that more vtable entries would need to be added, and as Leo pointed out: > While that is all fine and useful, > we would need that for e.g. keyed set > and get too (store/get a reference or value). > So that would lead to effectively almost > doubling our opcode count. This can lead to > less code locality and instruction cache > misses, which I don't like. There may be something I'm missing, but I don't understand why we need a keyed version of just about every opcode. If it wasn't for that, this wouldn't be so much of a problem. I find it a bit strange that there is a keyed version of 'add', anyway. If you're doing a lot of operations on integers stored in arrays it could help performance, but how often does this actually happen? Maybe there should be a add_keyed_int opcode/vtable entry, but not a generic add_keyed entry? :-S __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
