ok, req info, 'invokedynamic' and typesystem, ...

[BGB]

so, this is the question thus far:
which particular idea of invokedynamic is most likely to be used?

from what I can gather, one plan is to use opcode 186 with a layout and args 
the same as invokeinterface. informally, I have assumed this idea thus far.

mention was also given of using invokeinterface with a null object or class 
(in the MethodRef structure?...).


now, other info about the typesystem would be useful to know.
I guess the idea is that dynamic types will be represented via objects, so 
the 'dynamic' aspect is more the dynamic ability to handle object types?

if so, how is dynamic slot access handled?
via getfield/putfield, getstatic/putstatic, invokedynamic, ... ?

(in my effort, thus far I had taken the approach of using getfield/putfield 
and performing dynamic access if the slot was not statically resolved).


also, is it assumed thus far that using invokedynamic will always imply a 
method call (in general), or is it possibly the case that the VM could 
"streamline" some operations?

I guess the issue is partly, as I understand it, that a form of "duck 
typing" system is planned, where an object can be a type simply by having 
the right slots and methods, in contrast to having the type be 'intrinsic' 
in the value (as is typically the case with most VMs and types like fixnum, 
flonum, cons, ...).


oh well, for info (context, optional):
my effort is working from a pre-existing framework, and so dynamic types are 
builtin types (rather than object types). I also typically do not use "duck 
typing". this is partly why I guess I wanted specific opcodes (actually, I 
may well use special opcodes, mostly for performance reasons, and also for 
usages that go likely outside the normal 'intended range of use').

it is currently my plan to use a separate file extension if saving class 
files with a different usage pattern or bytecode than normally expected, 
although most such bytecode will probably only exist in-memory given my 
intended usage (a different file extension could help reduce possible 
confusion).

actually, I have come up with a specific extension opcode list, ... but 
don't expect it to be so much relevance to the people here.

as far as me implementing stuff, thus far most of the core VM machinery is 
now in place, apart from exceptions... but I have yet to really test any of 
it (or come up with and implement an external API, ...).


misc my case, native interface (safe to skip if not interested):
I also don't really like any of the existing "native interface" systems, but 
this is a harder issue.
current leaning is to make the java/class files look just as they do in 
using JNI, but possibly to include extra "binding" information in separate 
text files (I am still unsure between lots of little text files, and a few 
much bigger text files that cover many classes).

in my idea, it will be up to the VM to figure how to glue the native methods 
to the respective C functions (should be fairly easy in many cases so long 
as one doesn't try to deal with the "full complexity" of it all).
the binding files will be "dumb", and so any non-trivial mapping would need 
to be done in C land (or, in my case, imply the use of my certain "VM 
extensions").

idea thus far:
<command> <arg*>

<classname>:
<method><sig>    <c_function>[<c_sig>]
..

by default, the function is called exactly with the args list, as mapped to 
native types.

'sig' would be essentially the same notation as is used in class files 
(although probably with a few extra/different chars for certain cases).

I am considering '$' would be used in the args indicating to pass the 'this' 
object (by default not passed to called functions), and would have to 
precede other args.

some other chars may used for other special cases and conversions.
probably during calls strings will be converted to UTF-8, ... (most of my 
stuff uses UTF-8 by default).

'c_sig' would be optional and used in more 'advanced' cases, and would 
represent a much more complete version of the typesystem (different notation 
than sig though, basically a descendant of one originally used in my C 
compiler and also increasingly used elsewhere in my framework).

decided to leave out examples.


note, the reason I have not formerly defined a "native interface" system, 
despite having an existing framework, is that my existing framework had used 
the C calling convention and typesystem as the baseline, and so there was no 
real need to map anything.

note, my effort is not something I expect anyone to really know or care 
about, just generic hobbyist crap I guess...