Re: A 21st Century Apple II?

[mdj <mdj.mdj@gmail.com>]

On Mar 11, 1:59 pm, Jason <jasonb1...@yahoo.com> wrote:

> >    This is not a well-chosen example. The run-time requirements
> > of C++ are not that much different from Java - both need substantial
> > run-time support just to carry their own weight :-)
>
> I think this statement is based at least partly on a misunderstanding
> of the difference between a programming language and a programming
> platform.
>
> C++ is a programming language, Java is a programming platform.

Actually, Java is both.

> C++ needs no run-time support to run.  You can write C++ code which
> will live in an ROM without linking to any start up code or libraries
> (-nostartfiles, -nodefaultlibs g++ options).  Furthermore, the code can
> be linked statically (-static g++ option) so that there is no
> dependence on any dynamically loaded libraries.
>
> Java, by definition, runs on a Java Runtime Environment (JRE).  Java
> programs are compiled into a bytecode which is interpreted by a virtual
> machine implemented on the host system.  Some of these virtual machines
> support just-in-time (JIT) compilation which compiles the bytecode into
> native code when it is first loaded but they still require the presence
> of the JRE to function.

That's the most common way to do it. You can also use GCJ to produce a
binary that will run with the aid of a support library, exactly the
same way as the C++ compiler produces a binary that runs with the aid
of libstdc++

In practice, this isn't done very often, since the HotSpot capable
JVM's generally do a better job of optimising the critical code path.

> Several things should be apparent from the above:
>
> First, because C++ does not require any external libraries or other
> support in order to execute code written in it, C++ programs can be
> many times smaller than their Java counterparts.  This advantage
> becomes less significant with large programs that make heavy use of
> external libraries.

Of course, this is less applicable to the J2ME profile, which is
targetted at memory sizes as small as 64k. The support library is
granted, larger than that, but then libstdc++ is getting rather close
to a megabyte on my platform.

> Second, Java is not a suitable systems programming language not only
> because it must run on top of a JRE, but also because the language
> deliberately avoids constructs which allow its users to access memory
> directly.  The latter can certainly be addressed with native methods
> for direct access to memory/hardware although this would be considered
> poor design by most OS engineers and it still leaves the larger problem
> of the JRE remaining.

Nonetheless, it *has* been done. JavaOS complemented the JRE with a
microkernel to do just that. This used to run on a "JavaStation",
albiet very badly.

Of course, the idea of using true microkernels, let alone implementing
much of the OS in a higher level language still hasn't taken off, and
I suspect just the old adage of "if it aint broke don't fix it" will
keep mainstream OS's from being scratch rewritten for a very long
time.

Clever runtime systems however is an idea I can only see becoming more
widespread as the advantages it brings become more important.

> >    On one hand, I cannot think of any OS implemented in
> > either of these. That doesn't mean that they don't exist, but it's
> > hardly widespread. On the other hand, you have a language like Lisp,
> > which is "known" to be inefficient and a resource hog. This is
> > factually incorrect; Lisp has been used to implement the OSs of AI
> > workstations and there is even a story about a machine running an
> > interrupt handler in interpreted mode.
>
> Were you aware that Microsoft Windows is implemented in C++?  I can't
> think of an OS more widespread than it.
>
> Being inefficient or a resource hog does not preclude a language from
> being used to implement an operating system.

Almost enough to make you wish C++ *didn't* have pointers ;-)

Matt