OSDev.org

I've been pondering on this for a while and now I'm decided to pursue it, here are the features I'm thinking of:

- exokernel with only logic to prevent race conditions and illegal access
- default console is a javascript console instead of an unix shell
- direct hardware access in javascript like this - direct C bindings in the parser for certain things to improve performance (for OS and standard library functions)
- possible POSIX API
- vim-like editor for autocompletion in Javascript and OS functions / libraries

if I get a POSIX API I might get a framebuffer webkit browser too, and maybe some other GUI applications

I would prefer this to remain as a Node.JS/Javascript development environment though

Thoughts?

It sounds like a great idea. And it sounds like a lot of work.

I have been working on a similar design for about 8 years now. I created my own "language" using XML files and XSLT transforms, because I couldn't find any "modern" Assembly tools. And my console shell is similar to Node.JS in that you can create objects and call methods, and the results are converted to a string and displayed.

The real trick would be writing your compiler and build tools in JavaScript, writing your kernel in JavaScript, and then writing your Node.JS runtime in JavaScript.

Some of that may already exist. But in any case, I'd be interested in seeing what you can come up with. Just let me know if you need any help.

Good luck.

SpyderTL wrote:It sounds like a great idea. And it sounds like a lot of work.

I have been working on a similar design for about 8 years now. I created my own "language" using XML files and XSLT transforms, because I couldn't find any "modern" Assembly tools. And my console shell is similar to Node.JS in that you can create objects and call methods, and the results are converted to a string and displayed.

The real trick would be writing your compiler and build tools in JavaScript, writing your kernel in JavaScript, and then writing your Node.JS runtime in JavaScript.

Some of that may already exist. But in any case, I'd be interested in seeing what you can come up with. Just let me know if you need any help.

Good luck.

Hey SpyderTL thanks for the reply and your positive words! Your system sounds very interesting and alike to what I want to accomplish, I'm planning to write the kernel in ASM/C then add the node.js interpreter (a modified one that can do device access and execute certain things). Yes this will project will be quite the hard work but I'm only thinking of implementing the most necessary things for execution on the kernel side and there's already code for the QEMU drivers (my first target, I'll port to other boards and architectures later) and also if I implement the POSIX bindings for node.js (syscalls and stdlib functions for example) I should be ready to go. My main target with this is to write an OS totally optimized for Node.JS that will also have some native bindings to C for extra performance and use architectural features to squeeze some more.

I would definitely like to benefit from your mastery and keep contact if you have an email or Skype to speak more!

Regards
Jim

Most people here would disagree, but I would recommend not worrying about performance at all until you have everything working like you want it. The reason is that any time spent speeding up code that will ultimately be replaced in a redesign will be wasted, so wait until everything works and you're happy with the design before working on performance. It will also allow you to use your "slow" working code as a baseline to verify that your new code is indeed faster and nothing gets broken in the process.

If you had to pick one feature that you want to have working before anything else, what would it be?

SpyderTL wrote:Most people here would disagree, but I would recommend not worrying about performance at all until you have everything working like you want it.

I'd generally agree, but I think the exception is when the fundamental design already has an impact on the performance. Because what you say is true the other way round, too: All the work for nice functionality is wasted if you have to throw it away for a design that allows better performance.

For example, if you have something that can benefit a lot from multithreading, maybe you should write it that way from the beginning, because making a single threaded program thread-safe after the fact is a PITA.

You will still need a fully functioning kernel before you could tack on a javascript shell.

https://developer.mozilla.org/en-US/doc ... ript_shell

It's obvious that a JS shell is not in any way tied to the kernel, and can be implemented on top of any system.


PS. What's with the title of this thread? "Javascript state machine in ARM64", eh?

You could implement JavaScript as a library instead of as a language.

For example, you could provide direct access to the full set of raw "native code" functions, being able to access them without having to use the path of objects like "Math.pow()", but just a pointer to "pow".

Then you could provide a structure for objects, constructors, and the object path to the functions.

You could give the API a processor-native but transparent way to pass parameters and make calls, maybe even the freedom to select between Big Endian and Little Endian like with Typed Arrays.

You could make the API to be directly usable from C and Assembly, and then you could even use JavaScript functionality in your kernel, maybe not the language itself but just the functionality in a library, but with that you could make many things much easier to program, even porting back and forth the logic written in JavaScript, from webpages to your kernel, as well as from your kernel to webpages.

You could also define DOM and HTML5, and then internally you could base your windowing system in the HTML structure of documents, which would standardize and speed up the development of the system from there.

If you want to run node.js you'll have to port Google's v8. Porting v8 to a POSIX system is probably relatively straightforward (I did not try this; I can only guess based on my experience with porting other programs). Porting to a different environment (e.g. an exokernel) is probably more work. Try to look at the platform-specific v8 code and at v8's dependencies to get a better idea of what subsystems your kernel needs to provide in order to be able to run v8.

I stumbled upon this project today, which may be pretty close to what you are looking for. I may keep a copy on a VM just to play around with.

https://github.com/NodeOS/NodeOS

It essentially runs on a Linux kernel, and boots directly into NodeJS REPL as a shell. Bootup takes a few seconds, but shutdown (.exit) is instantaneous.

SpyderTL wrote:I stumbled upon this project today, which may be pretty close to what you are looking for. I may keep a copy on a VM just to play around with.

https://github.com/NodeOS/NodeOS

It essentially runs on a Linux kernel, and boots directly into NodeJS REPL as a shell. Bootup takes a few seconds, but shutdown (.exit) is instantaneous.

It gives a kernel panic when you try to use TAB for completions and my implementation is somewhat different, but it's function is very similar to mine pretty much, I'm thinking of making the OS (read, line, cat, ls and so forward) functions available on the Node.JS REPL shell (or write new commands using the file access etc. module of Node.JS)

I got the trial for ARM DS-5 IDE and I'm about to write the first parts of the exokernel, I'm excited!