h a l f b a k e r yRecalculations place it at 0.4999.
add, search, annotate, link, view, overview, recent, by name, best, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
The slogan "write once, run anywhere" or WORA, was coined by Sun Microsystems to illustrate the cross-platform benefits of the Java language. Unfortunately, when applied to Java this slogan is far from the truth; multiple Java VMs exist, and not for every platform, and for every VM you want your program
to be compatible with, you'll have to debug for. The idea here is intended as a realization of that ideal envisioned by Sun.
So to get right to the point, first there needs to be a reference interpreter, or reference VM if you will. Then the HLL (high level language) to bytecode (VM equivalent of machine language) compiler may be written to run in that interpreter. How is that any different than Java? you ask. How is it any easier to get the same program running on every architecture desired with this? I'll answer that now.
It is simple; the VM can only handle console I/O and a single instruction. Console I/O is supported in some manner in nearly every OS. There are a number of OISCs (One Instruction Set Computer) to choose from for the architecture definition, but that is immaterial so long as a standard is defined.
So, with the theory out of the way, I'll get back to the engineering part of the problem. There must be a reference interpreter defined in the standard. There must also be an interpreter that runs on your desired platforms. Creating such an interpreter is a trivial problem, and would probably be less than 100 lines of code, depending on the language and platform. An interpreter written in ANSI C could be easily adapted for several platforms. Interpreters written in other languages like Java and FORTRAN are not out of the question, and may well be desirable.
The hard part would be the compiler. There must be a compiler that supports at least one common input HLL, such as ANSI C, for the VM to be of any use to software developers. Writing a compiler that compiles only one language, again C for example, to a OISC architecture would be a big undertaking. Writing the same IN that architecture would probably be the single largest software development undertaking ever. Ideally, more than one common language should be supported. Heh.
http://en.wikipedia...uction_set_computer
[Spacecoyote, Mar 02 2009]
OISC with PL/0 (simplified Pascal) support
http://compilers.ie...h/article/88-11-019
from 1987 [Spacecoyote, Mar 02 2009]
[link]
|
| |
Ideally, yes, but I'll allow support to differ between implementations as necessary. |
|
| |
Hmm...If the input language was Java and the target environment was Java, things could get quite interesting. |
|
| |
Of course, this would all be too slow for any real computing task. But for some simple things it would be nice to be able to have the same program anywhere. And I mean anywhere. It would be relatively easy to knock out an SRE interpreter in Javascript. |
|
| |
If it only uses console I/O, couldn't you just write the program in C? |
|
| |
That only works when you have the source code. This makes a single binary that works on all platforms without recompilation. |
|
| |
Also, the bytecode produced by the compiler is inherently extremely difficult to decompile, even without encryption. This is good where security or reverse engineering is a concern but cross platform compatibility is required. |
|
| |
// the VM can only handle console I/O and a single instruction
What does the single instruction do? |
|
| |
I don't understand what the point of this is.
You want an implementation of Java, only yours won't have bugs? That's a halfbakery invention how? |
|
| |
Wikipedia gives a few examples of possible instructions that, alone, make for a turing-complete instruction set. One example is as follows: |
|
| |
subleq a, b, c ; Mem[b] = Mem[b] - Mem[a]
; if (Mem[b] <= 0) goto c
subleq means "SUBtract and branch if Less than or EQual to zero". |
|
| |
Such single instructions are to software what a NAND gate is to hardware: any other instruction may be synthesized from it. For example: |
|
| |
ADD a, b ==
subleq a, Z
subleq Z, b
subleq Z, Z
|
|
| |
where a and b are the registers to be added and Z is a register initially containing zero. |
|
| |
The point is that even though the compiler would be very hard to create, the interpreter is trivial to create. So if you have some programs made for SRE and you want to run them on a platform that doesn't have a SRE interpreter, you simply write your own. For a good programmer, it would be less than an hour's work. On the other hand, porting the JRE (either Sun's or GNU's) would be a huge amount of work. |
|
| |
Also there's the point I made earlier about security. From the standpoint of anyone requiring high security against reverse engineering this makes so much sense that I wouldn't be surprised if this were baked in some secret government way. |
|
| |
This is not Java. Not by a long shot. |
|
| |
This may end up becoming baked for entirely different reasons than I thought of. It is possible to make chips containing simple logic at VERY TINY half-pitch sizes and running VERY FAST (I'm talking like 15nm at hundreds of gigahertz). Such technology is impractical for use with current architecture paradigms. But a massively-parallel single instruction set, many pipeline chip would be ideal for this. |
|
| |
What programs do you imagine being run on this VM? I can see the benefits of a tiny, easily written interpreter that could run some generic utilities on a newly designed computer. But what else? Console I/O only is going to be a bit limiting. |
|
| |
Also, I doubt that programs will be terribly resistant to reverse engineering. If it is popular, then some hackers will learn to read it. I suspect it would be easier to read than obfuscated C code. With machine code, you know exactly what an instruction does just by looking at it, but with modern languages you can modify the behavior of an instruction with a declaration in a different file. |
|
| |
Well different devices can be piped to/from stdio, depending on what your OS supports, theoretically the possibilities are limitless. This is however, unlike Java, not meant for everyday computing, only special purposes. What purposes I don't know, but they're certainly out there. |
|
| |
I hold my position on reverse engineering. The difficulty of deciphering this machine code would be somewhere between that of deciphering brainfuck and deciphering malbodge. There are of course further ways to increase obfuscation if desired. |
|
| |
The single instruction could be HCF. |
|
| |
I've always found the local park simple enough. |
|
| |