Author
It would be more of a combination of os and language really.
Programs would be a bunch of commands rather than assembly
instructions.
Modules of assembly(for things too low-level to be handled by
the os, like adding) could be added on and before program
execution starts the os checks each module to see if it
accesses anything that it''s not supposed to.
I think it might be more secure and program size would
be drastically reduced.
In order to avoid redundant flames, I''ll state now for the
record that I don''t know a lot about operating system design.
Create.
Liv Tyler makes a really great elf.
AHHH!!! Everywhere I turn there''s a wall! Help I''m trapped! just a few comments I think you can expect.
quote:Original post by RolandofGilead
Programs would be a bunch of commands rather than assembly
instructions.
(1) What are assembly instructions if not "a bunch of commands"?
(2) It''s called "an interpreter". Interpreters are fine for some things, but not fast. This is why we have compiled languages.
quote:Modules of assembly(for things too low-level to be handled by the os, like adding) could be added on and before program execution starts the os checks each module to see if it
accesses anything that it''s not supposed to.
Or, just use plain ol'' assembler and let the processor do the checks for you.
Sure, you can run stuff in a virtual machine (either interpreted or JIT-compiled), but you pay a penalty (speed and memory, particularly the latter) for doing so.
quote:I think it might be more secure and program size would
be drastically reduced.
In order to avoid redundant flames, I''ll state now for the
record that I don''t know a lot about operating system design.
Why would one bother designing an entire OS in this way when one can readily run Java or .NET apps on a regular OS, and only pay for those overheads when one wants to?
quote:Original post by DrPizza
(1) What are assembly instructions if not "a bunch of commands"?
(2) It''s called "an interpreter". Interpreters are fine for some things, but not fast. This is why we have compiled languages.
Actually, Symbolics (http://www.symbolics.com) has ported the Lisp OS (Genera) to the Alpha architecture (before that, they used native Lisp Machines that were extensively used at the MIT AI labs) and it runs faster interpreted because the interpreter fits in the cache.
quote:
Sure, you can run stuff in a virtual machine (either interpreted or JIT-compiled), but you pay a penalty (speed and memory, particularly the latter) for doing so.
See above. I''m not saying than this is the norm, but it''s still possible.
Why would one bother designing an entire OS in this way when one can readily run Java or .NET apps on a regular OS, and only pay for those overheads when one wants to?
Because Java and/or .NET aren''t very well suited for some specific tasks (math intensive, AI, whatever), and because, unlike Lisp (or ML or most (sll?) functionnal languages), they won''t let you redefine "functions" (or macros, methods, etc, depending on the language) from within the interpreter loop.
Now is Genera a good all around OS? Probably not. But specialized OSes still have a use (especially in the embedded niche) and the idea of running a virtual machine/interpreter as a shell certainly isn''t bad.
Author
I''m well aware of the performance hit.
I''m also not talking about interpreting,
each command would be similar to a call to a .dll,
which we use all the time and don''t complain about
performance.
Another way might be to make the compiler replace
each command with the actual system code.
Create.
Liv Tyler makes a really great elf.
I''m also not talking about interpreting,
each command would be similar to a call to a .dll,
which we use all the time and don''t complain about
performance.
Another way might be to make the compiler replace
each command with the actual system code.
Create.
Liv Tyler makes a really great elf.
quote:Original post by Anonymous Poster
Actually, Symbolics (http://www.symbolics.com) has ported the Lisp OS (Genera) to the Alpha architecture (before that, they used native Lisp Machines that were extensively used at the MIT AI labs) and it runs faster interpreted because the interpreter fits in the cache.
It can run "fast" interpreted but it can''t ever run "as fast" as compiled code.
quote:Because Java and/or .NET aren''t very well suited for some specific tasks (math intensive, AI, whatever), and because, unlike Lisp (or ML or most (sll?) functionnal languages), they won''t let you redefine "functions" (or macros, methods, etc, depending on the language) from within the interpreter loop.
Bzzzt, incorrect, .NET does (dunno or care about Java). Not all functional languages have an "eval()" construct (e.g. O''caml), but languages that do (e.g. JScript) can work just fine -- and do -- in .NET.
quote:Now is Genera a good all around OS? Probably not. But specialized OSes still have a use (especially in the embedded niche) and the idea of running a virtual machine/interpreter as a shell certainly isn''t bad.
It''s customary to run an interpreter as a shell . I''m not sure it''s either customary nor beneficial to force code to be interpreted.
quote:Original post by RolandofGilead
I''m also not talking about interpreting,
each command would be similar to a call to a .dll,
which we use all the time and don''t complain about
performance.
...
This is what my compiler puts out already -- sequences of machine code (for things that can''t be done using a library (i.e. "the OS")) intermixed with calls to library functions. The only way you could distinguish what you''re proposing from what''s already done is to not use machine code but instead something interpreted (or at the very least, JIT compiled).
quote:Another way might be to make the compiler replace
each command with the actual system code.
It''s called "static linking".
quote:Original post by DrPizza
It can run "fast" interpreted but it can''t ever run "as fast" as compiled code.
It can, once again because the Lisp interpreter fits in the cache. A compiled program (read "bigger"
might not always fit in (the Lisp interpreter is actually very small).quote:
Bzzzt, incorrect, .NET does (dunno or care about Java). Not all functional languages have an "eval()" construct (e.g. O''caml), but languages that do (e.g. JScript) can work just fine -- and do -- in .NET.
I''ve never stated than eval (or its equivalent) won''t let you redefine a function. Simply than compiled (to native code) code won''t be able to do that given its ''static'' nature.
And fact remains than some specialized OSes (I''ll keep Genera as an example) are much better suited for some tasks (in this case symbolic math). I don''t see .NET and JScript owning that niche anytime soon, just like it won''t overtake massive clustering either: it wasn''t designed for that.
quote:
It''s customary to run an interpreter as a shell . I''m not sure it''s either customary nor beneficial to force code to be interpreted.
It''s not customary, but it does exist, and the possibility to alter the way the OS works - without even needing ugly hacks at the source and a reboot - is a very interesting feature that can''t be achieved when everything is done in native code. So yes, it can be beneficial.
Just try to change the behavior of, say, "cd" in either windows or a *nix without hacking the source and starting a new shell.
Note : this isn''t meant to start a flame war at all, I''m merely stating my (now out of topic) opinion.
quote:Original post by Anonymous Poster
It can, once again because the Lisp interpreter fits in the cache. A compiled program (read "bigger") might not always fit in (the Lisp interpreter is actually very small).
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.
quote:I''ve never stated than eval (or its equivalent) won''t let you redefine a function. Simply than compiled (to native code) code won''t be able to do that given its ''static'' nature.
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.
quote:And fact remains than some specialized OSes (I''ll keep Genera as an example) are much better suited for some tasks (in this case symbolic math). I don''t see .NET and JScript owning that niche anytime soon, just like it won''t overtake massive clustering either: it wasn''t designed for that.
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.
quote:It''s not customary, but it does exist, and the possibility to alter the way the OS works - without even needing ugly hacks at the source and a reboot - is a very interesting feature that can''t be achieved when everything is done in native code.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
