On 1/25/2013 10:11 AM, Kurt Stephens wrote:
Don't know if this has been posted/discussed before:
http://dslbook.org/
The 560-page, book is donationware. Lots to read here. :)
nifty, may have to go read it...
it does make me wonder:
how viable is donationware as an option for software, vs, say, the
shareware model?
(I wonder this partly as my 3D engine is sort-of donationware at
present, but I had considered potentially migrating to a shareware model
eventually...).
note: this doesn't apply to my scripting stuff, which is intended to be
open-source (currently uses MIT license), but is presently bundled with
the 3D engine, but could be made available separately (as some people
have expressed concern over downloading proprietary code to get the free
code, but admittedly I am not entirely sure what the issue is here, but
either way).
also left wondering if anyone has a good idea for a good way to
determine when things like bounds-checks and null-checks can safely be
omitted? (say, with array and pointer operations).
I guess probably a way of statically determining that both the array
exists and the index will always be within array bounds, but am not
entirely sure exactly what this check would itself look like (like if
there is a good heuristic approximation, ...).
type-checking is a little easier, at least as far as one can determine
when/where things have known types and propagate them forwards, which
can be used in combination with explicitly declared types, ... however,
the size of the array or value-range of an integer is not part of the
type and may not always be immediately obvious to a compiler.
then again, looking online, this may be a non-trivial issue (but does
add several checks and conditional-jumps operations into each array access).
well, at least luckily the security checks has a good solution:
if the code belongs to the VM root, most security checks can be omitted.
the only one that can't really be safely omitted relates to method calls
(we don't want root calling blindly into insecure code).
often this check can be done as a static check (by checking the source
and destination rights when generating a "call-info" structure or
similar, which will be flushed whenever new code is loaded or the VM
otherwise suspects that a significant scope-change has occurred).
actually, static-call caching is itself a heuristic:
it assumes that if the site being called is a known function or static
method declaration, then the call is static;
if the site being called is a generic variable or similar, a dynamic
call is used (which will use lookups, type-checks, ... to go about
making the call).
most of this is largely transparent to high-level code, and mostly is
figured out in the bytecode -> threaded-code stage, and most of this
information may be reused by the JIT.
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
