towards a 64 bit vm / image

I put together some patches that redo the pidgin type system to use
traits instead of rules, use sizeof instead of hard coded
bit/byte/word sizes, and write slate images based on a given bitsize
instead of assuming 32 bits. I'm doing this because i want to run
slate on my amd64 system. Unfortunately it's broken now and nothing
works, but hopefully I'll fix that in the next few years if I'm lucky.
It includes some other stuff I think.

slate pidgin woes

I'm trying to make some changes to the slate pidgin code to help make
porting the VM to my 64 bit machine easier. I probably did a few too
many search/replaces but basically I'm getting this error:

Generating function PSObject_isImmutable

Generating function PSObject_restrictsDelegation

Generating function PSObject_addSlotNamed_valued_at_

The following condition was signaled:
Error: A method translation wasn't found for copyBytes:into:.

The following restarts are available:
0)      Abort evaluation of expression
1)      Quit Slate

Enter 'help.' for instructions.
Debug [0..1]: up.
[tryHandlers]

the method translation searcher is:

g@(C SimpleGenerator traits) generateCFor: selector@(Symbol traits) on: arguments
[...]

g: ("SimpleGenerator" currentColumn: 0. currentLine: 0. level: 0. columnsPerLine: 1000.
    original: ("Stream" ...). inlining: True. asserting: False. verbose: False. useSymbolicConstants: True.
    useRightShiftForDivide: True. generateDeadCode: False. methodCalls: {"Bag" ...}.

darcs patch: Fixed bitShift: for BigIntegers for the case of 0.

Sun Jun 17 17:25:23 PDT 2007  BrianTRice <at> gmail.com
  * Fixed bitShift: for BigIntegers for the case of 0.

64 bit slate VM images

I just upgraded my computer to a dual core amd64 machine. I'd like to
use this machine to work on slate, but I can't find any 64 bit images
and I'm not sure how I could use the initial lisp sources to generate
a new kernel image. Anyone have any ideas or experience here?

I'd like to stay away from installing any 32 bit programs on this
computer. Thanks.

Slate on a message-passing machine

I sent this four days ago, but it never yet arrived

For my Master's thesis, I will probably be working on a hardware
architecture for efficiently executing object-oriented systems.
Slate is definitely the most generic of these types of systems,
and so I believe I should make the hardware directly applicable
to slate, since all other object oriented semantics are a subset
of those provided by Slate.

For an example of the kind of hardware I am talking about,
consider Jecel's Ring Network Architecture:
http://www.merlintec.com:8080/hardware/19 . According to the
example, the RNA architecture can send, lookup, and execute a
message that is installed on a single receiver without software
assistance. I wonder if this design can accommodate some, if not
all, of the multi-dispatched message sends in slate. In other
words, is there (hopefully large) a subset of slate
message-passing semantics that can be resolved without resorting
to sending extra messages?

I hazard to guess that a subset of slate does have the same
semantics as the operation natively handled by RNA, but it may
be somewhat small. This seems to be the case when there is
exactly one method with the given selector, and the receivers
all have NoRole. This could be resolved as a single-send to the
method object with the receivers as arguments. Is this correct?

To implement Slate on a single-dispatch architecture, I think
selectors would be sent a single-dispatch valueWith:With ...,
message. To resolve, I suppose one would calculate the distance

Slate on a message-passing machine

For my Master's thesis, I will probably be working on a hardware
architecture for efficiently executing object-oriented systems.
Slate is definitely the most generic of these types of systems,
and so I believe I should make the hardware directly applicable
to slate, since all other object oriented semantics are a subset
of those provided by Slate.

For an example of the kind of hardware I am talking about,
consider Jecel's Ring Network Architecture:
http://www.merlintec.com:8080/hardware/19 . According to the
example, the RNA architecture can send, lookup, and execute a
message that is installed on a single receiver without software
assistance. I wonder if this design can accommodate some, if not
all, of the multi-dispatched message sends in slate. In other
words, is there (hopefully large) a subset of slate
message-passing semantics that can be resolved without resorting
to sending extra messages?

I hazard to guess that a subset of slate does have the same
semantics as the operation natively handled by RNA, but it may
be somewhat small. This seems to be the case when there is
exactly one method with the given selector, and the receivers
all have NoRole. This could be resolved as a single-send to the
method object with the receivers as arguments. Is this correct?

To implement Slate on a single-dispatch architecture, I think
selectors would be sent a single-dispatch valueWith:With ...,
message. To resolve, I suppose one would calculate the distance
for each method, then minimize it. This could probably be done
in one trip around the loop in an RNA architecture if the

slate bootstrap bug status report

I've been looking into a bug in the bootstrap process.

After you make a new image with: Image bootstrapBasedOn: VM new, slate
tries to load that image, and that's where it fails.  The image file
is made by parsing a lot of slate files which are defined in
build.slate and then concatenating them into one function that
initializes a normal slate environment. Since some of the functions
used in earlier files depend on functions fully defined in later
files, pre-bootstrap.slate is loaded first with some common functions
defined in simpler terms to keep things from crashing because of
missing dependancies.

However, somewhere in numeric.slate, things go wrong.
The first define:

numerics define: #Comparable &parents: {Cloneable}.

causes the Cloneable object to be transformed into a Compareable
object, and things go spiraling out of control when Float is defined,
which somehow causes the #traits3 = #traitsWindow to invoke
CoercibleNumberMixin's specializer coerceTo (because Symbol's
inheritance graph has changed to have Float where Cloneable would be),
which fails on symbols because they don't have a level.

