quote:Original post by DrPizza The interpreter alone is not good enough. You need a program to run, which may or may not fit into cache; it may even push the interpreter out of cache. You can be faster if compiled simply by ripping out the front-end to the interpreter (i.e. the bit that parses the input and calls the right bits of the interpreter) and hard-wiring (according to the particular program) a particular flow.
I''ll just tell you to go to http://pt.withy.org/VLM.html and read the full article. They explain it much better than I can.
quote: Yes, it can. JScript.NET is compiled. JScript.NET lets you redefine functions, use "eval", and so on. For instance: I can have an object with a method. At runtime, I can prompt the user to type in some code, and I can replace that existing method with the one the user typed in. All on-the-fly, despite it being compiled code.
JScript.NET is compiled to bytecode and running on top of a JIT compiler. Not exactly a native, architecture dependant binary. That can be done with any "scripting" language, even when it''s compiled to bytecode (since that''s really how JIT works anyway): Python, Perl, Java, etc.
quote: The fact remains that compiled code can always run faster than interpreted code, even if it means simply hard-wiring the interpreter to run in a particular manner.
That''s not really a counter argument. How does it make specialized OSes useless or not-as-useful?
quote: YES, it bloody well CAN.
Self-modifying programs are not unheard of. Compiled languages can have eval() constructs. Patching running programs is perfectly possible. Patching running OS kernels is perfectly possible.
Agreed. Would you rather manipulate the flags of your program''s memory pages just to change its behavior (and all of that from a shell prompt, good luck), or just type a few characters and hit enter? Self-modifying (native) programs certainly aren''t unheard of, but there is a reason you just aren''t permitted to do that on most OSes at the user level: it''s error prone, unsafe, hard and hardware dependant.
Now I''ll leave this thread, as I don''t want this to turn into some language advocacy thing or worse. I''ve got usenet for that. Feel free to annihilate what I''m saying anyway .
I just wanted to add that .NET also lets you generate and execute assemblies dynamically at runtime.
Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
I''ve actually been working on something a bit similar. That is, an entirely Virtual Machine OS. I know we have Java and .Net, but this would be different. I''m going to create it so the primary way it runs is as the main OS. Meaning that it isn''t just something running on the computer like another program, the VM would be the only program running natively, and you would never see the underlying OS (linux).
The Virtual Machine is currently codenamed "Black Feather". I am working on its Assembly langauge, "Raven" and a programming language "Raven Cawl", ''cawl'' being the sound a Raven makes.
It is heavily module based. The virtual hardware consists of one virtual processor per function being run. That means each module has a processor for itself, and another one each time a function is called. I know it seems bloated, but I can do this without much overhead i think. The processors are more mental than actually coded.
All modules can communicate with their parents (module which spawned them) through a dual-pipe binary stream. Requests can be made for pipes between other modules as well.
As for how this OS will view hardware: Harddrive Prime will be the drive holding the VM and most you software (probably). The contents of this drive are very dynamic, as they do not represent archived, waiting-to-be-used data, but instead represent the current state of the modules. The RAM is simple a holding place for currently-in-action modules and code. Other drives can then be accessed as modules which can return several other modules (their contents). There are no "files" in this system, that seems outdated. Instead, a basic "Document/Text" module type returns an ASCII or Unicode stream, and has functions to edit the contents of that stream.
This is all still vaporware, but only until I get a test system built to start developing.
Additionally, this also includes a third codename, besides Black Feather and Raven/Cawl: Scream. Scream is an almost but not quite seperate project for a set of standard data types, such as integers, images, sound, text, formatted text, GUIs, etc etc etc.
If anyone is interested in this project, please e-mail me. (ironfroggy@yahoo.com)
// God.c void main() { WORLD Earth; LIFE People = Earth.CreateLife(HUMAN); GiveHope(&People); delete Earth; EvilCackle(); }
.
