Some time later, I got hold of the (excellent) book "Smalltalk-80, the language and implementation", after that I started to implement an experimental bytecode interpreter.
The bad performance of this interpreter lead soon to the conclusion, that only compilation to machine language will provide acceptable performance.
Due to previous (positive) experience with other cross-language
compilers (Basic-to-C :-)) and Lisp-to-C) this approach was
also taken, eventually leading to the first running Smalltalk-to-C
(stc) compiler during 1986/1987.
(the experiments began a few years earlier, but the full Smalltalk
semantics - especially contexts & blocks - was finally implemented
at that time).
Notice, that this was before dynamic translation of bytecode to machine code (aka JIT-ting) was well known, and I had no running Smalltalk at hand to start with. So the system was written completely from scratch in a "clean-room" environment. I decided to use yacc+lex to parse Smalltalk code (in fileOut format), and generate C-code from it.
This source-to-source compiler was named "stc" (for "Smalltalk-to-C") and this compiler is still used today (although it went through many revisions, as new syntax, features and optimizations where added).
Of course, in the meantime, this is also done by other Smalltalk systems, and Smalltalk/X nowadays also runs under non-X (e.g. Windows) systems, making the "X" a historical leftover (which is kept until I may find a better name :-).
Notice, that there is another package called
the "GNU-Smalltalk's X extension".
These two have nothing in common
"ST/X" ("Smalltalk/X") should not be confused
The author still depends on testers to send a note if any incompatibilities are encountered. Such a note should include the class & method name and a verbal description of what it should do. Also, incompatible instancevariable names are worth such a note (since those names should match for proper subclassability). Do not send any code which is based on or derived from any other existing Smalltalk system - I cannot make any use of it.
Since this (ParcPlace-) license does not cover the View and GUI elements, those classes are not (and may never be) fully compatible to ParcPlace implementations - however, some hooks and compatibility methods have been built in, in order to make porting at least easier (in the recent past, we have spent quite some effort in making ST/X very compatible to VisualWorks, making it very easy to port even highly GUI intensive code).
This may change if ongoing standardization efforts lead to an "Ansi Smalltalk" covering these classes. However, since even basic features (such as Blocks being closures) seem to make trouble in standardization, I personally doubt that there will be a standard covering these classes in the near future.
However, for development & prototyping, it became soon obvious that an incremental compiler was needed to be available IN the system and a bytecode compiler and interpreter were added during 1988. This allowed for a much better development experience, as code can now be executed inside the system, without the tedious save-compile-restart cycle.
A dynamic machine code compiler (JITter) was added shortly after that, around 1990. Initially, it supported MIPS and Sparc CPUs, but over time, many more architectures were added, some of which are now obsolete and no longer maintained (but could be reactivated relatively easily, if a demand arises).
Thus, in ST/X things were developed vice versa - first came the standAlone compiler, then the bytecodes and incremental compilation.
Many testers and more people joined the team, providing suggestions, hints, bug reports and adding new features.
If you like to participate in the development and/or donate code, new classes, examples or applications, feel free to contact the author or eXept, to have it included in the next distribution.
Be aware, that eXept has to earn money to pay its employees (what did you think?). While you get ST/X for free, it must be clear that we cannot spend our time with developing Smalltalk alone. Therefore, what you get is the fall-out of what we need for our own products and development.
If you have any wishes for improvement, support or a port to a particular machine, we have to ask for money. Customers for which ST/X is mission critical (yes, there a quite a few!) may get a maintenance contract which gives them online support, consulting, feature implementation upon request, regular updates and online access to the current development versions. Please contact firstname.lastname@example.org for details.
Without such a contract, you will have to wait for whenever we find time to provide a new free version. However, this is usually somewhat older (1/2 to 1 year) from what maintenance customers get.
The current system includes a Java support subsystem, which is able to read binary Java class files, and load them almost seamless into the Smalltalk class hierarchy (under a separate JAVA namespace). The VM and Jitter do handle Java-bytecode methods transparently, so Smalltalk can call Java and vice versa. In fact, Java objects are represented as Smalltalk objects internally, so there is no gap in the object representation. All reflective features of Smalltalk are also available with Java classes/methods and objects. And all dynamic features are available for Java code - this includes dynamic change of object layouts, adding/removing methods, changing the inheritance and accepting in the debugger.
Ongoing work is done in the browser, code completion and refactoring tools. Thanks to Marcel, Jan and the other guys from the Prag-CVUT Computer Science lab for lots of stuff in this area.