sorry again, just more me and ideas... ----- Original Message ----- From: "BGB" <[EMAIL PROTECTED]> To: <[email protected]> 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?... _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