I added this code to vm.c to realized this, but I'm not sure if the
code is correct:

  #ifdef DEBUG_MSG
  fprintf(stderr, "%d ", i->framePointer);

Some notes concening VM :)

Hello , i'm new here and have particular interests in developping a Slate VM.
I didn't decided yet if i will participate in this project in nearest
future, so i just want to discuss some of my ideas with you for now.

Concerning OMM (object memory model) and stack organization.
I'm refer to tables which you can see on this page:
http://slate.tunes.org/doc/mobius/

5.1.1 stack format.

Table 3. Block format.

I see little reason why selectors must be kept apart from literals.
The only place i see where they handled differently is at
interpretation stage to use different opcode 'Load Selector'.
If there's no extra processing except that, we can merge selectors
with literals slot and remove an opcode 'Load Selector'.

This is the code that shows that they handled in same manner..

static INLINE void PSInterpreter_loadLiteral_(struct Interpreter * i,
unsigned long int n)
{
  PSInterpreter_stackPush_(i, (((i -> method) -> literals) -> elements)[n]);
}

static INLINE void PSInterpreter_loadSelector_(struct Interpreter * i,
unsigned long int n)
{
  PSInterpreter_stackPush_(i, (((i -> method) -> selectors) -> elements)[n]);

Long-overdue updates

Hello all,

I'd like to revive the Slate project from dormancy in the last very  
quiet year, and would just like everyone to know that major overhauls  
of the project or code are totally acceptable if it means making it  
viable again. Most importantly, run-time improvements for memory  
management (generational GC, weak pointers, or manual memory  
management support) and the VM (threaded-code vs. bytecode, and most  
importantly, dynamic method inlining). Also, if someone wants to just  
take the reins and go change things relatively drastically, I will  
support that.

I've fixed up the main site homepage to correctly describe what we  
want to have environment-wise, compared to Self/Strongtalk: same  
optimizations, but self-hosted and in a simpler architecture. I've  
also hopefully more accurately described the current state of the  
project.

I'm attempting to get the alpha repository to run all build targets  
without end-user tweaking. I'll set up some automation so that I can  
track this down with minimal effort from here on. I will probably  
remove the main/alpha repository distinction for simplicity's sake,  
so that it's as simple as possible for a visitor to arrive and get a  
usable system.

In other news, I've finally learned how to write web applications  
over the last year, so it'll probably be a lot easier for me to  
improve the liveliness and feature set of the website.

Suggestions are quite welcome. I'll update as replies on this thread.

New Job

Hi all, just a quick update.

I am now working full-time at a product development company, http:// 
www.synapse.com which is Squeak-friendly and I will be cooking up  
UI's for embedded systems prototypes and otherwise hacking on firmware.

It's very exciting and pays well, and I'll try to make Slate a  
priority for it if I can, but central to that is solving our huge  
problem of needing a good dynamic inliner.

--
-Brian
http://briantrice.com

Alan Kay's new project