Hi Paul,

If you're looking to make instruction dispatch fast in your VM, one
thing worth trying is to use a 'case' indexed by enum elements.

You'll need to cook up some parsing words, first.

IN: lpeg

...

<<

SYMBOL: instructions

H{ } clone instructions set-global

! INSN: word body ;
: INSN: scan-word parse-definition swap instructions get set-at ; parsing

! DISPATCHER: new-word
! Creates new-word ( insn# -- ), change effect if you need more parameters
: DISPATCHER:
    CREATE-WORD instructions get >alist '[ _ case ] (( insn# -- ))
define-declared ; parsing

>>

C-ENUM: first-insn second-insn third-insn ... ;

INSN: first-insn ... ;

INSN: second-insn ... ;

INSN: third-insn ... ;

DISPATCHER: exec

As I mentioned before, make sure that all the critical words have
static stack effects. You can assert this with unit tests:

\ exec must-infer

One other thing to try: declare any words which operate on your VM
tuple 'inline', then supposing the exec word has effect ( vm insn --
vm ), put hints on it:

HINTS: exec vm instruction ;

Slava

On Wed, Jan 21, 2009 at 2:35 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> 2009/1/21 Slava Pestov <sl...@factorcode.org>:
>> Have you seen C-ENUM: in alien.syntax?
>
> No, I hadn't. Thanks for the pointer. It's nice to see that it's quite
> similar to mine :-)
>
>> This word is in alien.syntax
>> because we generally only use it when interfacing with C libraries. If
>> you just need symbolic constants (without requiring them to be
>> consecutive numbers), use SYMBOLS: or SINGLETONS:.
>
> I was looking at having an array of actions indexed by symbolic
> constants, so I did need consecutive numbers. Having said that, a
> hashtable indexed by symbols, or a generic function dispatching on
> singletons, would probably do the same job. I suspect I was just
> letting C-based coding habits (where an indexed array would be
> distinctly faster) rule my design. I may still try it, just to get a
> feel for relative performance...
>
> (Hmm, for experiments like this, in C I might well write the 3
> versions of the code using #ifdefs and use -Dxxx at compile time to
> build the 3 variants, to test them. What would be an idiomatic way of
> doing something similar in factor?)
>
> Paul.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to