javap -c output resembles FORTH(?)

[Tarkin]

....at least superficially. Is this because FORTH
represents the earliest, if not the first VM, and one
of the earlier interpreted languages?
Or is it because there are only so many ways
to 'skin a cat', that is, be a runtime-interpreter
with a VM, such that _any_ given
interpreter + VM will look similar?

A parallel discussion is seen here in the thread:
"Eiffel features in Java?" dated 1998,
Though it quickly turns into a debate on the
various merits or lack thereof as to the
suitability (or lack thereof) of FORTH.

TTFN,
Tarkin

 

[Tarkin]

A parallel discussion is seen here in the thread:

"Eiffel features in Java?" dated 1998,

[ED: in the comp.lang.forth, not this this newsgroup!]

Though it quickly turns into a debate on the
various merits or lack thereof as to the
suitability (or lack thereof) of FORTH.

[ED: ....for large and/or complex and/or
not embedded applications.]

TTFN,
Tarkin

 

[Chris Smith]

...at least superficially. Is this because FORTH
represents the earliest, if not the first VM, and one
of the earlier interpreted languages?
Or is it because there are only so many ways
to 'skin a cat', that is, be a runtime-interpreter
with a VM, such that _any_ given
interpreter + VM will look similar?

It is not true that ANY such system will look the same, but it is true
that there are only so many ways to skin a cat. When building a
portable virtual machine, you don't know how many registers will be
available. It's silly to just pick a number. The result will be code
that's optimized for a platform that doesn't really exist, and which
requires extra work and complexity to translate into a real machine.
There are basically two choices for a portable virtual machine: first,
model it as an infinite register machine and leave the VM to do spilling
onto the stack based on the number of actual registers on the target
hardware; or second, model it as a zero-register machine, in which all
operations are inherently stack-based, and leave the VM to handle
caching some stack slots into registers when possible.

So this "Forth-like" (by which I assume you mean stack-based)
architecture is one of two options. I tend to prefer the other option,
but either makes for feasible implementations.

If you're referring to some other similarity to Forth, then you might
want to be clearer about what it is.