[unios] Bytecode format

[Pat Wendorf]

Andrew Coles wrote:

> Hi.
>
> As I understand it from the documents section one possibility for the
> distribution of applications is a platform-independant bytecode format, ie.
> code to run on a non-existant CPU is converted into native code on-the-fly.

Yep that was the general idea, but rather than always converting on the fly, it
may also be compiled for the target platform when it's installed. This would
speed things up considerably.  For example, if you install a Word Processor
type program, it would seem silly if you have to recompile every time you run
it (that's like Java... too slow).  If the bytecode is kept along side the
architecture (native) code, even if the hardware environment changed, it could
still be run, or recompiled.  This makes the whole application binaries quite
large, but if the system is static (no hardware changes), the bytecode could be
deleted leaving just the native binary.   I'd imagine the only way this would
work though, would be some kind of execution determination system  where it
looks for the native code binary first (and validates it against the current
system), then the bytecode.

>If not then I'm proposing it as an idea ;-) Comments? I am in favor of

> this idea as it is highly platform independant and I predict that it would
> be quicker to convert the bytecode into a native binary faster than it
> would be to recompile a piece of C/C++ code.

> Another comment, although this may be stating the obvious (FYI: I've read
> the mailing list archives) - UniOS must, IMHO, be designed from the ground
> up to support multi-processing. Otherwise it is time-consuming and
> less-efficient to hack multiprocessing support into the kernel after it has
> been written (Linux SMP, for example).

I was thinking it would be part of the hardware abstracts.  I'm not completely
familiar with SMP programming, but I imagine it could be implemented with the
System object (or kernel).  Then the programs could be compiled to take
advantage of it (they are platform neutral, and therefore SMP neutral also).
Actually the only way of implementing SMP that I know of is having the programs
multi-threading(threaded).  If anyone has and idea beyond that, please say so
:)

> Hopefully this will start some sort of discussion (for example, about
> possible instructions or pseudo-instructions for the bytecode) :-)

I've been working on that for a while, but I believe we have to finalize on a
design. I think that this may be necessary, because we don't even know HOW
programs will run on the system, so the details of a bytecode system are
unanswerable at this point. We have many ideas, but I don't think we're all
comfortable enough with a design (or it would have been written ;)  to start
with it yet.

I think the prototyping effort will bring us closer to a design.  Hopefully
everyone can look over the structure that we have, and change it accordingly.
I've seen some criticism of the current structure, so I don't want to jump
ahead to coding anything yet (even if it's just ideas, it would still be a
waste if I missed something important in the basic structure).

--
-----------------------------
Pat Wendorf
UniOS Group
http://unios.dhs.org
beholder@ican.net
ICQ: 1503733
-----------------------------