tjmonk15 wrote:
m12: I see a number of problems with your response (Feel free to justify a problem I see and say it is necessary, that's the game we play
)
OK
Quote:
m12 wrote:
@tjmonk, add ease of ui customization to that list, and our goals are pretty close to identical.
This is indeed a design decision I plan to solve as well. But it is just that, a Design Decision, not an architecture one.
true
Quote:
m12 wrote:
I think the basic instructions I need to support are:
move, swap, add, subtract, multiply, divide, jump, conditional jump, call
so, 9 necessary operations, round up to 16, plus whatever I choose to add.
If that is all your bytecode can support, I would recommend just using assembly + actual op-codes + verification. And you are missing some crucial ones, namely cli/sti (for time critical code), int (for interrupts/syscalls), among many others, unles you have a CLR type enviroment, where all syscalls are inside an library(s) provided by your OS that has access to protected instructions.
No, it's just the bare necessities. The environment will be more like clr or jre.
Quote:
Also, I missed a goal of mine, but it is that "untrusted" executables from other OS can be executed, namely Linux (GNOME only to start with) and Windows (Win32 api only to start with) Where binary apps can be run. These can be secure by allowing a "registry" that is not global as Micro$oft's is. But, continuing...
I'd like to implement this as well, but I have a different method. I'll allow copyright holders to provide a wrapper layer for their apis in my bytecode, and I'll include a port command to convert executables to the bytecode. This however isn't immediately relevant, and probably needs to be thought out better.
Quote:
m12 wrote:
one byte should be sufficient for the first version, but better yet, 4 bit prefix, and twelve bits for the instruction.
You have 9 op-codes atm. Why plan for 65536???? (4+12 = 16 bits 2^16....)
It's 4096 opcodes. The prefix serves a completely different (and necessary) purpose. I'm not allowed to prepare for the future?
Quote:
m12 wrote:
I can then chop off a byte from registers, and chop off the third register field, shortening the bytecode to eight bytes. For immediate values, I can define a special register, indicating that the next instruction is immediate value data.
I think you are missing the point. For a VM/bytecode implementation, you don't fix the size of op-codes. You make then as small as possible in most cases, and in the "ab-normal" cases make them bigger. NOW, in CPU creation, the design is done such that the circuits such as those that are used the most are fastest (<=1 cycle) and others are 2 or more cycles. You need to understand this and build it into your design.
If you take an instruction that is 1 cycle to compute, but make it 4 bytes big in your code (when the CPU only needs 1 or 2 bytes) you are adding memory accesses on top of the compute time. (A single instruction might be 1 cycle, but a RAM [not cache] access might be 100+ cycles. Don't even mention HD or network access here hahaha) So you have to keep all of this in mind. And even more is that you need to realize hardware is designed in such a way that it handles the common case far better than the ab-normal case.
I'll admit I didn't think of this.
Really, it depends on how I implement it what the best case would be. if I choose to at install time convert it to native machine code, the bytecode size will hardly matter. if I choose to run the bytecode, though, then yes, this would be a good thing to keep in mind.
Quote:
Chainging the "playing field" drastically is possible, but you must do it in a way that convinces others to follow along... (This is how M$ has the market share they do...)
<offtopic>
Have you taken a look recently at the market shares? For the devices I'm targeting, it's Google 75%, Apple 15%, Microsoft 2%, Others 8%
</offtopic>
I'm not gonna give an actual comment just yet on this.
Quote:
m12 wrote:
For 150000 lines of code, assuming roughly 3 operations each, I'm looking at about 5.14MB of per application, plus data (icons, readmes, etc.)
15 MB isn't too bad for a 2D tablet game is it? Of course, that's a best case scenario, but...
A 5.14MB App??? o.O I would not worry about that, And more importanly, 1 line of code != 1 line/instruction of assembly. In reality, it is incredibly common that one line of code >= 3 lines of assembly.
[[All numbers are "pulled from my rear" but based on experience/knowledge/reality as best as I am capable of....]]
I was also making my best guess. Instructions such as
Code:
x %= x - function(x, y, z, class.staticfunction(z, y, x), new int[6][7][8]); // or your similiar line of code
would most certainly take up several (at least thirteen in this case) instructions.
There's no reason that
Code:
x = y;
should take up more than one instruction though: mov x, y
Thank you for the discussion, btw. And for the (very) valid points.