greetings here...

[BGB]

sorry again, just more me and ideas...

----- Original Message ----- 
From: "BGB" <cr88192 at hotmail.com>
To: <mlvm-dev at openjdk.java.net>
Sent: Monday, October 13, 2008 10:12 AM
Subject: greetings here...


> well, ok, I will say I am new to this list, but am hoping for interesting
> conversations.
> sorry if in being new here, I am being an ignorant troll.
>

<snip>

>
> hypothetically:
> 240-243 <byte>: a group of 64 blocks of 16-opcodes
> 244-247 <short>: 1024 blocks of 256 opcodes
>

(in all this I am just loosely assuming that these ranges are unused...).


ok, this could be possibility A.

next possible:
extended space is conceptually linear.

0-239: as before (group A)
240-243 <u1>: opcodes 256-1023 (group B)
244-247 <u2>: opcodes 1024-262143 (group C)
248-251 <u3>: opcodes 262144-67108863 (group D)
252-253 reserved
254: impdep1
255: impdep2

groups A and B only have opcodes defined officially, and not by 3rd parties.

group C is divided into groups of 256 opcodes, which may be 'registered', 
and are generally to be considered implementation-specific or experimental.


group D is more or less free range, and can be divided into groups of 1024 
opcodes. this would be for highly experimental features, and people will try 
to make use of "best effort" to avoid clashes (of course, even using a 
random number generator should reasonably avoid clashes).

another possibly strategy for allocating spaces in group D, could be to 
specify that one uses a hash of the prefix they would use for their opcodes, 
which would probably unlikely clash (or, they go to the next permutation if 
there is a known clash).

nmonics in groups C and D could have prefixes to minimize clash with later 
official nmonics or with those of other implementations (for example, I 
could have a prefix 'bgbvm' or similar...).


now, as for impdep1/2, well, they still work as before. they would make 
sense for stuff the implementor thinks no one else will ever want to use...


possibility B:

similar, but using a smaller range of opcodes:
248-250 <u1>: opcodes 256-1023
251 <u2>: group C, 1024-65535
252 <u3>: group D, 65536-16777215
253 <u4>: group E, 16777216-4294967295
254: impdep1
255: impdep2

group D is as before, but is groups of 256 opcodes.
group E could be "free range" (its use is almost like that of impdep, only 
that opcodes are expected to be recognized by some magic of their value).

as before, the verifier rejects the file if it contains anything 
unrecognized (and a compiler refrains from generating any opcodes unless it 
is sure the target will accept them, the default being to only generate 
valid/baseline opcodes). this would be sort of like on x86 and friends (but 
maybe with a little less bit-mongering...).


in any case, otherwise probably will otherwise put any special opcodes in 
impdep (and refrain from generating and class-files with any extended 
opcodes), as I guess is the normal idea anyways.

(note, I probably will generate stuff, since my framework already exists, I 
will probably just change around the target of some of my pre-existing 
compilers, ... it was all this or make my own entirely custom bytecode 
formats, which I have done many times in the past...).


will not detail what I am thinking exactly, only that they will probably be 
for more dynamically typed operations, and also for raw pointer ops (which I 
do have some reason to have, since after all I probably will eventually 
target my C compiler to it, as well as generating native code, ...).

now, I just figure, for example, if multiple implementations decide to 
support, for example, fixnums or cons cells, maybe implementations can 
separately innovate these features, and be able to easily make use of each 
others' innovations (vs each having to roll their own entirely-incompatible 
option).


but, then again, maybe these sorts of limitations better help enforce 
adherence to the baseline?...

then again, maybe I am thinking too far outside the normal usual usage 
domain, or these sorts of ideas are too far unreasonable?...