Re: Dusting off an old JVM discussion

On Aug 12, 6:53 pm, xge...@xxxxxxxxx wrote:
Hey all. Please excuse me for resurrecting a discussion that began
around 1997, but I had some questions and was wondering if someone
could shed some light on it.

I have recently been thinking heavily about just how bad the operating
systems that I use are. I use WinXP and Windows Mobile 5 at work and
what I observe is that processors are getting way faster, but the
operating systems that run on them get more and more bloated, and the
net effect is that my computers never get faster, and continue to be
unreliable.

Anyhow this has led me to ponder some things, including Forth.
Although I have no wish to program in Forth, there are many aspects of
the Forth language (small size, for example) that appeal to me.

I was wondering how difficult it would be to write a JVM in Forth, as
the c++ versions of the full JVM seem quite large to me. At least
they are too large for embedded devices like blackberries and PDA's,
which is why we have the stripped down KVM for mobile devices.

Anyhow, I looked at the JVM specification, and it struck me that any
Java program, when compiled to bytecode, will basically contain a
series of bytecode (or should they be referred to as opcode?)
instructions. Upon looking at those "opcode" instructions, they
looked to me to be very similar to Forth instructions.

So I am wondering how difficult it would be for a skilled and
experienced Forth programmer to write a JVM, since it seems to me that
for the most part they would be translating very similar
instructions.

In some of my research, I came across this FAQ (http://www.faqs.org/
faqs/computer-lang/forth-faq/part1/) , which specifically mentions
this idea and some of the difficulties that may be associated with
it. I have added my comments/questions to them. They are:

-garbage collection --> this seems complicated and beyond my skills to
fully comprehend whether it can be done or not.

-threads --> Not sure why this is problemmatic. This Forth (http://
pfe.sourceforge.net/doc/) claims to be fully multi-threaded.

-control structures (branches->ANS Forth's seven universal control
structure words) --> I have no idea what this means or why it is a
problem.

-exceptions --> Here is a project which implements exception handling
in Forth (http://portal.acm.org/citation.cfm?id=70811.70815)

-subroutines (JavaVM does not specify that a subroutine returns to its
caller) --> I have no idea why this matters.

-JavaVM makes the same mistake as Forth standards up to Forth-83: It
specifies type sizes (e.g., a JavaVM int is always 32-bit). A few
operators have to be added to support this. --> Is this really non-
trivial?

-The native libraries (without them JavaVM can do nothing). -->
Clearly there are going to be some operations that are currently
handled by native libraries that would have to be handled in the Forth
JVM. But I am not aware of anything that c++ (i.e. native libraries)
can do that Forth can't. So what is the problem?

-----------------------------------------

So, moving beyond the technical questions revolving around IF the
aforementioned JVM implemented in Forth would work, I have been
daydreaming about the possibility of a pervasive OS and development
paradigm.

I imagine applications that run on Servers, Desktops and handhelds,
without having to worry whether it is Gnome or KDE or whatever. I
imagine being able to walk around with my computer in my hand, and
plugging it in to whatever peripherals I need at home, or the office,
or wherever.

Let's face it, the software needs of the average user are pretty
minimal. Aside from my dev environments, all I need is a web browser,
word processor, spread***, and (maybe) mail client.

All of those applications have been around in a fairly mature state
since 1998 at least, and I think today's PDA's might have more memory
and higher clock speeds than my computer did back then.

I imagine those applications written in Java, supported by a JVM
implemented in Forth, running on a Forth-chip based system that
doesn't have all the overhead and baggage of the current x86 wintel
miasma.

As I said, this is a lot of daydreaming, and I am a software
architect, not a computer engineer. But are these concepts pie in the
sky? Is a Forth based JVM possible, and if so how large might it be
and (speculatively speaking) how fast might it be, particularly if it
were running on a Forth-chip based system?

I think the short answer to your question is YES. A Java VM can be
implemented in Forth. The basic JVM is a byte-code driven machine,
and making a set of routines that correctly interpret the byte-codes
can be done in many languages.

But if that Forth is also a Forth VM running threaded code, the
performance could be wanting. As a point of interest however, others
have already thought of your idea, by using Forth specific hardware to
interpret JVM byte-codes.

forthfreak.net/misc/psc1000.pdf


The information below is for a Forth Architecture CPU chip that was
invented by Chuck Moore. It is (was?) sold by Patriot Scientific as a
"Java Chip" as you can see below.

PSC1000 Microprocessor
32-BIT RISC PROCESSOR
1
Features
General Description
Low-System-Cost 32-Bit RISC Microprocessor
Runs Java? at Native Speed
Multiple Language Support
Dual-Processor Architecture
·Microprocessing Unit (MPU)
High-performance zero-operand dual-stack
architecture
·Virtual Peripheral Unit (VPU)
Performs timing, time-synchronous data
transfers, bit outputs, DRAM refresh,
emulates peripherals
4-Gigabyte Physical Address Space
Internal Clock Multiplier
·2X CPU clock, 4X Bus timing
4-Group Memory/Bus Interface
·Supports any combination of EPROM, SRAM,
DRAM, VRAM
·Programmable memory and I/O timing
Virtual Memory Support
8-Level Interrupt Controller
8-Level Direct Memory Access Controller
16 I/O bits
52 General-Purpose 32-Bit Registers
"Glueless" System Interface
Big Endian Byte Ordering
Small, Low-Cost, 100-Pin TQFP Package
--------

The Forth VM and the Java VM have some similarities that make running
Java on a Forth chip pretty efficient.
The bigger problem of course is marketing. All that you ask for can
be done, but who will pay for it? If it can't be made into a
commercial success or develop serious geek popularity/demand (a la
Linux), you will have a user group of 1 and a lot of S/W maintenance
on your hands. :-)


Brian Fox
Western Union Canada

.