OSDev.org

Have you seen this?

http://copy.sh/v24/

great fun, and a quick way to try out simple OS's

Edit: I deleted the comment as it was too negative and not helpful in the slightest.

Just tested Kolibri OS through my android device.
Thanks for the Link but it's slower maybe cause it's online and programmed
in java script......

Is it supposed to be able to handle 32-bit mode or is it limited to real mode?

Unimplemented: callf
Execution stopped

It puts up that message within a few seconds with MikeOS32 and my own OS.

MikeOS (16-bit version) worked, but even that had errors: I went into the hangman game and it wouldn't display the crucial part where the word is supposed to appear as you guess the right letters - it doesn't even show you how many letters there are in the word, but this normally works fine when run directly or in other emulators.

Some work to do then, but it's a great idea - makes it easy for ordinary people to try out an OS safely without having to download or install an emulator.

Does ayone know who wrote it?

[Edit: I see it's been done before though. http://forum.osdev.org/viewtopic.php?t=23612.]

Worked fine with the (very) old version of BOS that I had up on my site, and that even does some wierd jumps back and forth from 16-32 bit IIRC. Pretty sweet, even with the obvious limitations.

Strange, may be my browser or my false attempt at using it, but it does not work at all for me.

Did you try the FreeDOS image that is available? For my old BOS version eveything worked as expected, even going back from 32-bit mode to 16-bit, enter mode 0x13 and back into 32 bit. Maybe that's why I think it's sweet, because my old source runned as well as it did.

An emulator written in an interpreted language? Not exactly efficient, but interesting nonetheless.

metallevel wrote:An emulator written in an interpreted language?

Being more pedantic than usual I would like to point out that all of the symbols we programmers use are interpreted at some level, all languages used are interpreted, all microprocessors interpret their opcodes and in some cases even the operands are interpreted.

Try on my Andriod OS, get some issuse on old version, is it work for java os.

metallevel wrote:An emulator written in an interpreted language? Not exactly efficient, but interesting nonetheless.

Don't forget about JIT compilation. Btw, AFAIK, in V8 there's no interpeter mode - only compilation (two compilers are included: quick and optimizing).

bwat wrote: Being more pedantic than usual I would like to point out that all of the symbols we programmers use are interpreted at some level, all languages used are interpreted, all microprocessors interpret their opcodes and in some cases even the operands are interpreted.

Yeah, but microprocessors do it in hardware. Some microprocessors are microcoded too, but that is slower than running on tailor made hardware.

Nable wrote: Don't forget about JIT compilation. Btw, AFAIK, in V8 there's no interpeter mode - only compilation (two compilers are included: quick and optimizing).

Is JIT compilation often used with JavaScript? I know Java uses it a lot, but I haven't heard of many cases of it being used with JavaScript.

EDIT: Looks like JIT and AOT compilation actually have become quite popular for JavaScript recently. But I still wouldn't regard such techniques as 'efficient' (except compared to simple interpretation), since time must still be taken to compile the program on the user's end.

True - though the compilation only has to be done once, and compling C to asmjs (a subset of JavaScript designed to be easy to optimise) can be as little as a factor of 1.5x slower than native. Which, although noticable for an emulator, is not that significant for many tasks.

metallevel wrote:

bwat wrote: Being more pedantic than usual I would like to point out that all of the symbols we programmers use are interpreted at some level, all languages used are interpreted, all microprocessors interpret their opcodes and in some cases even the operands are interpreted.

Yeah, but microprocessors do it in hardware. Some microprocessors are microcoded too, but that is slower than running on tailor made hardware.

You are, of course, right to point out the huge difference in instruction latency. The rule of thumb is 1 to 2 orders of magnitude increase in execution latency for a program for each level of interpretation. In the system I'm currently building the source interpreter is roughly 240 times slower than the bytecode interpreter. These days I'm no longer surprised when I find bytecode interpreted code to be good enough. Here's an old paper from a Smalltalk company talking about bytecode interpreters and some of their advantages (like code density - just to widen the scope from the rather narrow latency-is-top-priority viewpoint):
http://www.object-arts.com/downloads/pa ... IsDead.PDF

Nable wrote: EDIT: Looks like JIT and AOT compilation actually have become quite popular for JavaScript recently. But I still wouldn't regard such techniques as 'efficient' (except compared to simple interpretation), since time must still be taken to compile the program on the user's end.

Every time a compiled code routine is executed, the cost of compilation per compiled instruction executed is lowered and efficiency is increased. Again, it is a question of what is good enough. I worked on an AOT compiler project that was shut down because the JIT sister project turned out to be good enough even for applications that were deemed to be time critical and therefore in need of AOT compilation.

Ultimately, you never know until:
a) you get your hands on a specification, and
b) you do some measurements.
Until that time we're just working off technical prejudice and guesswork.

JIT compilers can be very efficient depending on what kind of code is being JIT compiled. Basic math operations and loops can often be trivially JIT compiled into machine code that runs at native speed.

Running code that performs bounds checking, dynamically looking up properties, evaluating code dynamically at runtime, etc. obviously is going to run much slower, as any JIT compiler is either going to have to generate a lot of extra code to run this code, or invoke it's own code.

The purpose of asm.js is to have Javascript code that falls into the former category (simple array buffers, loops, and math operations) and removes a lot of dynamic stuff. It intends to be used as the backend of compilers, such as Emscripten (the LLVM to Javascript compiler that enables you to run C++ code in your browser), that can easily be JIT compiled and run at near native speed.

But, why not go crazy?