Re: If it works, this might be interesting
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 29 May 2007 13:50:53 +1000
<rhyde@xxxxxxxxxx> wrote in message
news:1180397367.488807.217290@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On May 28, 4:11 pm, "cr88192" <cr88...@xxxxxxxxxxxxxxxxxx> wrote:
<r...@xxxxxxxxxx> wrote in message
news:1180385189.431973.92990@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://www.openlina.com/index.html
Lina is a VM that allows one to run unmodified binaries under Linux,
Windows, Mac OS, and other OSes with the look and feel of the native
OS. Software is written to the Linux API. Don't know the details, and
I have my doubts as systems like this have come and gone in the past,
but it would be interesting to develop GUI apps that you write once
and can run on all these OSes.
hLater,
Randy Hyde
but, at what cost?...
They claim it's not that bad.
depends on how one defines 'cost' I guess.
there is more than just performance, such as dependencies, ability to
"abandon ship" absent to much work (ie: code is still useful even if the VM
project dies, ...).
for example, I trust C and C++ far more than I trust python, which is still
more than many scheme VMs or other functional languages.
this is a problem of nearly any VM.
VM's generally cost about 10% in performance for normal stuff. Given
that we're talking user interface programming here, that's almost
inconsequential.
yes.
I meant, not performance.
I meant dependency and generality.
nearly anything the VM does, apart from the ordinary, risks becomming a
burden, their benefit a hinderence, ...
But 99% of the time you're doing ordinary stuff. What's your point?
and I was talking about deviation from standards...
even if one is sticking within a standard dialect of a standard language,
there is a risk of nonstandard libraries and APIs.
the more one uses these (often the core of the 'advantage'), is also the
cost, cool new features, but degraded code reuse.
using a non-standard programming language, the situation is far worse
(porting typically requires a good deal of rewriting, often almost complete
destruction and re-creation).
this is why I try to write hopefully portable code, albeit with what I am
doing now (runtime assembly and compilation), this is hardly an easy task
(windows and linux are my target OSs, and x86 and x86-64 my target archs,
with linux and x86-64 currently a lower priority, but I had verified
before
that at least in a trivial way, my stuff works in linux on x86-64...).
That's cool. It's the same thing I'm doing with the HLA standard
library. OTOH, suppose you didn't have to put in all this effort?
Particularly on the GUI interface part of the library code. I don't
know about you, but giving up 10% performance for portability -- IF IT
WORKS -- is a *good* tradeoff.
well, I am odd. I just did my own GUI framework, in C and OpenGL.
migrating between windows and linux, in the past, has not been too much work
(usually, I just replace the code for screen, keyboard, and mouse).
this wont work for everyone though, but for my style of apps this seems to
be good.
my framework tends to be a little more "abstract" than GTK though, ie: I do
not use direct pointers or callbacks, rather names and event handlers (errm,
polling to see if any messages have been generated).
anything clearly different (such as linux on PPC), no go...
Obviously.
yeah.
oh well, at least I have part of my assembler linking and loading in
itself
(note: from object files), and the ability to patch code (ie: replace old
functions with new versions at runtime, ...) is maybe interesting. an
example would be with a frontend UI, altering a chunk of C code and
watching
the app's behavior change in real time, well, assuming it doesn't
segfault...
For a compiler or other command-line tool, this isn't very interesting
technology. After all, achieving portability with such applications is
fairly straight-forward. The real benefit to something like Lina is
with GUI apps. That's what this package is all about.
well, my goal is not to be a command-like compiler (if it were, there is no
real point in any of this).
actually, technically, I am trying to be more like a typical
interpreter-based VM (such as python, perl, javascript, ...), but, also
attempting to sidestep the issues that plague these kind of projects:
a nonstandard language (aka: much of anything other than generic C or C++);
an ugly and annoying FFI (aka, someone off in some dark corner writing all
these wrapper interfaces so that some chunk of C code or some generic API,
can be used, often crudely, from whatever language).
and also the problems that exist with statically-compiled C:
the language/implementation is not reflective (the 'best' there is being
'dlopen', which is just sad...);
code can't modify or rewrite itself at runtime;
....
no, so this compiler wont run on the command line, but will rather be both a
library and a VM of sorts (and still allow fairly raw access to the host
OS).
this is in part because source and binary compatibility with existing libs
is a goal, I would like being able to just grab the mass of libraries and
headers present in mingw, for example, and use without modification.
of course, this will mean at least partly having to clone a lot of gcc's
functionality (or at least as far as the ability to read the headers and use
the libs goes, ie: data representations and calling conventions and some
special funkiness).
not everything needs to be able to be compilable though (luckily, I can
still use gcc for whatever I don't feel like doing dynamically).
so, what is the cost?
Read the white paper at the URL I provided. They talk about this.
ok, usual vague details and comercial-ish style...
skimming, it looks like they still use existing programming languages
according to the table.
I suspect their VM is likely a custom loader and an API, right?...
well, could be worse...
like any VM, it has its own tweaks and incompatibilities. its own
existence
is its weakness.
Again, I want to point out that I said "this is interesting...if it
works." As for it's own existence being it's weakness, I'm afraid
you've lost me there.
the 'perfect' VM would be invisible, and nearly impossible to tell from the
host OS, and something that could be 'added' or 'removed' from an existing
codebase without completely thrashing the project in the process...
but, the VM will always do 'something', so no VM can be 'perfect' in this
way...
now, I do not advocate making the VM part of the host OS, that is a rather
different topic (as I feel right now, this may not be necessary).
one major risk I think with embedding any kind of VM into the OS proper, is
that there is often no longer any kind of 'sandbox' for the code, which
makes security a problem.
sadly, existing OS's/HW hardly do much of anything to
really allow software (at least in C land) to be reflective or
self-writing/modifying.
Uh, with a simple linker option you can make your code writeable.
However, note that writing self-modifying code on a modern x86 CPU is
generally a bad idea. You might try reading the Intel and AMD
documentation for details if you don't realize this.
this is not what I meant.
not the tweaky "mess with the machine code to improve performance" type
stuff, but in the more abstract sense, for example, what we can get out of
languages like scheme, or to a lesser extent python or javascript (where, if
we want, we can generate code programmatically, and 'eval' expressions, and
load and run chunks of source from files, ...).
your typical C app simply can't to the kind of wanton tweakability and
dynamic behavior seen on, for example, websites, or in flash
animations/games, or needed for some kinds of projects, and in part I blame
this on the existing compiler technologies.
yet, dynamic VMs don't come to the rescue, as nearly no VM (python,
javascript, flash, ...) offers the kind of power and control (or
performance) available to a full-fleged app.
I don't view this as purely a language issue (as some do), rather, the way
apps are built makes a bigger difference IMO, and traditional approaches are
intent on turning code into bricks...
the fact that if you write into a section of code, and it kills performance,
is something I am well aware of (I try to minimize this situation).
trying to keep the overhead as low as I can reasonably do so (ie: if I
need
any kind of FFI, I have already lost), but all this may well be asking
too
much.
I have no clue what you're talking about.
FFI:
Foreign Function Interface
big annoying problem with script languages.
we have to wrap all these APIs to be able to use them...
some people went and wrote SWIG, but this is IMO a lame option...
any VM is still a VM...
So?
I think you are confusing an interpretive virtual machine like Java's
with the virtual machine implementation that Lina is using. The two
are not at all the same. You do realize we're talking about native
code execution here, right? The only time anything funny happens is
when you make a system call. Otherwise, it's strict x86 execution.
not performance, again.
VM is abstraction, and often APIs.
a library can be much the same as a VM, but a VM is often worse (since it
often fundamentally changes some aspect of the development process).
I totally dislike Qt, even if it is still native code.
I have seen the horror that is Qt dependent code...
pointless hobbyism really though...
Again, you've lost me. Are you talking about your code, Lina, what?
I was talking more abstractly, but partly about my own projects, and partly
about VMs in general.
hLater,
Randy Hyde
.
- References:
- If it works, this might be interesting
- From: rhyde@xxxxxxxxxx
- Re: If it works, this might be interesting
- From: cr88192
- Re: If it works, this might be interesting
- From: rhyde@xxxxxxxxxx
- If it works, this might be interesting
- Prev by Date: Re: If it works, this might be interesting
- Next by Date: Re: If it works, this might be interesting
- Previous by thread: Re: If it works, this might be interesting
- Next by thread: Re: If it works, this might be interesting
- Index(es):
Relevant Pages
|
