Re: Phix 1.0.2 uploaded

new topic     » goto parent     » topic index » view thread      » older message » newer message
katsmeow said...

2) knowing what's in existance during runtime before trying to use it.

Yes, that would certainly have to be considered. There is a fair bit to unpick here, not all bad:

It is the compiler's job (and remember that in Phix, interpretation is just "compilation in memory") to emit the fastest possible code, so "normal" function calls and the like are converted to fixed symbol table entries, for instance if you have "function myfunct()" and "x = myfunct()" that means (say) symtab[427] with (say) 9 consecutive entries for result/myfunct/args/locals, and unless you want performance to fall off a cliff, that is not going to change. However call_func() and/or call_proc() (which along with get_routine_info() were never going anywhere, btw, and being advised that the compiler spots non-overidden "routine_ids" and spits out the faster static form) already have to perform the sort of dynamic lookup the static form deliberately avoids.

I want to replace the "flat" symbol table with something more "tree shaped" (and probably also "unpack on demand"), so while some symtab[1..symlimit] may remain set in concrete, there would be more options for symtab[symlimit+1..$] being able to contain a myfunct with the needed 10 or 11 replacement consecutive entries. There is an argument that once you have defined "myfunct", that's it, it should never go away, in case something is still using it, but you could o/c subsequently define "myfunct2", "myfunct3", etc.

In short, I am not about to kill performance for aesthetics sake, if you want dynamic code it has to at least look like dynamic code, and there may need to be a little hoop-jumping to prevent the compiler replacing "call_func(myfunct,...)" with the faster static form, ie "call_func(rid,...)", where rid is not patently always set to myfunct. Anyway, this is all a very long way off, o/c.

One last question I have for you is that Phix already has an eval(), have you tried using it? Pretty much the best I could do with things in their current state, may get something better in 2.0, may not survive, no-one seems to be using it anyway.

new topic     » goto parent     » topic index » view thread      » older message » newer message


Quick Links

User menu

Not signed in.

Misc Menu