Squeak People diary for Jecel

23 Nov 2006

Thu, 23 Nov 2006 23:24:10 -0700

Yesterday, I mentioned a plan to incrementally develop a Squeak machine starting with a simple RISC processor. Step 3 would be the addition of a technology similar to ARM's Jazelle, which I am calling "BC Mode". This would speed up the interpreter allowing the compiler to be used just for the most critical code.

What was missing was that step 2 only mentioned the very similar "PIC Mode" technology for type feedback with no details, but this would involve not only adding a special PIC Cache (or enhancing the instruction cache to include this extra functionality) but also at least one instruction. In the case of RISC42 the COPR instruction makes additions like this trivial.

While this is being done it would be a good idea to consider other instructions that might improve the compiled code. A TADD instruction which checks the operands for SmallInteger tags and does all the ugly untagging/tagging in a single clock would be nice, for example. It could save the result and skip the next instruction in the case where everything worked out - this would be simpler for the compiler to handle than a trap.

23 Nov 2006

Thu, 23 Nov 2006 00:46:57 -0700

Though my current focus is on stack based hardware for running Neo Smalltalk, I am slowly evolving my ideas of how to build a Squeak Machine. One possible plan:

start out with a conventional processor (like my RISC42 design) running SqueakNOS
add my PIC Mode technology to speed up message dispatch and provide type feedback for a compiler like Exupery
add something like ARM's Jazelle 1 technology to speed up the interpreter

This incremental approach would have an end result equivalent to a microcoded solution while remaining more compatible with Squeak's current technologies.

17 Aug 2004

Tue, 17 Aug 2004 18:49:37 -0700

Object Reference Model

No object is an island - they can grouped together in several different ways. Here are some of them:

disk (package, segment, soup, image, snapshot): In theory, every individual object could be stored separately in permanent memory. The opposite strategy, where all objects are saved in a single file, has often been used. Intermediate solutions give the users more control over disk management.
process (thread, transaction, actor): The most common implementations have concurrency as totally independent of objects, but that is not natural and is harder to program. When making execution an integral part of objects, this can be applied to all objects or they can be separated into active and passive objects.
security (capability, user, session): When multiple users share a system, it is important to protect one from the actions of the others. Even with a single user it is a good idea to make accidents less likely and/or less severe.
type (class, clone family): Even when a programmer is presented with a model in which each object is totally independent of the others, that is not practical in terms of implementation. The system must use some notion of type to associate executable code with the received messages.
inheritance (sub/superclass, trait, mixin, parent/child): Facctoring and refactoring is an important process in software development. Being able to express concepts in terms of differences in relation to other concepts can provide support for this.
composite (part, assembly): Just like in the real world, objects can be combined to create larger objects.
version: An object's state varies over time as a side effect of normal operation. In addition, programming changes on live objects can result in new or removed "slots" as well as changes in behavior.
reflection (metaspace, mirror, class, aspect): While objects often simulate real world objects, they actually are computer constructs built with resources like memory and processing power. Behavioral reflaction can deal with the latter and structural reflection with the former.
viewpoint (layer, subject, piece, namespace): Simple systems exist in total isolation an can be completely objective. Larger systems can't hope to be entirely consistent and must be prepared to handle different interpretations of the same concepts.
role: Concepts in different parts of the system can represent a single entity.

So?

The idea of a reference model (like the OSI network one) is to create a common framework in which different implementations can be compared.

20 Jan 2004

Tue, 20 Jan 2004 00:33:40 -0700

I am trying to compare these alternatives:

Squeak Hardware: partly described on Jan 9, this would involve two images. TedK and Glenn Krasner have already done this in their LOOM virtual memory system for Smalltalk-80. The root image would be trimmed down as much as possible but would include two instances of the Interpreter class. One would represent the root image itself, while the other would represent the user image. Whenever code translated from Slang to C would be called in a "normal" Squeak VM, the hardware would simply switch Interpreter objects and go back to executing bytecodes. This Escher drawing is a pretty good illustration of what this system would be like.
EToys on Neo Smalltalk: for many people when they talk about Squeak they really mean EToys, so if that were ported to run on Neo Smalltalk they would be happy with my machine.
Squeak on Neo Smalltalk: it would be possible to translate Squeak objects and bytecodes into Neo Smalltalk equivalents as an alternative way to get Squeak to run on my hardware. PEP, the Java-on-Self project, showed how it can be done. It is interesting to compare that with Gnu Smalltalk-on-Self. Low level stuff like the debugger would break in this environment, but enough might run to make it worth it.

The original idea was to have a complete and bidirectional compatibility layer for Squeak over Neo Smalltalk. I called that "150% compatibility" since it would allow a package from, for example, Squeak 2.3 to live side by side with stuff loaded from Squeak 3.5 and that is even more compatible than Squeak itself. That is a very ambitious and long term project, so it was not included in the above list.

Evaluating EToys with MudPie and looking at the scripting methods for class Morph showed that 2 is not a practical option as there is no clear separation between EToys and Morphic. That leaves 1 and 3.

9 Jan 2004

Fri, 09 Jan 2004 19:48:05 -0700

People are starting to get excited about Squeak down here, mostly due to the "Squeakers" DVD. So today and next week I will be considering the possibility of using Squeak instead of Neo Smalltalk in the initial release of my hardware to make it easier to collaborate with these people.

Neo Smalltalk and its hardware were designed together. For example, the architecture (called "Plurion") is a network of five relatively slow (100 MHz) and simple stack processors. The software was created to have an average of dozens of active threads, which should be enough to keep all processors busy most of the time.

Squeak, on the other hand, represents a fixed software design. This requires a different hardware with very different tradeoffs. Unless the result with these constraints still represents a huge cost/performance advantage over, for example, a XScale solution then it wouldn't be a project worth doing.

The first step in this evaluation was checking out the bytecodes. It is nice that Squeak's bytecodes are almost exactly the original Smalltalk-80 ones because there is a lot of information about them in the "green book" (Smalltalk-80: Bits of History, Words of Advice). While more complex than what I had been using, they don't seem too unreasonable and a "one bytecode per clock" implementation might be possible.

Primitives and plug-ins represent the bulk of the virtual machine, however. It would not be a good idea to try to render them in hardware. At least the parts that are written in Slang wouldn't be a problem - they can be compiled to bytecodes and executed by the same hardware that handles regular Smalltalk code. Any parts in C would have to be rewritten in Slang (or plain Smalltalk if possible) which was actually already being done by the SqueakNOS guys.

19 Nov 2003

Wed, 19 Nov 2003 00:03:52 -0700

Yet another diary.

I first started one for the Merlin Project (68000 based Smalltalk computer) in November of 1984. The last entry was for December of 1993 (I moved all documentation efforts to the Web after that), but it is sad to see how many times years went by without a single entry.

My swiki already contains two project diaries: one for the truck terminal and the other for the adaptation of that as a low cost computer. I will probably have to start another one soon for the "real" Smalltalk computer.

But this is about Squeak, and after so many years toying with it I have finally started using it in my work. It is funny that the only reason why I am using it instead of Self is because I got serial ports to work on the first try but looking through the Solaris manuals it didn't seem easy to do the same thing in Self.

So I did

a file/font/text uploader to the prototype Flash memory
a quick and dirty compiler for the 4 bit Smalltalk processor
the truck terminal application itself accessing all the peripherals remotely through a simple hardware in the FPGA and the serial port.