Re: big-little

On 11/11/2011 1:28 PM, Chris Gray wrote:
BGB<cr88192@xxxxxxxxxxx> writes:

although, FWIW, I was recently testing, and my BGBScript interpreter
is 233x slower than native WRT the test... ("fib(38)" currently takes
about 69s).

I can't recall, but I think you said you had a byte code engine?


yes.

it was partially modified more recently though (a matter of days ago) to use a variant of threaded code, which is built from the bytecode. this was more for flexibility reasons than performance ones though.

the interpreter itself is written mostly in plain C.


I just tried it on my Zed one. With unoptimized engine, the time is a bit
under 24s. With "gcc -O3", it is a bit over 13s. Given the extra
conditional branches you'll need for dynamic type testing (Zed is statically
typed, except for explicit tests), I'd say you are doing pretty good.


yep.

actually, the typesystem is not particularly efficient either, as it is mostly built on memory-object lookups (the pointer can be to nearly anything, managed heap or otherwise, and need not point at the start of the object) and returning the type-name as a string.

so, it was a typesystem more built to be convenient than to be efficient.

FWIW: I have used tagger-references in the past, and although they can generally be much more efficient, they are also generally more awkward to work with. likewise goes for things like dealing with type-numbers or similar (it is easier to assign types a name).

yes, "strcmp()" is not the fastest possible type-checking around.


granted, I have made much faster interpreters in the past, but it mostly the matter of balancing performance against convenience (and a scripting language which runs at near native speeds, but is very painful to interface with from C, is not necessarily an ideal tradeoff...).


so, the gain is a type-system where I can use raw pointers, do most other things one can do with raw pointers, run type-checks on whatever (most calls are friendly to unmanaged and otherwise invalid pointers), where adding types is often as simple as coming up with a name for it.

similarly, one can register a few callbacks and add new types of built-in objects to the language (including executable objects, such as function-types), ...


one doesn't have to register C functions, because the VM is generally smart enough to figure out how to automatically glue against C functions.

this also includes accessing structs (and struct members), which can be accessed fairly easily, provided they are allocated with a type-name, and have an annotation in the typedef to associate between the type-name and structure definition (in the future, I may make it so that if the typedef-name is used as the type-name, the VM will figure it out without an annotation).

the language can also work with raw pointers and function pointers, but all this has not been well tested. theoretically, one can just shove a lambda into a function pointer (say, in a struct or similar) and it should work, but I don't currently trust this all that well.

it is also possible to export structures and functions to C (so that C code can "call in" without needing to use API calls).


note: "most of this automatic gluing against C" stuff does require the use of tools (basically to parse headers and similar, or to spew out C code and headers WRT exporting), which produce databases and similar (and have to be kept "up to date" so that struct access works).

sadly, some of these tools are a little slow...

note: C code generation can be skipped if one doesn't really need transparent C -> script calls (and can live with making API calls, or writing wrapper functions for said API calls...).

also, the current interface is mostly C only, and has almost no support for C++ gluing (processing C++ and gluing against the C++ ABIs is admittedly a bit more complex than plain C functions and structs).

IMO, it seems "reasonable" to use a C-style API for cross-language interfacing (people *can* live without directly sharing classes and templates across language barriers until if/when I can face this terror...).


so, it is not necessarily the fastest or most rock-solid piece of technology around (nor necessarily the cleanest or simplest design), but in general I am generally optimistic about how things are going with it.

nevermind if people don't like aspects of my language design:
it having a JavaScript/ActionScript style syntax, having goto, C-style pointers, ifdef, and using a mix of C-style and Java-style APIs, ... but, hell, not everyone can be happy.

some people can make accusations of "blub", but really, what does it matter if it does what I want from it?...


or such...
.

Relevant Pages

  • Re: new here, my lang project...
    ... I feel general, as I am unsure, eg, how a language like c would map to ... on the way structs are layed out in memory, the way pointers are ... such a vm will typically manage it's own memory, ... one can't put any more data in a struct, doing so would break the app. ...
    (comp.object)
  • Re: Compatibility question
    ... struct point a, b; ... I suppose if I was designing a language there's a lot of things I ... Where 'reference' and 'value' refer to the targets of the pointers. ... My ruminations had not gone as far as to consider nested structures ...
    (comp.lang.c)
  • Re: A C Adventure: your comments are welcome
    ... try on a dynamically typed language: ... I still contend that auto-dereferencing of struct pointers is better suited to a dynamic language than a static one. ... That's why I'm less concerned with auto-derefencing of these pointers in the more informal dynamic language than in C: ...
    (comp.lang.c)
  • struct by value
    ... When creating an API for a struct in C, ... Often the answer is obvious, to use pointers, particularly ... Is there a rule of thumb of struct size for an interface API that you ... Have you used struct by value parameter passing or return value at all ...
    (comp.lang.c)
  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)