I have my own Smalltalk system implemented as a batch compiler via C.
This was originally just going to be a baseline for a student wanting
to work on JIT, but he went elsewhere and I found the system surprisingly
useful. I also wanted something that hewed closely to the ANSI Smalltalk
standard, but could diverge in other matters (like not having dynamic code
modification).
- All Smalltalk bytecode sets are stack-based VM. (?)
My system has no bytecodes. Smalltalk=>C=>native code.
- Bytecodes are always fixed-size. (?)
False back in the Blue Book. Why does it matter anyway?
- Most of the time spent by a VM is in the instruction interpreter. (actually it's in the GC right?)
There is no interpreter in my system, and many modern systems use a JIT.
That or they generate Javascript or JVM instructions or .NET or something,
and then _that_ gets turned into native code.
- You cannot serialize objects containing blocks. (IIRC one can use MessageSends)
True in my system but that's because blocks contain pointers to native code and may
contain pointers into the C stack. I have plans to work around this, but it has not been
a priority. Something I don't ever plan to deal with is objects containing references to
external objects (memory-mapped segments, file descriptors, sockets, ...) and it is not
at all clear to me what the semantics should be.
BinaryObjectStorage in VisualWorks has no trouble with blocks.
I meant to try this in Pharo 7.0. The image I just installed via the launcher has
no DataStream, ReferenceStream, or SmartRefStream, but the class comment
for MCDataStream begins
"This is the save-to-disk facility.
A DataStream can store one or more objects in a persistent form.
To handle objects with sharing and cycles, you must use a ReferenceStream
instead of a DataStream. (Or SmartRefStream.) ReferenceStream is typically
faster and produces smaller files because it doesn't repeatedly write the same Symbols."
This was also the case back to Pharo 2.0. What *is* the persistence scheme in Pharo these days?
- Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo I think).
There are no images in my system.
- All Smalltalks includes UI classes. (GemStone doesn't have AFAIK).
It depends on what you mean by "include". Gnu Smalltalk *has* UI classes but they
are not loaded by default.
- All implementations uses direct pointers, (GST?)
True in my case, but that's because I'm lazy and using the Boehm collector.
- All implementations uses green threads. (VAST? MT?)
False in my case. A Process is a POSIX (red) thread and no green threads exist.
This meant having to keep the interface fairly lean, but honestly wasn't that hard,
since the Boehm collector handled the hard stuff.