Re: The Revenge of the Geeks
Date: Thu, 24 Jan 2013 17:44:01 -0600
Message-ID: <kdsh2o$fg8$1_at_news.albasani.net>
On 1/24/2013 4:30 PM, Arne Vajhøj wrote:
> On 1/24/2013 5:10 PM, BGB wrote:
>> I ended up trying to use Java for scripting at one point (since
>> Minecraft made it look like maybe this made sense), and ended up using
>> my own custom mini-JVM (using a JavaME like subset, mostly due to JNI
>> frustration), but soon enough realized that it didn't really make a
>> particularly great scripting language (didn't really fit in well with
>> the use case, and I couldn't readily "eval()" it).
>>
>> (I also evaluated using .NET and/or Mono and C# for scripting, but this
>> also looked like a big mess).
>>
>> so, effort mostly shifted back to my custom script language, which is
>> more closely derived from JavaScript and ActionScript (with a lot more
>> elements from C, Java, C#, ... glued on). (like, hell, I will glue on
>> what parts I care about).
>>
>> it seems to work moderately well for game-scripting tasks, without the
>> same level of funkiness as Lua or Python (I more prefer an at least
>> vaguely C/Java/C# style syntax, even if the language still has its share
>> of funkiness, and the controversy over whether to the use JS/AS or
>> Java/C# style declaration syntax, ...).
>>
>> theoretically, I guess it would be a more direct competitor with Lua or
>> similar though.
>
> If one need a scripting language, then a scripting language is
> often the best choice.
>
yeah, it can also be specialized to application needs, like, say, a scripting language for a game having built-in vector math support and similar (vectors are a part of the numeric tower).
> :-)
>
> If you absolutely want to use Java, then use BeanShell.
>
well, as-is my script-language works well enough.
and, my main codebase is pretty solidly stuck with being C as well. (could do more C++, but this would make a mess of some things, as at-present most of my tools can't parse or process C++ code, as well as making code using C++ features as part of its external API unusable from script code, ...).
luckily, with the new JIT, the language shouldn't be as slow as it was before either (I was measuring it as around 3x slower than C for things like array sorting), which is an improvement over the 60x slower than C with the plain-C interpreter.
the JIT is still a bit naive at present though, and doesn't cover much/most of the ISA, in which case operations fall back to "call threaded code" (but, this is still faster than the plain interpreter).
admittedly, this JIT is x86 only at the moment.
as-is, some elements of the VM architecture did take some ideas from the JVM though, like for example, many opcodes are either type-specific or may be type-qualified via prefixes, ...
the use of prefixes was more a result of migrating a dynamically-typed VM to being largely statically typed, as the prefixes resulted in less ISA expansion (and also it being easier to figure this stuff out in the front-end compiler than in the back-end). though, I did end up with a pile of type-specialized arithmetic operations.
like "ADD_XI" or "PF_HINT_XI ADD", which serve a similar role to "IADD" in the JVM, ...
or such... Received on Fri Jan 25 2013 - 00:44:01 CET