Re: Promoting adoption of Smalltalk & Designing a Standard Opcode Set For Smalltalk

"Peter Schuller" <[hidden email]> wrote in message
news:91j37b$ds$[hidden email]...
> >Everyone talks as if initial deployment is the end of the game.  I guess
> >we can wait for the 50th (and 100th for that matter) re-printing of the
> >'The Mythical Man Month' by Fred Brooks.  First ship means virtually
> >nothing in terms of overall cost.  Maintenance over the next few years
> >adds many times the initial cost.
>
> But the development cost imposed on big corporations isn't the issue! It's
> the *flexibility*. Look at Jini. How would you make Jini a reality in
> Smalltalk without everybody using the same VM?

Such a Jini like facility for Smalltalk could be developed. It is not
technically such a difficult problem, but it is a very challenging standards
problem for implementations/vendors.

One possibility is that:

a) Smalltalk vendors can continue to support their internal opcode formats.
b) A second, standardized/portable opcode set can be specified by community
and vendor interaction -- possibly via CampSmalltalk. To increase the chance
of acceptance and provide a good model for execution the "portable opcode
set" should be a new opcode set not based exactly on any current set. There
are a number of related considerations such as whether it should always be
jitted, versus whether it should be designed for interpreting, and whether
it should be broad enough to host (more than Smalltalk) both static and
dynamic language facilities, and whether it should be able to support value
types (non-oops such as Java and .NET have), etc.

For those Smalltalk's that want to support such a "portable/standard"
executable code representation, there are a number of approaches. First, if
they have a jitter architecture then they add support for an additional
jitter to handle the portable opcode set. Second, if that is not desireable,
they could produce an opcode-translator (i.e., a preprocessor: like the
frost concept or like the cross-jittersin the AOS VM's) that translates from
one opcode set to another.

Some advantages of this approach are that existing opcode sets do not need
to be unified; this could ease vendor issues regarding who might gain an
time to market advantage over another vendor (or other technical concerns).
An incremental approach, as sugested in the preceding paragraph, can be
taken to supporting the "standard/set" -- which is good for vendors and
possibly reduces the level debate over whose or what instruction set is most
ideal. Furthermore, an open-source compiler could be developed independently
from the vendors. That compiler could then be used on all implementations
for generating "portable" method packages.

The challenges include:

1. It will be difficult to get vendors to support the standard in their
VM's.

2. It may be very difficult to get vendors to work together to developer a
"good" opcode set. Without that collaboration, there is a very high
likelyhood of developing a "poor" opcode set.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> A standard bytecode format creates flexibility. People can create plugins,
> componenets Jini devices, RMI interfaces, and so on, completely
independent
> of the VM!
>
> I am not looking at this as a development process in a large corporation.
> I'm talking about the flexibility of the product.
>
> You can argue about the development costs of not being "locked in" all you
> like, but you can't refute the fact that a standard bytecode format
doesn't